谁能用网络技术登陆不知道微信账号密码登陆的qq号,夹,,,酒三四一八起四酒肆

of the controls and components, and we are committed to making Video.js the most accessible player we can. Video.js also provides some shiny, and awesome, new features for developers in
and . Video.js 6.0 is also the first release where
– though, it is still available as a plugin, if necessary.
Today’s release is a pre-release and will stay that way for about a week or two before being promoted to latest. Just to make sure that any last bugs, if any, are ironed out.
Things you should knowMost things have not changed between 5.x and 6.x. In fact, in most of our work in plugins we maintain, the majority of the work was to use new methods and fallback to old methods because they were logging deprecation warnings. Those plugins would’ve continued working otherwise.
However, there are definitely some changes that are breaking and would require action on your part. For example, if you require Flash, that’s something that would now need to be included manually.
One of the other big changes is that source selection is now asynchronous. This was necessary for middleware support and most likely won’t affect users if they are waiting for the player to be ready before interacting with the player.
These are written up on our . We’ll make sure to update it if there’s anything that we missed.
Feedback WantedIf you are using Video.js and have comments or questions, please drop by on . If you find a bug, please open an , preferably with a .
5.x SupportWe’re still going to be supporting the Video.js 5.x release line. This will mostly be bug fixes but features will be considered on a case-by-case basis.
If IE8 support is still required, it is probably best to stick to 5.x.
Once Video.js 6 is promoted to latest, it’ll take over the next and latest tags on npm. The 5.x release line will then be given its own set of tags: latest-5 and next-5.
Code of CondunctWe strive to be open and inclusive and so we have adopted a , based on
that applies to all Video.js projects.
ConclusionWe are super excited for this release! Please take it for a spin from next tag on npm or from the . And please come chat with us on .
. This middleware will change the times of the controls depending on the current rate. For example, if you’re playing back a 20 minute video and change the rate to 2x, the controls will adjust to display 10 minutes. Let’s take a look at the code.123456789101112131415videojs.use('*', function(player) {
return {
setSource(srcObj, next) {
next(null, srcObj);
duration(dur) {
return dur / player.playbackRate();
};});
So, here, we attach a star-middleware because we want to have it applied to any video, regardless of the MIME type. In setSource, we also call next directly with null and the srcObj because we want to use this middleware with any and all sources. We also set up our duration method to take in the duration from the previous middleware and divide it by the playback rate we get from the player.
If you look at the
you can see some other methods next to duration. They’re there to make sure other methods that rely on timing get updated. The two methods to notice are currentTime and setCurrentTime. currentTime gets called when we want to know what the current time is. setCurrentTime is called when we’re seeking. Because the user is seeking in the shifted time, we want to apply our change operation in reverse. Instead of dividing it, we want to multiply it.1234567currentTime(ct) {
return ct / player.playbackRate();},setCurrentTime(ct) {
return ct * player.playbackRate();},
If you were to apply what we’ve done so far, you’ll notice that the nothing changes, the control bar is still showing a duration of 20 minutes. This is because as far as Video.js knows, nothing has changed. So, we need to tell Video.js that the duration has changed. We can do that by storing the tech that Video.js gives us after source selection is complete.1234567891011videojs.use('*', function(player) {
return {
setTech(newTech) {
tech = newT
};});
And then, when the ratechange event triggers, we tell Video.js that the duration has changed and Video.js will update the controls accordingly:123456789101112videojs.use('*', function(player) {
player.on('ratechange', function() {
tech.trigger('durationchange');
tech.trigger('timeupdate');
return {
}});
You can see a
our intention of removing Flash as a part of the core Video.js project.As Html5 video becomes the standard playback tech and Flash fades into obsolescence, it is timeto remove Flash from the core player and move it to a separate code base.
This will give us the abilityto allow developers to continue to support legacy browsers by adding the tech themselves, while allowingus to minimize legacy code in Video.js and decrease the footprint of the player.
This follows in the footsteps of Chrome, Safari and Firefox which are all taking steps to deprecate Flash.
As of the Video.js 6.0 release, the dream of a Flashless future will come closer to a reality.
In the meantime, the separate
project has been created for Flash tech support.When the
plugin is added to the player, the Flash tech is added to the tech order.
1234567891011 rel="stylesheet" href="path/video.js/dist/video-js.css"& src="path/video.js/dist/video.js"&& src="path/videojs-flash/dist/videojs-flash.js"&&
id='vid' class='video-js' controls height=300 width=600&
src="video.mp4" type="video/mp4"&&&
var player = videojs('vid');&
if you already know what accessibility is.
Accessibility? What’s that?Accessible software has support for users with vision, hearing, movement/dexterity, or other impairments. It also helps users that want to use the keyboard to navigate. Out of the box web applications have some accessibility due to the nature of HTML, but this is only the case if you are using native elements in intended ways. If you cannot use native DOM elements, like &button&, and instead must use a &div& for buttons, then you need worry about accessibility in your page.
Supporting users with hearing impairment is not something that we can do directly for the users of Video.js. Instead we must indirectly support these users by adding support for captions in videos. In Video.js we have had support for captions and subtitles for some time, internally they are called TextTracks. In fact Video.js has had support for WebVTT format TextTrack, which is much more accessible, since version 4.
Supporting users with vision impairment is harder, but partly in our control. To support this group of users our player must be accessible to screen readers. A screen reader is an application that reads elements off of the screen to the user (as the name implies). On top of reading from the screen it also allows the user to interact with the page using only the keyboard or specific gestures on a touchscreen (without using a mouse or needing to directly touch visible items). HTML has certain rules that must be followed so that a page can be accessible. We will go over the basics of these rules in the next section. Screen readers are further supported by having description tracks that can be read out during video playback. Description tracks are a sub-type of TextTrack, and as previously stated we cannot automatically add them to videos, we can only have support for them in the Video.js.
for a list of screen readers.
How do you make a web application screen reader accessible?If you use the native elements for the purposes that they were intended, you will already have most of the work done.This is why the use of the native element is the recommended way to make anything accessible for a screen reader. For instance if you use a &button& element you will get the following accessibility attributes (without them actually being on the button):
tabIndex which allows users to tab to the button
role=&button& which tells the screen reader that this is a button
The space and the enter key will both press the button
In some cases, such as in Video.js, it will not be possible to use the native &button& element. You will have to mimic the accessible functionality from the list above and use a div. Here is a list of what you will have to add:
You have to add the role=&button& attribute to classify it as a button.
You have to add a tabIndex which will allow the div to be navigated to using the tab key
You have to add handling for the space and enter key that press the button
A list of role attribute values can be found on .
After mimicking or adding native accessibility on the controls and content in your webpage, the next thing to look over are aria attributes. For instance, we use aria-live=&polite& for our ProgressBar slider. By default aria-live is set off, which means updates to controls should not be read to the user unless they un-focus and re-focus an element. The value of polite which we use allows us to convey the position of the slider to screen reader without them having to change focus on the control. This is useful because the ProgressBar is always updating while a video is playing. A value of polite will also wait to convey said updates until the screen reader is done reading other information to the user.
For a more complete list of .
Finally you need to add an accessible “name” to an element so that it can be referred to. A good example of this is can be seen in the MuteToggle control. Since it is not a simple “button” we include innerHTML/innerText of “Mute” or “Unmute” in a way that is hidden from most users but announced to screen readers. In Video.js we refer to the accessible name and the action that a control performs as “control text”. Control text also updates the title attribute of an element in most cases, which is important for visual accessibility. When the action the a control performs changes so does the control text. This will allow the screen reader to refer to the MuteToggle as “Mute Toggle” rather than “button”. It will also convey the current action of the MuteToggle. In this case that will be either “Mute” or “Unmute” depending on what the button would do when pressed (ie the state of the button).
Here are some examples of accessibility straight from Video.js:
The MuteToggle &button&:
Has aria-live set to polite, rather than the default value of off. aria-live with any value other than off indicates that innerText/innerHTML updates can be sent to the screen reader without the user needing to move focus off of the control. The value of polite means that the screen reader should wait until it is done speaking to convey these updates to the user.
Has control text of “Mute” or “Unmute” which indicates the current status of the button to the use
The VolumeBar slider &div&:
Has a role attribute with a value of slider. Like this: role=&slider&
Has a tabIndex attribute as it is not a native control element
Has EventHandlers that listen for:
The up and right arrow keys to increase the volume and the slider percentage
The down and left arrow keys to decrease the volume and the slider percentage
Has aria-label of “volume level” which is an accessible label that the screen reader will use to refer to it
Has aria-valuenow and aria-valuetext properties that update to indicate the current volume level (so the screen reader can read it)
Has aria-live set to polite, rather than the default value of off. aria-live with any value other than off indicates that innerText/innerHTML updates can be sent to the screen reader without the user needing to move focus off of the control. The value of polite means that the screen reader should wait until it is done speaking to convey these updates to the user.
The problem and the solutionNow let’s talk about how screen reader accessibility broke in Video.js 5. First VolumeMenuButton replaced MuteToggle and VolumeControl on the ControlBar. VolumeMenuButton was set to mimic MuteToggle when clicked. It would also show the VolumeControl on mouseover or focus. This was a problem because a VolumeControl was a now a child of a button, and buttons should not contain other controls. To the screen reader and to the DOM there are two MuteToggle button controls. When visually there is a VolumeControl and a MuteToggle. Below you can see a gif of this behavior in action :
The solution to this problem was to use a regular div to house the MuteToggle and VolumeControl. This regular div would have no role or control text so that it would be invisible to a screen reader. From that point forward we just needed to mimic the old UI. For those who are wondering, this new Component is called the VolumePanel. See the new behavior in a gif below:
OutlinesAnother big accessibility fix for controls comes from the removal of one small css rule:
Why did we do it? With feedback from the community and , we learned that outlines should always be on. Without outlines there is no visual indication of keyboard focus on control elements and without that, keyboard users who are not visually impaired have a hard time using the controls.
Wrap upHopefully this post has given you some insight into making a web application accessible. If you find any issues or have any suggestions for our accessibility or in general feel free to .
If you want to keep up to date on the current state of accessibility work see the a11y label on
ResourcesHere are some popular screen readers that are actually used in the wild:
Resources for learning more about web accessibility:
available.
These plugins - which we’ll call basic plugins - are lightweight and offer complete control of the player. That’s really useful and it isn’t changing - existing plugins should continue to work!
But what if you want a richer set of features? Or more guidance on how to structure your plugin? Or more tools out of the box that help manage complex plugin-rich players?
Well, until Video.js 6.0, you had to figure things out on your own.
Introducing Advanced PluginsOne of Video.js’ strengths is its rich
so, in the last few months, we wanted to focus our efforts on improving the plugin author experience.
While projects like
make becoming a plugin author easier than ever, the Video.js team thought it was important to provide a foundational API and set of conventions on which the future of Video.js plugins could be built.
Our solution is advanced plugins.
Advanced Plugins are Component-LikeOne of the design goals for advanced plugins was to provide an API that was reminiscent of the existing components system. We achieved this in a number of ways.
At the lowest level, this included a name change for the plugin registration function from videojs.plugin to videojs.registerPlugin (taking a naming cue from videojs.registerComponent and videojs.registerTech).
Beyond a simple registration method name change, advanced plugins are class-based. A trivial example of an advanced plugin might look something like this:
12345678910const Plugin = videojs.getPlugin('Plugin');class HelloWorld extends Plugin {
constructor(player) {
super(player);
this.addClass('hello-world')
}}videojs.registerPlugin('helloWorld', HelloWorld);
This plugin can be initialized in the same way as a basic plugin - via a player method whose name matches the registered name of the plugin.
In the case of advanced plugins, this method is a factory function, which instantiates the plugin class and returns an instance.
It’s useful to know that the player method that is created will always be a function. If a player already has an instance of an advanced plugin, its associated method will simply return the pre-existing instance rather than re-initialize it:
12345const player = videojs('my-player');const instance = player.helloWorld();videojs.log(instance === player.helloWorld());
The helloWorld method will return this plugin object until it is disposed - after which it will create a new plugin instance again.
EventsSimilar to components, advanced plugins can listen to and trigger events via the on, one, off, and trigger methods.
This provides a loosely coupled communication channel for plugins and other objects (components, players, etc) to manage their own state and respond to changes in the state of one another.
Additional Event DataThe Video.js event system allows additional data to be passed to listeners as a second argument when triggering events (the first argument is the event object itself).
Plugin events pass a consistent set of properties in this object (including any custom properties passed to trigger):
instance: The plugin instance, which triggered the event.
name: The name of the plugin as a string (e.g. 'helloWorld').
plugin: The plugin class/constructor function (e.g. HelloWorld).
For example, a listener for an event on a plugin can expect something like this:
1234567891011const player = videojs('my-player');const instance = player.helloWorld();instance.on('some-custom-event', (e, data) =& {
videojs.log(data.instance === instance);
videojs.log(data.name === 'helloWorld');
videojs.log(data.plugin === videojs.getPlugin('helloWorld'));
videojs.log(data.foo); });instance.trigger('some-custom-event', {foo: 'bar'});
LifecycleAnother similarity between plugins and components is the concept of a lifecycle - more specifically, setup and teardown processes.
We get the setup feature as a side effect of normal object creation in JavaScript, but we are left to our own devices when it comes to object destruction and ensuring that references between objects are cleaned up to avoid leaking memory.
Video.js components have long had a dispose method and event that deal with removing a component from the DOM and memory. Advanced plugins have the same feature:
12345678910111213141516const player = videojs('my-player');const firstInstance = player.helloWorld();videojs.log(firstInstance === player.helloWorld());firstInstance.on('dispose', () =& videojs.log('disposing a helloWorld instance'));firstInstance.dispose();const secondInstance = player.helloWorld(); videojs.log(firstInstance === secondInstance);
The pluginsetup EventPlugins do have one lifecycle feature that components do not: the pluginsetup event.
This event is triggered on a player when a plugin is initialized on it:
12345678910const player = videojs('my-player');player.on('pluginsetup', (e, hash) =& {
if (hash.name === 'helloWorld') {
videojs.log('A helloWorld instance was created!');
}});player.helloWorld();
React-inspired StatefulnessOne of the exciting additions in Video.js for both advanced plugins and components is React-inspired statefulness. Essentially, this means that all plugin objects and component objects have a state property, which is a plain object that can be used to store variable state for that object. Then, there is a setState method that updates this object and triggers a statechanged event.
This system allows plugins and components to use their evented nature to communicate in-memory state changes through a consistent API:
1234567891011121314151617HelloWorld.defaultState = {color: 'red'};const player = videojs('my-player');const instance = player.helloWorld();instance.on('statechanged', (e) =& {
const {color} = e.
if (color) {
videojs.log(`The helloWorld color changed from "${color.from}" to "${color.to}"!`);
}});instance.setState({color: 'blue'});
Player Plugin AwarenessFinally, we couldn’t add new plugin infrastructure without working on one of the more pernicious problems of managing complex combinations of plugins: the player can’t report which plugins it has initialized - or not. To this end, the player has two new methods: hasPlugin and usingPlugin. These methods work for both types of plugins.
The hasPlugin MethodThis method reports whether a plugin matching a given name is available on the player:
1234567const player = videojs('my-player');videojs.log(player.hasPlugin('helloWorld'));videojs.log(player.hasPlugin('fooBar'));
This method ignores whether or not the plugin has been initialized and merely reports whether or not it has been registered.
The usingPlugin MethodThis method reports not only whether a plugin is available on a player, but whether it is currently active on the player:
123456789const player = videojs('my-player');videojs.log(player.usingPlugin('helloWorld'));player.helloWorld();videojs.log(player.usingPlugin('helloWorld'));
One caveat to note here. While this works for both types of plugins, only advanced plugins can change this value more than once. A basic plugin has no built-in so, it’s not possible to determine whether one has been “disposed”.
Go Forth and CodeWe hope these additions and improvements to the plugin architecture will make writing Video.js plugins more pleasurable and remove some of the low-level legwork involved in ensuring plugins aren’t creating memory leaks and other problems.
The design of advanced plugins is such that we can add features as 6.0 matures and we get more community feedback. As always, we strongly encourage our users
in whatever way they can.
For a more complete discussion of plugins generally, visit the .
and we also made a lot of improvements under the hood.
How to try it outThe RC is now published on npm under the beta tag with verion 6.0.0-RC.0.
1npm install video.js@beta
Please try it out and let us know how it is on .
What to look forward to
We’re finally removing Flash from core as outlined in .
Plugins are being updated to a React-inspired component architecture. The old style is staying around.
We’re recommitting to accessiblity by fixing the accessibilty of our volume control and bringing back outlines!
Middleware. A brand new feature to interface between Video.js’s techs and the player.
Feature SpotlightsOver the coming weeks, we’ll post feature spotlights talking about the big things that are happening.We might also revisit some old features.
- the transmuxer at the heart of
- we faced a problem: How do we determine if the output from Mux.js is correct?
Early on we managed to figure out how to coax FFmpeg into creating
segments that would play back in a browser with
(MSE) which at the time meant only Chrome. However, we needed a simple way to compare the output of our transmuxer with what was produced by FFmpeg. The comparison had to be aware of the MP4 format since the two outputs are extremely unlikely to be byte-identical.
MP4 files are composed of boxes - hierarchical logical units that, conveniently, all start with a 32-bit length and a 32-bit box-type. Boxes will often contain other sub-boxes.
The answer to that problem was to build an “mp4-inspector” - a tool that would parse MP4 and display a sort of JSON-like dump of any relevant boxes and their contents. By generating a dump of the output from Mux.js and comparing it to a known-good fragment generated with FFmpeg, we could see where our transmuxer’s output differed.
The “mp4-inspector” was built as a web page so that we can have a graphical color-coded diff of the two segments. Over time the page gained a video element and we started appending the results of transmuxing segments directly into the video element’s MediaSource to aid in instant feedback and validation of changes to Mux.js.
A Brave New WorldA media container such as MP4 encapsulates the video and audio stream. It has metadata describing the streams, timing information for each frame, and the stream data itself.
As development continued, we would sometimes encounter streams that would fail in new and interesting ways. Some of these failures were, admittedly, due to bugs in Mux.js. As Mux.js itself became more robust, failures were increasingly caused by problems with the streams or issues with a particular implementation of the .
It eventually dawned on us that we really needed to learn more about what was happening inside of those videos. We needed to see not just what was happening at the media container level but we had to go deeper - we needed to peek into the video data itself. For that purpose we created .
Inside of a container, video and audio are contained in data called bitstreams. Bitstreams are the data produced by encoders to represent the audio signals or video frames. Some common bitstreams are
for audio and
for video.
Thumbcoil is a suite of tools designed to give you a peek into the internals of H.264 video bitstreams contained inside either an MP4 or MPEG2-TS container file. Using the tools in
you can get a detailed view of the internal structure of the two supported media container formats.
In addition, the tools have the ability to show you the information contained within the most important NAL-units that make up the H.264 bitstream. Ever wonder what kind of secret information the video encoder has squirreled away for decoders to use? Now, with , you can finally see for yourself!
MotivationAn H.264 encoded bitstream is composed of what are called NAL, or network abstraction layer, units. NALs are a simple packet format designed to use bits as efficiently as possible.
Believe it or not, there are very few good tools to generate a somewhat graphical display of the structure of media containers and the data that they contain. Debugging problems with video playback is usually a tedious task involving various esoteric FFmpeg and FFprobe incantations. Unfortunately at it’s best, FFprobe is only able to print out a small portion of the data we were interested in.
The exact data inside of the various parameter sets for instance is not available via the command-line. Inside of FFprobe, that data is parsed and stored but there is no easy way to dump that information in a human readable form.
In H.264, there are two special types of NAL-units - the SPS or seq_parameter_set and the PPS or pic_parameter_set. These two NAL units contain a lot of information. The decoders require this information to reconstruct the video.
not only provides parameter set information in excruciating detail but also keeps the information with its surrounding context - the boxes it was contained by or the frame it was specified along with. This context is often very important to understanding issues or peculiarities in streams.
Built Upon Fancy StuffOne of the more interesting things about how
parses parameter sets is that is builds what is internally called a “codec” for each NAL unit type. These codecs are specified using what is essentially a fancy -type setup.
Much of the data in the two parameter sets are stored using a method called
This method uses a variable number of bits to store numbers and is particularly suited to values that tends to be small.
Each function used to build the codec returns an object with two functions: decode and encode. This means that we can specify the format of, say, a seq_parameter_set NAL unit just once and then we can both parse from and write to the bitstream for that particular NAL unit.
The “grammar” used to specify NAL unit codecs is very similar to the grammar used by the H.264 specification (ISO/IEC 14496-10). The data-types that the codecs in
understand are, with some extensions, merely the same types defined in the specification such as signed- and unsigned- exponential golomb encoded integers.
In addition to the parameter sets,
provides insight into the structure of the slice layers themselves by parsing the slice_header data though we stop short of parsing any of the actual slice_data because things quickly become more difficult and less useful as you descend into that madness.
But what is the deal with the name?““ doesn’t mean anything, really. It’s an inside joke that is funny to exactly 3 people in the world - myself included. The odd name does have one benefit in that it makes for a short and easy to remember domain-name: .
As with all Video.js projects,
is open-source software and we welcome suggestions, issues, and contributions at .
and run the linter as a pre-push git hook.
Fix CSS issues in IE8.
Updated dependencies using Greenkeeper.io
Make video.js provide ES5 source files for bundlers like webpack and browserify to use. This also makes video.js requirable in node.
Video.js still provides a pre-build dist files for the CSS and JavaScript for those that aren’t using bundlers.
We’ve added a grunt task called check-translations that will output a
from language files based on the
file which serves as a template. If you know another lanugage, this would be an easy and quick way to get started contriburing to video.js!
Known IssuesNo new known issues but we have started looking into the .
Looking forwardGoing forward, we’re
switching to . This will allow us to accept PRs more easily and have the changelog generated for us. Also, this will make it easier for other core contributors to accept PRs. We’ve previously been using the
tool for accepting PRs and have the CHANGELOG generated automatically at that time but getting new people started with it for merging PRs was not the easiest experience.
Raw Changelog
@misteroneill, @BrandonOCasey, and @pagarwal123 updates all the code to pass the linter ()
@misteroneill added ghooks to run linter on git push ()
@BrandonOCasey removed unused base-styles.js file ()
@erikyuzwa, @gkatsev updated CSS build to inlcude the IE8-specific CSS from a separate file instead of it being inside of sass () ()
@gkatsev added null checks around navigator.userAgent ()
greenkeeper updated karma dependencies ()
@BrandonOCasey updated language docs to link to IANA language registry ()
@gkatsev removed unused dependencies ()
@misteroneill enabled and updated videojs-standard and fixed an issue with linting ()
@misteroneill updated tests to qunit 2.0 ()
@gkatsev added slack badge to README ()
@gkatsev reverted back to qunitjs 1.x to unbreak IE8. Added es5-shim to tests ()
@gkatsev updated build system to open es5 folder for bundles and dist folder other users ()
greenkeeper updated uglify ()
greenkeeper updated grunt-concurrent ()
greenkeeper updated karma-chrome-launcher ()
@gkatsev added tests for webpack and browserify bundling and node.js requiring ()
@rlchung fixed tests that weren’t disposing players when they finished ()
Git diffstatsThese are deltas between 5.11.5 and 5.12.0 with the dist folder ignored.123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167.babelrc
4 -.gitignore
1 -.jshintrc
49 ++.npmignore
1 -.travis.yml
2 +-CHANGELOG.md
26 -Gruntfile.js
2 +-README.md
2 -build/grunt.js
| 131 ++-build/tasks/cdn-links.js
2 +-build/tasks/languages.js
35 -build/tasks/saucelabs.js
24 +component.json
2 +-docs/guides/languages.md
| 164 +++-docs/translations-needed.md
| 363 --------lang/de.json
8 +-lang/en.json
2 -lang/fr.json
19 +-package.json
80 +-src/css/_utilities.scss
2 +-src/css/components/_control-bar.scss
16 +src/css/components/_fullscreen.scss
2 +src/css/components/_play-pause.scss
2 +src/css/components/_progress.scss
2 +-src/css/components/menu/_menu.scss
3 +-src/css/ie8.css
30 -src/js/base-styles.js
18 +src/js/button.js
28 +-src/js/clickable-component.js
29 +-src/js/component.js
79 +-.../audio-track-controls/audio-track-button.js
11 +-.../audio-track-controls/audio-track-menu-item.js
18 +-src/js/control-bar/control-bar.js
39 +-src/js/control-bar/fullscreen-toggle.js
2 +-src/js/control-bar/live-display.js
2 +-src/js/control-bar/mute-toggle.js
20 +-src/js/control-bar/play-toggle.js
8 +-.../playback-rate-menu-button.js
27 +-.../playback-rate-menu/playback-rate-menu-item.js
10 +-.../progress-control/load-progress-bar.js
22 +-.../progress-control/mouse-time-display.js
22 +-.../progress-control/play-progress-bar.js
6 +-.../progress-control/progress-control.js
5 +-src/js/control-bar/progress-control/seek-bar.js
41 +-.../progress-control/tooltip-progress-bar.js
10 +-.../spacer-controls/custom-control-spacer.js
4 +-.../caption-settings-menu-item.js
18 +-.../text-track-controls/captions-button.js
13 +-.../text-track-controls/chapters-button.js
57 +-.../chapters-track-menu-item.js
18 +-.../text-track-controls/descriptions-button.js
15 +-.../off-text-track-menu-item.js
25 +-.../text-track-controls/subtitles-button.js
4 +-.../text-track-controls/text-track-button.js
17 +-.../text-track-controls/text-track-menu-item.js
36 +-.../time-controls/current-time-display.js
13 +-.../control-bar/time-controls/duration-display.js
15 +-.../time-controls/remaining-time-display.js
7 +-src/js/control-bar/track-button.js
7 +-src/js/control-bar/volume-control/volume-bar.js
12 +-.../control-bar/volume-control/volume-control.js
10 +-src/js/control-bar/volume-menu-button.js
19 +-src/js/error-display.js
5 +-src/js/event-target.js
17 +-src/js/extend.js
7 +-src/js/fullscreen-api.js
6 +-src/js/media-error.js
57 +-src/js/menu/menu-button.js
31 +-src/js/menu/menu-item.js
10 +-src/js/menu/menu.js
63 +-src/js/modal-dialog.js
20 +-src/js/player.js
| 383 ++++-----src/js/plugins.js
2 +-src/js/popup/popup-button.js
10 +-src/js/popup/popup.js
11 +-src/js/poster-image.js
7 +-src/js/setup.js
40 +-src/js/slider/slider.js
34 +-src/js/tech/flash-rtmp.js
25 +-src/js/tech/flash.js
| 157 ++--src/js/tech/html5.js
| 347 +++-----src/js/tech/loader.js
20 +-src/js/tech/tech.js
| 210 +++--src/js/tracks/audio-track-list.js
5 +-src/js/tracks/audio-track.js
10 +-src/js/tracks/html-track-element-list.js
4 +-src/js/tracks/html-track-element.js
8 +-src/js/tracks/text-track-cue-list.js
12 +-src/js/tracks/text-track-display.js
| 144 ++--src/js/tracks/text-track-list-converter.js
28 +-src/js/tracks/text-track-list.js
6 +-src/js/tracks/text-track-settings.js
| 347 ++++----src/js/tracks/text-track.js
51 +-src/js/tracks/track-enums.js
29 +-src/js/tracks/track-list.js
12 +-src/js/tracks/track.js
13 +-src/js/tracks/video-track-list.js
4 +-src/js/tracks/video-track.js
10 +-src/js/utils/browser.js
32 +-src/js/utils/buffer.js
9 +-src/js/utils/dom.js
95 +--src/js/utils/events.js
| 429 +++++-----src/js/utils/fn.js
6 +-src/js/utils/format-time.js
2 +-src/js/utils/guid.js
2 +-src/js/utils/log.js
14 +-src/js/utils/merge-options.js
14 +-src/js/utils/stylesheet.js
7 +-src/js/utils/time-ranges.js
68 +-src/js/utils/to-title-case.js
2 +-src/js/utils/url.js
29 +-src/js/video.js
53 +-test/api/api.js
| 421 +++++-----test/globals-shim.js
2 -test/index.html
2 -test/karma.conf.js
17 +-test/require/browserify.js
8 -test/require/node.js
9 -test/require/webpack.js
8 -test/unit/button.test.js
32 +-test/unit/clickable-component.test.js
31 +-test/unit/close-button.test.js
22 +-test/unit/component.test.js
| 639 +++++++--------test/unit/controls.test.js
| 101 ++-test/unit/events.test.js
| 240 +++---test/unit/extend.test.js
20 +-test/unit/media-error.test.js
69 --test/unit/menu.test.js
54 +-test/unit/modal-dialog.test.js
| 138 ++--test/unit/player.test.js
| 912 ++++++++++-----------test/unit/plugins.test.js
| 196 +++--test/unit/poster.test.js
68 +-test/unit/setup.test.js
20 +-test/unit/tech/flash-rtmp.test.js
68 +-test/unit/tech/flash.test.js
| 203 ++---test/unit/tech/html5.test.js
| 491 +++++------test/unit/tech/tech-faker.js
86 +-test/unit/tech/tech.test.js
| 438 +++++-----test/unit/test-helpers.js
71 +-test/unit/tracks/audio-track-list.test.js
| 108 ++-test/unit/tracks/audio-track.test.js
88 +-test/unit/tracks/audio-tracks.test.js
70 +-test/unit/tracks/html-track-element-list.test.js
50 +-test/unit/tracks/html-track-element.test.js
68 +-test/unit/tracks/text-track-controls.test.js
| 202 ++---test/unit/tracks/text-track-cue-list.test.js
79 +-test/unit/tracks/text-track-list-converter.test.js |
67 +-test/unit/tracks/text-track-list.test.js
23 +-test/unit/tracks/text-track-settings.test.js
| 178 ++--test/unit/tracks/text-track.test.js
| 203 +++--test/unit/tracks/text-tracks.test.js
| 401 +++++----test/unit/tracks/track-baseline.js
37 +-test/unit/tracks/track-list.test.js
| 104 ++-test/unit/tracks/track.test.js
16 +-test/unit/tracks/video-track-list.test.js
| 111 ++-test/unit/tracks/video-track.test.js
87 +-test/unit/tracks/video-tracks.test.js
71 +-test/unit/utils/dom.test.js
| 426 ++++------test/unit/utils/fn.test.js
13 +-test/unit/utils/format-time.test.js
48 +-test/unit/utils/log.test.js
26 +-test/unit/utils/merge-options.test.js
16 +-test/unit/utils/time-ranges.test.js
49 +-test/unit/utils/to-title-case.test.js
10 +-test/unit/utils/url.test.js
| 103 ++-test/unit/video.test.js
| 186 ++---166 files changed, 5233 insertions(+), 6541 deletions(-)
all the way back in 2010, Flash was the only way to play video in Firefox, IE, and the Android browser. And when you could use HTML video, it was
and broken in all sorts of scenarios (live streaming, anyone?). Those problems were a big part of why we wrote video.js in the first place. The HTML standard provided a simple, powerful, and universal API for video: why use anything else?
The superiority of HTML video is pretty well established these days and
reflects that. If you have your videos in MP4 format, video.js will play them natively in HTML on every modern desktop and mobile browser out there. In , we started the process of deprecating the last holdout in our supported browsers: the dreaded Internet Explorer 8. If you’re saying to yourself “Wha?! You still support IE8??”, I share your shock and horror. It’s no fun but we’ve been holding out for the couple folks who want to use video on their sites and still have to support ancient clients. There’s
to jump through however, and you should start emotionally preparing yourself for the end of IE8 support if you’re one of the people using it. With IE8 heading out to pasture, including a Flash fallback by default in video.js is starting to look a little silly.
So here’s what we’re thinking: move Flash support out of the core of video.js and into our
around the time
this December. We’ll keep it around for awhile to support some more complex usage (say, live streaming in IE10) but the heart of video.js will go from “HTML-first” to “HTML-only.” That should mean more focus from the core committers on some amazing new stuff like improving our plugin framework, enhancing our support for
and , and making advanced features like
easier to integrate and better for viewers.
How does that sound? Let us know in this , ping
on Twitter, or come say “hi” in our .
if you find anything.
Notable Changes
In version 5.0, we wanted to deprecate videojs.players property in favor of of the videojs.getPlayers() getter. However, it’s proved to be very useful and it is now being un-deprecated so it will no longer print deprecations in the console.
If the player is created without a source set and a user hits play, video.js will now wait for the a source to be provided before starting playback. This eliminates an error that happens when we try to play an empty source.
Our custom captions settings dialog was updated to be more accessible by using more aria attributes and better option names in drop downs.
Known Issues
In video.js 5.10, to be able to better respond to the source of the video element changing directly without going through video.js, we
and . However, this causes an . A contributor investigated and found out that the two PRs mentioned before cause the issue. If a video is created with an MPEG-DASH source element, we end up seeing a loadstart event because of the source element and then when Dash.js kicks in and starts playback using MSE, we get another loadstart event. Since we see the second loadstat event we dispose of the SourceHandler, that is, videojs-contrib-dash and Dash.js, and the video doesn’t play. A work around, while we figure out a correct solution, would be not to use source elements with DASH sources and only use the video.js API in the meantime.
Raw Changelog
@BrandonOCasey Document audio/video track usage ()
@hartman Correct documentation to refer to nativeTextTracks option ()
@nickygerritsen Also pass tech options to canHandleSource ()
@misteroneill Un-deprecate the videojs.players property ()
@nickygerritsen Add title to all clickable components ()
@nickygerritsen Update Dutch language file ()
@hartman Add descriptions and audio button to adaptive classes ()
@MattiasBuelens Retain details from tech error ()
@nickygerritsen Fix test for tooltips in IE8 ()
@mboles added loadstart event to jsdoc ()
@hartman added default print styling ()
@ldayananda updated videojs to not do anything if no src is set ()
@nickygerritsen removed unused tracks when changing sources. Fixes ##3000 ()
@vit-koumar updated Flash tech to return Infinity from duration instead of -1 ()
@alex-phillips added ontextdata to Flash tech ()
@MattiasBuelens updated components to use durationchange only ()
@misteroneill improved Logging for IE & 11 ()
@vdeshpande updated control text of modal dialog ()
@ldayananda fixed mouse handling on menus by using mouseleave over mouseout ()
@mister-ben updated language to inherit correctly and respect the attribute on the player ()
@sashyro fixed nativeControlsForTouch option ()
@tbasse fixed techCall null check against tech ()
@rbran100 checked src and currentSrc in handleTechReady to work around mixed content issues in chrome ()
@OwenEdwards fixed caption settings dialog labels for accessibility ()
@OwenEdwards removed spurious head tags in the simple-embed example ()
@ntadej added a null check to errorDisplay usage ()
@misteroneill fixed logging issues on IE by separating fn.apply and stringify checks ()
@misteroneill fixed npm test from running coveralls locally ()
@gkatsev added es6-shim to tests. Fixes Flash duration test ()
@misteroneill corrects test assertions for older IEs in the log module ()
@gkatsev fixed setting lang by looping through loop element variable and not constant tag ()
Git diffstatsThese are deltas between 5.11.0 and 5.10.71234567891011121314151617181920212223242526272829303132333435363738394041424344CHANGELOG.md
33 +build/grunt.js
3 +-component.json
2 +-docs/examples/simple-embed/index.html
3 -docs/guides/audio-tracks.md
69 +docs/guides/languages.md
12 +-docs/guides/text-tracks.md
184 +docs/guides/tracks.md
186 +-docs/guides/video-tracks.md
70 +docs/index.md
2 +-lang/en.json
1 +lang/nl.json
19 +-package.json
7 +-src/css/_print.scss
5 +src/css/components/_adaptive.scss
9 +-src/css/components/_captions-settings.scss
26 +-src/css/video-js.scss
2 +src/js/clickable-component.js
12 +-.../control-bar/time-controls/duration-display.js
8 +-.../time-controls/remaining-time-display.js
1 +src/js/menu/menu-button.js
4 +-src/js/modal-dialog.js
2 +-src/js/player.js
68 +-src/js/tech/flash-rtmp.js
3 +-src/js/tech/flash.js
21 +-src/js/tech/html5.js
73 +-src/js/tech/tech.js
16 +-src/js/tracks/text-track-settings.js
176 +-src/js/utils/browser.js
3 +src/js/utils/create-deprecation-proxy.js
50 -src/js/utils/log.js
124 +-src/js/video.js
16 +-test/globals-shim.js
1 +test/unit/button.test.js
5 +-test/unit/player.test.js
22 +-test/unit/plugins.test.js
20 +-test/unit/tech/flash.test.js
51 +-test/unit/tech/html5.test.js
16 +-test/unit/tech/tech.test.js
17 +-test/unit/tracks/text-track-settings.test.js
51 +-test/unit/tracks/text-track.test.js
13 +-test/unit/utils/create-deprecation-proxy.test.js
45 -test/unit/utils/log.test.js
104 +-103 files changed, 971 insertions(+), 55554 deletions(-)}

我要回帖

更多关于 不知道宽带账号和密码 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信