Video.js Blog 2019-01-18T19:57:55.575Z http://blog.videojs.com/ John Doe Hexo In-band Captions Support with videojs-http-streaming http://blog.videojs.com/Inband-Captions-Support-with-VHS/ 2019-01-16T18:36:32.000Z 2019-01-18T19:57:55.575Z With the release of videojs-http-streaming (VHS) v1.2.0 on July 16th 2018, Video.js has built-in support for CEA/CTA-608 captions carried in FMP4 segments. This means that closed captions are automatically parsed out and made available to Video.js players for MPEG-DASH content and HLS streams using FMP4 segments. Here’s a sample player that shows the captions (English with the “CC” button is the track with CEA-608 captions).

If you are curious about CEA-608 captions and the approach we used to parse them out of fmp4s, or a general overivew, you can watch my talk from Demuxed 2018.

Caption Parsing is handled by the mux.js library and interacts with VHS to feed parsed captions back to Video.js.

Usage

Create a CaptionParser:

1
2
3
4
5
6
7
8
import { CaptionParser } from 'mux.js/lib/mp4';

const captionParser = new CaptionParser();

// initalize the CaptionParser to ensure that it is ready for data
if (!captionParser.isInitialized()) {
  captionParser.init();
}

When working with HLS and MPEG-DASH with fmp4 segments, it’s likely that not all the information needed to parse out captions are included in the media segments themselves, and metadata from the init segment needs to be passed to the CaptionParser. For this reason, the video trackIds and timescales defined in the init segment should be passed into the CaptionParser.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import mp4probe from 'mux.js/lib/mp4/probe';

// Typed array containing video and caption data
const data = new Uint8Array();
// Timescale = 90000
const timescales = mp4probe.timescale(data);
// trackId = 1
const videoTrackIds = mp4probe.videoTrackIds(data);

// Parsed captions are returned
const parsed = captionParser.parse(
  data,
  videoTrackIds,
  timescales
);

Calling captionParser.parse with data containing CEA-608 captions will result in an object with this structure:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
  captions: [
    {
      // You can ignore the startPts and endPts values here
      startPts: 90000,
      endPts: 99000,
      // startTime and endTime can be used for caption times in the TextTrack API
      startTime: 1,
      endTime: 1.1,
      text: 'This is a test caption',
      // This is the CEA-608 "channel" the caption belongs to
      stream: 'CC1'
    }
  ],
  // Includes any (or none) of: CC1, CC2, CC3, CC4
  // This should match the captions returned in the above caption array
  captionStreams: {
    CC1: true
  }
};

You can then take one caption and create a VTTCue to add to a TextTrack with Video.js APIs

1
2
3
4
5
6
7
8
9
const player = videojs('video');
const track = player.addRemoteTextTrack({
  kind: 'captions',
  label: parsed.captions[0].stream,
  default: true,
  language: 'en'
}, false);

track.addCue(parsed.captions[0]);

VHS is included by default with videojs v7.x.

]]> <p>With the release of <a href="https://blog.videojs.com/introducing-video-js-http-streaming-vhs/">videojs-http-streaming</a> (VHS) v1.2.0 o Video.js 7.4 http://blog.videojs.com/Video-js-7-4/ 2019-01-11T16:24:34.000Z 2019-01-18T19:57:55.603Z It’s time to have an overview of Video.js 7.4, first released early December. The big new feature for this release is a UI that allows you to seek during live streams. We updated focus-visible to work with our Menus, added more translations, added a replay option to the Play/Pause button, and many, many fixes, multiple of which are accessibility related.

We also dropped our usage of Grunt from our build process. We owe a lot to Grunt as it has served us well but it was time to move on.

Video.js 7.4.1 is currently the latest release with 7.4.2 out as a pre-release until next week.

Thanks

Before continuing, I’d like to thank everyone that was involved, we really appreciate your contributions! There were a total of 14 first time contributors, I think this is a historic high for us and I hope this continues!

Live UI

Video.js has supported live streams for a while, either natively, or via videojs-http-streaming (VHS). However, this UI was very minimal, it disabled the progress bar and basically only allowed pausing, though, there was an indicator that this was a live stream.

Video.js, with the new Live UI, playing a live stream

The new UI looks pretty similar to the previous live UI and the regular control bar. The “live” indicator moves to the right side of the progress bar and also indicates whether we are playing back live or we are behind live. Clicking this button will seek to the “live point”. The time displays and tooltips will show time with respect to the live point; so, current time at the live point will be 0 and if you seek back 30 seconds it’ll show -00:30.

This feature is still somewhat experimental, so, it is behind an option that is off by default. We hope that you try it out and give us feedback and that we can enable it by default in a future release.

To enable the feature, pass in liveui: true to the player:
In JavaScript:

1
2
3
4
var player = videojs('my-id', {
  liveui: true
  }
);

Or HTML:

1
2
3
<video-js id="my-id" data-setup='{"liveui": true}'}>
  <source src="https://example.com/live.m3u8" type="application/x-mpegurl">
</video-js>

Languages

We’ve had a bunch of language additions and updates in the 7.4 release line. In addition, we now copy the JSON files into the dist/lang folder for easier inclusion your projects.

Languages added and updated

  • Occitan (oc)
  • Russian (ru)
  • Welsh/Cymraeg (cy)
  • Ukrainian (uk)
  • Serbian (sr)
  • Swedish (sv)

Accessibility

As always, we aim to make Video.js as accessible and usable as we can. To that end, we’ve had a bunch of accessibility related fixes in these releases.

  • Time displays accessibility with VoiceOver
  • remove hidden control text in progress bar
  • make the seek-to-live button announce itself to screen readers properly
  • Make the - in the remaining time display be visual only and not readable by screen readers

Other Features Updates

Responsive Captions Settings Dialog

This uses the new responsive setting and breakpoints to make the dialog respond to the size of the player and improves the user experience.

replay option for PlayToggle

The PlayToggle button changes the icon to a replay icon when the video ends, most users don’t mind it and it was a highly requested feature previously. This adds an option to turn it off.

focus-visisble menu backgrounds

Like outlines for other buttons, we use a different background color to represent the focus in menus. We should respect focus-visible there like we do for outlines in buttons.

playerreset event

When the player is reset with the reset() method, it’ll now trigger a playerreset event to let components and users know.

Other Fixes

  • Fix fullscreen event triggering twice (7.4.2)
  • PlayToggle cursor pointer
  • select default subtitles on loadedmetadata not loadstart
  • don’t apply user preference to subtitles if no language is set
  • make sure that vjs-waiting is only removed if we started playback again
  • allow duration to be set to NaN, making Video.js more spec compliant
  • fix locking menus when the menu button is pressed
  • remove child component from old parent when moving the component to a new parent
  • remove vjs-ended when seeking after video has ended
  • don’t autohide the control bar when hovering with the mouse

Full CHANGELOG for 7.4.0, 7.4.1, and 7.4.2

7.4.2 (2019-01-08)

Bug Fixes

  • Control-bar autohide when cursor placed over it #5258 (#5692) (6ebc772)
  • css animation shorthand property order (#5687) (0e69ce9)
  • fs: make sure there’s only one fullscreenchange event (#5686) (2bc90a1), closes #5685
  • lang: adds sv translation used by liveui component (#5704) (f38726e)
  • package: update @videojs/http-streaming to version 1.6.0 🚀 (#5705) (3d093ed)
  • player: remove vjs-ended class on seeked (#5728) (f1637cd), closes #5654
  • remaining-time-display: make the ‘-‘ be visual and not readable by screen readers (#5671) (05513f8), closes #5168
  • seekbar: don’t disable if live tracker’s seekable is infinity (#5721) (7f507df)
  • remove child from old parent when moving to new parent via addChild (#5702) (8a3e2a7)

Chores

Documentation

  • liveui: Add a guide for the live ui and live api (#5677) (c147581)

7.4.1 (2018-12-11)

Bug Fixes

Chores

  • package: update autoprefixer to version 9.4.2 (#5647) (19f3465)
  • package: update rollup-plugin-node-resolve to version 4.0.0 🚀 (#5666) (d07b6c2)

Documentation

  • remove grunt and update usage of build scripts (#5656) (62f9e78)

Tests

  • verify null-checks with player and control bar children set to false (#5670) (13b42ad)

7.4.0 (2018-12-03)

Features

Bug Fixes

  • add correct cursor pointer for the play toggle (#5463) (aed337a)
  • default subtitles not enabled (#5608) (8329e64)
  • tracks: don’t select tracks based on user pref if no langauge is set (#5556) (c1cbce3), closes #5553
  • Don’t remove vjs-waiting until time changes (#5533) (0060747)
  • lang: add is loading ru translation (#5630) (0090b75)
  • lang: Occitan: harmonisation plural/singular (#5602) (4842201)
  • package: update @videojs/http-streaming to version 1.4.2 🚀 (#5543) (dbaca33)
  • package: update @videojs/http-streaming to version 1.5.0 🚀 (#5587) (d95ef6f)
  • duration reset and allow duration NaN or 0 for duration display (#5348) (ab0e29a), closes #5347
  • not inline volume slider showing up after mouse hovering on it (#5503) (7d127c8), closes #5502 #5505
  • vjs-lock-showing class gets removed from menu when no longer hovering on menu-button. (#5465) (58f638e), closes #1690

Chores

Documentation

]]> <p>It’s time to have an overview of Video.js 7.4, first released early December. The big new feature for this release is a UI that allows yo Bugpost: Disconnects and Reconnects http://blog.videojs.com/Bugpost-Disconnects-and-Reconnects/ 2018-12-17T15:00:44.000Z 2019-01-18T19:57:55.569Z In my old apartment, whenever I nuked a bowl of oats in the microwave, my WIFI cut out. It was an annoyance, but I was hungry, the apartment was too small to move the router further from the microwave, and I didn’t want to buy anything that operated on a different frequency. So I’d start the microwave, watch whatever video was streaming on my laptop until the buffer ran out, then watch the loading spinner until the microwave gave the triple ding.

Thankfully, video players are usually pretty robust against such issues as network connectivity (and rogue microwaves), and the video resumed after the network recovered. But recently, we found that for some content played in Video.js, the video didn’t resume. Even worse, the loading spinner simply disappeared, leaving a frozen frame on screen.

You can see this behavior yourself by checking out Video.js 7.3.0, loading https://dash.akamaized.net/akamai/bbb_30fps/bbb_30fps.mpd as the source, and using Chrome Dev Tools to disconnect and reconnect the network.

Here’s a quick tour of what happened and how we fixed it.

The Loading Spinner

To approach the bug, we started with the most glaring problem, the disappearance of the loading spinner. The spinner is managed by Video.js. In the code, the vjs-waiting class is added to the HTML element when the tech triggers a waiting event, and is removed on the next timeupdate event.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/**
 * Retrigger the `waiting` event that was triggered by the {@link Tech}.
 *
 * @fires Player#waiting
 * @listens Tech#waiting
 * @private
 */
handleTechWaiting_() {
  this.addClass('vjs-waiting');
  /**
   * A readyState change on the DOM element has caused playback to stop.
   *
   * @event Player#waiting
   * @type {EventTarget~Event}
   */
  this.trigger('waiting');
  this.one('timeupdate', () => this.removeClass('vjs-waiting'));
}

After logging the events emitted by the player, the issue became clear. Some browsers emitted a timeupdate event immediatley after the waiting event.

So timeupdate events themselves were not reliable, but what else could be used to make a better determination of if we’re waiting? We checked player.currentTime() on the timeupdate events, and found that when we caught the last timeupdate event, the one after the waiting event, the player was at the same time as the timeupdate event prior to the waiting event (and the same time as when the waiting event was triggered).

1
2
3
4
`timeupdate` triggered, player.currentTime = 11
`timeupdate` triggered, player.currentTime = 11.250
`waiting` triggered, player.currentTime = 11.250
`timeupdate` triggered, player.currentTime = 11.250

The fix was pretty easy. Simply record the player’s time when it gets the waiting event, and instead of removing the vjs-waiting class on the next timeupdate, remove the vjs-waiting class on the next timeupdate that has a different time from the one we recorded.

You can see the PR for that here, and it is available in Video.js 7.4.0.

Resuming Playback after Disconnecting

With the loading spinner back, the next issue was to determine why, when the network reconnected, the video did not resume. First, we tested a few different pieces of content. The HLS source we tested did reconnect, but the DASH source didn’t. Worse, when using the DASH source, Chrome’s debug console froze, as it racked up request and console errors as fast as the computer could process them.

Console Crash

Imagine your console filled with the following two messages repeated thousands of times:

1
2
GET https://dash.akamaized.net/akamai/bbb_30fps/bbb_a64k/bbb_a64k_8.m4a net::ERR_INTERNET_DISCONNECTED
VIDEOJS: WARN: Problem encountered with the current HLS playlist. Trying again since it is the final playlist.

When your console freezes, debugging can be tough. It’s like trying to watch a video when the microwave is on. So we tackled that issue first.

Looking at the error message, we were repeatedly retrying the last rendition. That is expected behavior, as we added it a long time ago to our HLS playlist loader. However, when we added DASH support, we created a different playlist loader, and we never added the same logic for reloading the final DASH playlist.

After adding the throttle, debugging became much easier, and we were able to use the console once again and dig into why DASH didn’t reconnect while HLS did.

Multiple Requests Multiple Problems

The last problem proved to be the most difficult to debug. Initially, the thought was that demuxed content was the problem, as having a separate audio segment loader to load from the audio playlist could cause trouble when experiencing errors at the same time as the main segment loader tried to load from the video playlist. However, HLS can also have demuxed content, and after an example source proved to resume just fine, that approach was ruled out.

By examining Chrome’s network log, the DASH content, after a certain point, stopped requesting video segments, and only requested audio segments. But there were more than just two requests for DASH. The video segments themselves included two requests: one for the init segment, and the other for the video data.

Requests in VHS are managed by a module called media-segment-request, which is responsible for requesting everything required for a segment, whether it be the key, the init segment, the media data, or all of them, before letting the segment loader know that its requests are done. And for the video requests, the media-segment-request never called the done callback after the disconnect.

It turned out that if we received one error, we aborted the other requests in that group, and waited to call the done callback until those requests reported that they were aborted. However, according to the XHR standard, the abort algorithm may not be run if the request was unsent. In this case, when the network disconnected, the first request reported an error before the second had a chance to be sent. After we aborted the second request, we were stuck waiting for an error that would never come.

We fixed that by immediately calling back with an error on the first error we encounter instead of waiting for each subsequent request to finish.

The problem should also have existed in HLS, but only in cases where the segments had an EXT-X-KEY or EXT-X-MAP tag to go along with the media request. In the content we tried, neither of those was present, so it appeared to be isolated to DASH content.

Bug Solved

We hope that was somewhat useful in describing some of the bugs we encounter, how we go about investigation, and what the resolutions look like. We’d be happy to hear from you as well. You can find us on the #playback channel in the Video.js Slack, or navigating Issues and PRs at https://github.com/videojs/http-streaming.

Now to enjoy my oats and video, without any concerns about the playback resuming.

]]> <p>In my old apartment, whenever I nuked a bowl of oats in the microwave, my WIFI cut out. It was an annoyance, but I was hungry, the apartm Introducing Video.js HTTP Streaming (VHS) http://blog.videojs.com/Introducing-Video-js-HTTP-Streaming-VHS/ 2018-11-08T11:33:01.000Z 2019-01-18T19:57:55.575Z

“How do I get my video to play with Video.js?”

This is one of the most frequent questions we get when working on Video.js. And it’s a good question.

If someone checks out a copy of Video.js, their content may play on one browser and not another. To get cross browser support for a specific type of content, they must stumble upon a relevant source handler (for instance, videojs-contrib-hls for HLS content). Only after including the source handler will their video play across all major browsers.

We want Video.js to be easy to use, and that isn’t the easiest setup. So we decided that it’s time to address the issue.

This was the motivation behind integrating Video.js HTTP Streaming (nicknamed VHS) inside of Video.js 7 by default.

What is VHS?

VHS is the successor to videojs-contrib-hls. It is a source handler forked from the videojs-contrib-hls repository. While videojs-contrib-hls was originally designed to add HLS playback on all browsers, we realized that the engine could also play other formats just as well.

To prove this, we added a DASH manifest parser, and with a few minor changes, VHS played DASH content with the same codebase and API as it used for HLS.

Even with the changing landscape of video technologies, Video.js will be ready. If a new streaming format gains popularity, only a few code changes will be necessary to add support to VHS. One engine and API for all formats.

Why is VHS included by default in Video.js?

By including VHS by default in Video.js, you no longer have to worry about what browser supports what streaming technology.

Video.js was built to abstract away differences in video APIs and features between web browsers, creating one simple API as close to the web standards as possible, and filling in feature gaps where possible. Over time, one area where browsers have diverged is in their support of different media formats. Some browsers may support native playback of DASH, others of HLS, and some support neither.

Previously, this would be managed by including source handlers and plugins, but we understand the importance of having a simple setup. By including VHS by default in Video.js, you no longer have to worry about what browser supports what streaming technology. It should just work.

What if I want to opt-out of using VHS?

If you would rather include a different source handler for HLS or DASH playback, Video.js still allows you to do that. Video.js core is the Video.js you know and love, without the inclusion of VHS. Everything should work as it used to.

Contributions and Feedback Welcome

As always, we’d love your contributions and feedback. The best way to reach us for comments, questions, requests, contributions, or just to say hello are the VHS GitHub page and the #playback channel on the Video.js slack.

]]> <blockquote> <p>“How do I get my video to play with Video.js?”</p> </blockquote> <p>This is one of the most frequent questions we get when w Video.js 7.3: Responsive Layout, Fill Mode, createLogger http://blog.videojs.com/Video-js-7-3-Responsive-Layout-Fill-Mode-createLogger/ 2018-10-29T17:44:42.000Z 2019-01-18T19:57:55.603Z Another month, another Video.js release: v7.3.0. This release brings a long wanted feature: Responsive Layout.
In addition, Fill Mode has been promoted to a first-class feature and createLogger was added to make debugging and logging easier.

This is currently out as a pre-release and will be promoted to latest in about a week. Please try it out and report any issues you find.

Thanks

I’d like to thank everyone that was involved in making changes that landed in this release. Any and all changes are really appreciated.

Responsive Mode

Responsive Mode will make the player adjust UI components to the size of the player. It uses the playerresize event that was added in v6.7.0 of Video.js, which allows us to know when the player changes sizes.

Responsive mode will set and change certain breakpoint classes like vjs-layout-small when the player size changed. These can be configured. Depending on which class is currently on the player, the control bar and other UI elements can adapt. For example, with vjs-layout-small, the time controls will not show because the time tooltips on the progress bar are available and the captions button is more important. At a larger size, both can be shown without a problem.

You can find out how to enable Responsive Mode and more in our docs page. There is also an example playground in the sandbox folder in the repo.

Fill Mode

Fill Mode allows the Video.js player to resize dynamically, but stay contained within the bounds of the parent container. This is analogous to Fluid Mode, but sometimes you the container is already being sized properly.

Fill Mode is not a brand new mode, the class vjs-fill has been available in Video.js for quite a while. This finally makes it a first-class feature to go along with Fluid Mode.

createLogger

This is a new method on videojs.log that allows you to create a new logger with a specific name. It then creates a chain of names to make it easier to track which component logged this particular message. In particular, this can help plugin authors to log messages and then filter out only the messages that are associated with their plugin.

createLogger returns a function with the same API as videojs.log. You can see it in action below.

Examples

A new method, player.log was added which uses createLogger behind the scenes. It logs the player ID in addition to VIDEOJS:

1
2
3
4
var player = videojs('myid');

player.log('foo');
// VIDEOJS: myid: foo

You can also go further and create a sub logger:

1
2
3
4
5
var player = videojs('myid');
var mylog = player.log.createLogger('my-plugin');

mylog.log('foo');
// VIDEOJS: myid: my-plugin: foo

If you want to log a warning or error for your custom plugin:

1
2
3
4
5
6
7
8
var player = videojs('myid');
var mylog = player.log.createLogger('my-plugin');

mylog.log.warn('foo');
// VIDEOJS: myid: my-plugin: WARN: foo

mylog.log.error('bar');
// VIDEOJS: vid1: my-plugin: ERROR: bar
]]> <p>Another month, another Video.js release: <a href="https://github.com/videojs/video.js/releases/tag/v7.3.0" target="_blank" rel="external" Video.js 7.1 and 6.11: Autoplay and Fullscreen changes http://blog.videojs.com/Video-js-7-1-and-6-11-Autoplay-and-Fullscreen-changes/ 2018-07-10T17:02:47.000Z 2019-01-18T19:57:55.601Z

It’s been a while since the last release post. The 7.1.0 and 6.11.0 releases of Video.js are full of great features from contributors and maintainers.
The two big changes are related to autoplay – when will we stop talking about autoplay? – and fullscreen. Though, there’s plenty more in there.

Video.js 7.1.0 and 6.11.0 are out as next and next-6 respectively on npm.

To get 7.1.0 via npm:

1
npm install video.js@next

And 6.11.0 via npm:

1
npm install video.js@next-6

Autoplay

We’ve been keeping track of changes happening around autoplay in browser vendors. We’ve also done a lot of work to make Video.js work as well as possible with the new autoplay policies. However, there were still some use cases that weren’t accounted for. To address those, we decided to extend the existing Video.js autoplay option to include a few new values: muted, play, any. The current boolean options will work as they do now and unknown options will be treated as they do now.

  • muted - this will mute the video element before calling play() on loadstart.
  • play - this will call play() on loadstart. This is similar to the autoplay attribute but with a call to play instead of using the attribute.
  • any - this will call play() on loadstart but if it fails, it will try and mute the player and try play()ing again.

Fullscreen

There are two fullscreen related changes in these releases.

The first one is one that was often request and it’s finally here: double click to toggle fullscreen. Double clicking inside the player area – outside of the control bar and modal dialogs – will enter or exit fullscreen playback.

The second change is to disable the fullscreen toggle if fullscreen is not available, for example, inside of an iframe without allowfullscreen attribute

Fullscreen available
Fullscreen unavailable

Notable Changes

  • Make audio tracks that are of “main-desc” kind show up with an Audio Description icon
  • Run our CSS through autoprefixer which reduces the output size a bit.
  • Make the mute toggle show up if muting is possible even if changing volume programmatically isn’t. For example, on iOS.
  • Make setSource be option for middleware.

Thanks

I’d like to thank everyone that contributed to this release!

]]> <p><img src="/Video-js-7-1-and-6-11-Autoplay-and-Fullscreen-changes/header.png" alt=""></p> <p>It’s been a while since the last release post Video.js 7 is here! 🎉 http://blog.videojs.com/Video-js-7-is-here/ 2018-05-11T17:31:52.000Z 2019-01-18T19:57:55.606Z

I’m happy to announce that Video.js 7 is now out! It brings to Video.js support for HLS and experimental DASH support via the Video.js HTTP Streaming (VHS) project. Video.js 7 also drops support for some older Internet Explorer browsers only keeping support for IE11.

While it’s out, it’s still in pre-release for a short while and only available under the next tag on npm. Some time next week, we’ll flip the switch and make it latest.

changes for removing IE8 code
This release is pretty exciting because it means we were able to remove a bunch of code for old browsers and we can now start using newer web platform features that we had previously been avoiding like the :not() css selector. It’ll also free us to look forward at new features and not be held back by needing to support old browsers like IE8.

Getting Video.js 7

You can get it from npm via

1
npm install video.js@next

or

1
npm install video.js@7.0.0

From GitHub Releases,

Or from our or another CDN

1
2
https://vjs.zencdn.net/7.0.0/video.min.js
https://vjs.zencdn.net/7.0.0/video-js.css

1
2
https://unpkg.com/video.js@7.0.0/dist/video.min.js
https://unpkg.com/video.js@7.0.0/dist/video-js.css
1
2
https://cdnjs.cloudflare.com/ajax/libs/video.js/7.0.0/video.min.js
https://cdnjs.cloudflare.com/ajax/libs/video.js/7.0.0/video-js.css

VHS and Video.js

Video.js will be bundling VHS by default for ease of use for new users. However, some people don’t want VHS or are using another plugin. For this, we have a separate build of Video.js which doesn’t include VHS.

You can get it from our CDN or another CDN

1
https://vjs.zencdn.net/7.0.0/alt/video.core.min.js

1
https://unpkg.com/video.js@7.0.0/dist/alt/video.core.min.js
1
https://cdnjs.cloudflare.com/ajax/libs/video.js/7.0.0/alt/video.core.min.js

Finally, expect a more detailed post about VHS in the weeks to come.

What the future holds

Video.js hasn’t really had a roadmap for a long time. With this release, we think it’s time to take a step back and create a roadmap.

The roadmap will take into account currently open issues and internal and external feature requests. In addition, we’re going to look at currently available features and see if it’s worth refactoring them with the more modern web in-mind.

Later down the line, we’d also want to make a roadmap for a Video.js 8. Given that this release only adds VHS and removes old browsers, there’re plenty of already deprecated features that it’s time to remove.

Updates from the Video.js 7 roadmap

Video.js 5.x

As of this release, Video.js 5.x is now officially deprecated. This means that we will no longer work on it or back-port fixes to it but it’s still available for usage if you’re still using it. We do urge you to update to the latest 5.x, or better yet, upgrade to 6.x or 7.

Build Tools

In the roadmap post, we talked about potentially switching to webpack from Rollup for better support of importing VHS into Video.js. However, while doing this work, we found out that the filesize of Video.js will increase by about 20%, which isn’t a trivial amount, not to mention that the filesize is already going to increase from the default inclusion of VHS.

Eventually, after much work, we were able to figure out how to bundle VHS using Rollup as well and we are continuing to use Rollup for our builds.

Google Analytics

Video.js 7’s CDN builds will no longer send any data to Google Analytics via our stripped down pixel tracking.

Video.js 6 and below CDN builds will continue sending data, unless you opt out with window.HELP_IMPROVE_VIDEOJS = false, but versions 6.8 and above will honor the Do Not Track option that users can set in their headers before sending the data.

We are continuing to investigate our options for collecting our CDN logs in an open manner and will post updates when we have any.

]]> <p><img src="/Video-js-7-is-here/vjs 7 small.png" alt=""></p> <p>I’m happy to announce that Video.js 7 is now out! It brings to Video.js sup Autoplay Best Practices with Video.js http://blog.videojs.com/Autoplay-Best-Practices-with-Video-js/ 2018-04-17T14:49:43.000Z 2019-01-18T19:57:55.568Z tl;dr
  • Never assume autoplay will work.
  • Using the muted attribute/option will improve the chances that autoplay will succeed.
  • Prefer programmatic autoplay via the player.play() method, avoiding the autoplay attribute/option.

Introduction

There has been a lot of chatter about autoplay lately and we wanted to take a few minutes to share some best practices when using autoplay with Video.js.

This post is meant to be a source of information - not an editorial or positional statement on autoplaying video. A lot of users hate autoplay because it’s annoying or it consumes precious bandwidth. And a lot of publishers providing content free of charge rely on autoplay for the preroll ads that finance their businesses. Browser vendors (and open source library authors) have to weigh these concerns based on the interests of their users, publishers across the web, and their own business. And users have to choose the browser that best reflects their preferences.

This post is not about ways to circumvent autoplay policies. That’s not possible and no one should waste their time attempting it. We think it’s uncontroversial to say that actively circumventing the browser’s built-in user experience or user preferences is harmful.

Autoplay Policies in the Big Browsers

I’m not going to go into exhaustive detail on each browser’s specific algorithms because they are subject to change and it would defeat the core point of this post: never assume autoplay will work.

Safari

As of Safari 11, which shipped in September 2017, Apple has updated their autoplay policies to prevent autoplay with sound on most websites.

Chrome

Back in September 2017, Google announced that Chrome’s autoplay policy would change in April 2018 with Chrome 66, subject to a series of rules you can read about in the linked article.

Firefox

With Firefox, Mozilla has taken the position of not having a firm autoplay policy for the time being. That may change in the future. That said, Firefox today does allow users to disable autoplay with a few configuration changes.

IE11 and Edge

Microsoft’s browsers have no specific/known autoplay policy - at the time of writing, autoplay just works in IE11 and Edge.

Refresher on How to Request Autoplay in Video.js

Note how the title of this section uses the word “request.” That’s intentional because it should be thought of as a request. Remember, never assume autoplay will work.

One of Video.js’ strengths is that it is designed around the native <video> element interface; so, it will defer to the underlying playback technology (in most cases, HTML5 video) and the browser. In other words, if the browser allows it, Video.js allows it.

There are two ways to enable autoplay when using Video.js:

  1. Use the autoplay attribute on either the <video> element or the new <video-js> element.

    1
    2
    <video autoplay src="https://path/to/source.mp4"></video>
    <video-js autoplay src="https://path/to/source.mp4"></video-js>

  2. Use the autoplay option:

    1
    videojs('player', {autoplay: true});

By default, you can defer to the default behavior in Video.js. If autoplay succeeds, the Video.js player will begin playing. If autoplay fails, the Video.js player will behave as if autoplay were off - i.e. it will display the “big play button” component over the poster image (or a black box).

If that works for you, your job is done!

TIP: If you want to use autoplay and improve the chances of it working, use the muted attribute (or the muted option, with Video.js).

Beyond that, there are some general practices that may be useful when dealing with autoplay: detecting whether autoplay is supported at all, or detecting whether autoplay succeeds or fails.

Detecting Autoplay Support

Similar to detecting successful or failed autoplay requests, it may be useful to perform autoplay feature detection on the browser before creating a player at all. In these cases, the can-autoplay library is the best solution. It provides a similar Promise-based API to the native player.play() method:

1
2
3
4
5
6
7
canAutoplay.video().then(function(obj) {
  if (obj.result === true) {
    // Can autoplay
  } else {
    // Can not autoplay
  }
});

Programmatic Autoplay and Success/Failure Detection

For those who care whether or not an autoplay request was successful, both Google and Apple have recommended the same practice for detecting autoplay success or rejection: listen to the Promise returned by the player.play() method (in browsers that support it) to determine if autoplay was successful or not.

This can be coupled with the autoplay attribute/option or performed programmatically by calling player.play(), but we recommend avoiding the autoplay attribute/option altogether and requesting autoplay programmatically:

1
<video-js id="player" src="https://path/to/source.mp4"></video-js>
1
2
3
4
5
6
7
8
9
10
11
12
13
var player = videojs('player');

player.ready(function() {
  var promise = player.play();

  if (promise !== undefined) {
    promise.then(function() {
      // Autoplay started!
    }).catch(function(error) {
      // Autoplay was prevented.
    });
  }
});

NOTE: It’s important to understand that using this approach, the Video.js player.autoplay() method will return undefined or false. If you expect your users or integrators to rely on this method, consider the following section.

Programmatic Autoplay with the autoplay Attribute/Option

When building a player for others to use, you may not always have control over whether your users include the autoplay attribute/option on their instance of your player. Thankfully, combining this with programmatic autoplay doesn’t seem to have a significant effect on the behavior of playback.

Based on our experimentation, even if the browser handles the actual autoplay operation, calling player.play() after it’s begun playing (or failed to play) does not seem to cause current browsers to trigger an extra "play" event in either Chrome or Firefox. It does seem that Safari 11.1 triggers "playing" and "pause" events each time player.play() is called and autoplay fails.

Still, if you have full control, we recommend avoiding the autoplay attribute/option altogether and requesting autoplay programmatically.

NOTE: Even if using the autoplay attribute/option with programmatic autoplay, the player.autoplay() method will return undefined until the player is ready.

Example Use-Case

At Brightcove, one thing we’ve done to improve the user experience of our Video.js-based player is to hide the “big play button” for players requesting autoplay until the autoplay either succeeds or fails. This prevents a periodic situation where the “big play button” flashes on the player for a moment before autoplay kicks in.

While our actual implementation has more complexity due to specific circumstances with our player, the gist of it is the same as this functional JSBin demonstration.

Conclusion

There may be decision points in your code related to whether autoplay succeeds or not; however, the practical reality is that all the paragraphs before this boil down to a single, essential concept:

Never assume that your request to autoplay will succeed.

Keep that in mind and you’re golden. Even if the browsers stop allowing autoplay entirely, our hope is that recommending this approach will be somewhat future-proof.

]]> <h2 id="tl-dr"><a href="/Autoplay-Best-Practices-with-Video-js/#tl-dr" class="headerlink" title="tl;dr"></a>tl;dr</h2><ul> <li>Never assume videojs-contrib-ads 6 http://blog.videojs.com/videojs-contrib-ads-6/ 2018-03-13T15:22:57.000Z 2019-01-18T19:57:55.606Z A major update to videojs-contrib-ads has been released. In this post, we’ll take a look at what videojs-contrib-ads offers and what has improved in version 6.

What is contrib-ads?

Videojs-contrib-ads is a framework for creating Video.js ad plugins. Seamlessly integrating ad support into a video player can be a daunting task, especially if you have other plugins that may be effected. For example, playing ads may result in additional media events. Imagine an analytics system that listens to “loadstart” events: it would start seeing double when extra loadstart events result from preroll ads. contrib-ads has a feature called Redispatch that makes sure ads do not trigger extra media events. This keeps things as simple as possible without breaking other plugins. Additional benefits of using contrib-ads are listed in the readme.

Version 6

Version 6 of contrib-ads is a maintenance release that includes a major code refactor. The core of the project’s behavior is handled by a state machine that advances through various states as the player plays content, preroll ads, midroll ads, and postroll ads. The initial state machine was designed to implement a specific set of functionality when the project was first conceptualized. Over the years, the project became much more fully-featured and many new scenarios and edge-cases arose. In this refactor, the state machine has been updated to precisely match the modern feature-set. This has resulted in a more maintainable and reliable codebase.

How it works

Ad mode is strictly defined as if content playback is blocked by the ad plugin.

contrib-ads has a concept called ad mode. Ad mode is strictly defined as if content playback is blocked by the ad plugin. This does not necessarily mean that an ad is playing. For example, if there is a preroll ad, after a play request we show a loading spinner until ad playback begins. This is considered part of ad mode. The public method player.ads.isInAdMode() can be used to check if we are in ad mode.

In version 6, the state machine was refactored to match this strict definition of ad mode. There are two types of states: content states and ad states. If contrib-ads is in an ad state, it is in ad mode.

Here is a diagram of the new states. Blue states are content states and yellow states are ad states:

For a history of how the state machine has evolved over time, there is detailed information in this Github issue. In this article we’re going to focus on how it works in version 6.

Let’s walk through the states for a simple preroll scenario. contrib-ads begins in the BeforePreroll state. This is considered a content state because content playback hasn’t been requested yet and so ads are not blocking playback. The ad plugin can asynchronously request ads from an ad server during this time, even though the plugin is in content mode. The ad plugin triggers the adsready event when it’s ready. Contrib-ads knows that once the play button is pressed, ads are already prepared.

Now the user clicks play. At this point ad mode begins and contrib-ads moves forward to the Preroll state. The Preroll state shows a loading spinner until ad playback begins. The Preroll state knows that the ad plugin is ready and that play was clicked, so triggers readyforpreroll to inform the ad plugin that it’s time to play an ad. Once ad playback begins, the control bar turns yellow and will not allow seeking. If the ad takes too long to begin playing, a timeout will occur and content will resume without further adieu. When the ad is complete, contrib-ads restores the content video. Only when content playback results in a playing event does ad mode end.

Now we’re in the ContentPlayback state. At this point, the ad plugin could play a midroll ad, causing a brief foray into the Midroll state, or content could continue without interruption.

When content ends, normally we would see an ended event right away. Instead, contrib-ads sends a contentended event, which is the ad plugin’s chance to play postroll ads. Perhaps the ad plugin has decided not to play postroll ad, so it responds by triggering nopostroll. contrib-ads knows that now we’re really done, so an ended event is triggered.

Finally, since content has ended for the first time, we now transition to the AdsDone state. There will be no more ads, even if the user seeks backwards and plays through the content again.

Conclusion

Ads may not be your favorite part of watching video online, but contrib-ads makes sure that they don’t break your site and that content plays even if ads fail. If you’re interested in learning more or contributing to the project, check it out on Github!

]]> <p>A major update to <a href="https://github.com/videojs/videojs-contrib-ads/" target="_blank" rel="external">videojs-contrib-ads</a> has be Video.js 7 Roadmap http://blog.videojs.com/Video-js-7-Roadmap/ 2018-03-09T16:33:56.000Z 2019-01-18T19:57:55.604Z

Today, I’m excited to announce the roadmap to Video.js 7! While this is a major version update, there is very little that is actually breaking. The two main changes are the addition of videojs-http-streaming, VHS for short, and the removal of support for older versions of Internet Explorer.

VJS 7

Video.js HTTP Streaming

VHS used to be videojs-contrib-hls, but as MPEG-DASH became more popular, we realized that we wanted to support it as well and that we can share a lot of the code between HLS and DASH implementations. Look for more details in an announcement post for VHS soon!
VHS will ship with Video.js by default because one of the guiding principles of Video.js is to make it easy for users to just put it on the page and have a player that works across browsers. With HLS and DASH becoming so popular, we thought it was about time for a plug and playable Video.js for the most common streaming formats.
In addition to having it be included by default, we’ll make sure to provide builds that exclude VHS for those that don’t need it or are using another playback engine like HLS.js.

Old IE

IE8

Video.js has a long history of making best effort to support IE, starting with the Flash fallback originally created for IE8. When Video.js 5 was released, we had a lot of code in place to support IE8 and when Video.js 6 came around, with Flash on its way out, we moved Flash support to a separate project, videojs-flash. Now, based on usage data, we are planning to remove support for IE8, IE9, and IE10.
According to the data we’ve gathered, IE in total has a share of about 4%. Of those 4%, IE8, IE9, and IE10 combined make up barely 5%, and IE11 has around 91% usage. This means that combined IE8, IE9, and IE10 are barely 0.002% of the total usage of Video.js. Based on this incredibly small footprint, we believe it isn’t worth the substantial effort required to maintain support for these browsers. The good news is, for those concerned, Video.js 6 isn’t going away anytime soon and will be available for your old IE support needs.
In addition to the statistics, our tests currently take between 5 and 10 minutes to run on IE8. Removing this will allow us to greatly decrease the duration of our test suite. Even worse, sometimes the tests timeout and retry for up to 40 minutes but when they restart they pass on the first try. Not having to deal with these types of issues will allow us to increase our testing infrastructure and provide a better product.


Thanks Browserstack for sponsoring browser-based testing for Video.js!

Video.js 5.x

When Video.js 7 is released it’ll be the end-of-life for Video.js 5.x from a support perspective. Of course, we are not going to unpublish this version from npm or remove the files from the CDN, so you are free to continue using it. However, we urge you to update at your earliest convenience as we will no longer be accepting fixes.

Google Analytics


Thanks Fastly for sponsoring vjs.zencdn.net

Video.js provides CDN hosted files for Video.js, sponsored by Fastly – thanks Fastly! These files currently have a stripped down pixel tracking for Google Analytics (GA) that sends limited information to a GA account we own. We did a terrible job communicating that this is happening and how users can opt out – set window.HELP_IMPROVE_VIDEOJS to false before loading in Video.js – or use another CDN like unpkg or CDNJS. Recently we made a change that makes this tracking pixel honor the Do Not Track flag set by users in the browser, however, this isn’t going to affect previously released versions of Video.js

In addition, starting with Video.js 7.0 (and probably back ported to newer versions of 6.x) we will no longer include this tracking pixel in our CDN builds. Instead, we are investigating our options for using the CDN logs via Fastly. We expect to share more details as we get closer to the Video.js 7 release date and have a better idea of what we will be doing.

Build Tools

Currently, Video.js uses rollup to combine all the Video.js files into two files for different build systems. One that excludes dependencies, for use in bundlers, and another that includes dependencies for a UMD file that can be used on a page as a <script>. We are looking to transition our build and test tooling from rollup and browserify to Webpack 4.0 to provide more flexibility in our builds and to do a better job at being able to build with VHS (as many people remember the infamous issue 600 on the contrib-hls repo).
In addition, we’ll be looking into allowing custom builds when bundling Video.js. For example, if one doesn’t want VHS or doesn’t want visible controls, a surprisingly large part of the player, they can set VJS_VHS=false VJS_CONTROLS=false when they’re bundling their application to keep these pieces out of the build.

Timeline

We are still working on a lot of what was mentioned above but our hope is to have the first pre-release of 7.0 before the end of March.

We’re pretty excited about this not-so-major update and hope you will be too!

]]> <p><img src="/Video-js-7-Roadmap/woodland-road-falling-leaf-natural-38537.jpeg" alt=""></p> <p>Today, I’m excited to announce the roadmap to videojs-vr Is Now Under The Video.js Org http://blog.videojs.com/videojs-vr-now-under-the-video-js-org/ 2018-02-21T11:36:00.000Z 2019-01-18T19:57:55.607Z Brightcove and Video.js have adopted the videojs-vr plugin as a first class plugin.
It’s out now with support for Video.js 6!

Where did it come from?

This plugin has a long history and has had many maintainers.
It started as slawrence/videojs-vr. From there it became metacdn/videojs-vr. Then there was a private collaberation between StreamShark.io, Brightcove, and HapYak. Eventually we decided to treat this plugin like a first class citizen. So we updated it to the advanced plugin API, fixed a few long-standing issues, documented other issues along the way, and moved it to the Video.js Organization.

How do you know a video is 360/VR?

On desktop players

In a non-browser environment this question is easily answered, because there is a generally agreed upon standard. The video itself should have metadata indicating that the video is a 360/VR video and how to display it. Even outside of the browser though it is a bit tricky because most programs (even ffmpeg) don’t support the insertion of this metadata. In fact a lot of them will strip said metadata as they think it is invalid. That is where a project called Spatial Media Metadata Injector comes in. Spatial Media Metadata Injector injects 360/VR metadata into the video without changing anything else.
That allows players like VLC to know that a video is 360/VR.

How does videojs-vr do it?

The browser does not expose video metadata in an API so we would have to parse it ourselves, which isn’t really an option. So in videojs-vr we have a projection option that can be passed in during plugin initialization.

The first and default setting for projection is 'AUTO'. Setting projection to 'AUTO' tells videojs-vr to look at player.mediainfo.projection. player.mediainfo.projection will have to be set by some external plugin/script which is told by a server that the current video is 360/VR. The player.mediainfo.projection of a video can be any of the following:

  • '360', 'Sphere', or 'equirectangular': The video is a sphere
  • 'Cube' or '360_CUBE': The video is a cube
  • 'NONE': This video is not a 360 video, the videojs-vr plugin should do nothing. this would not have to be set as it will be assumed if no projection exists.
  • '360_LR': Used for side-by-side 360 videos
  • '360_TB': Used for top-to-bottom 360 videos

Otherwise, the projection can manually be set on plugin initialization to any of the above values. The plugin can then be disposed and re-initialized for each video with a different setting.

What happens after after we know a video is 360/VR?

Using the current projection value we determine what we need to show on our three.js canvas. From there we use the polyfilled (via webvr-polyfill or real VRDisplay API to set up controls. If the device has a VIVE, Oculus, etc plugged in we use that. If not we display the video in 360 mode where the mouse/keyboard/accelerometer control the video. On mobile devies there is also a button to go into cardboard mode which will show the video as two smaller videos separated by a line. This is so that the video can be viewed using pseudo VR headsets (such as google cardboard) and a phone. While the video is playing we use animation frames to animate the VideoTexture on the three.js canvas. That allows us to show the correct portion of the video based on the controls that the user is inputting.

Why is it so huge?

We all agree that the plugin is huge, but due to the fact that all browsers do not natively support the VRDisplay API, we have to include a lot of big dependencies in our project. Mainly the size comes from the following:

  1. three.js which we use to create the VR/360 canvas, and implementing it on our own would be painful
  2. webvr-polyfill which polyfills VR features for browsers that don’t currently support VR (outside of experimental flags and builds)

Debugging

Every object from three.js and webvr manager (from webvr-boilerplate) is available on the instance of the VR plugin that will is returned by player.vr().

Known Issues

  • Multiple players on the same page will share controls, panning in one video will pan in the other.

The Future

  • Implementing player level controls rather than window controls. This will allow individual videos to be controlled separately based on the current focus.
  • A menu so that multiple VR displays can be used rather than just the first one that we find.

To see the code, submit an issue, suggest a feature, or submit a pr

See the github repo videojs-vr

]]> <p>Brightcove and Video.js have adopted the videojs-vr plugin as a first class plugin.<br>It’s out now with support for Video.js 6!</p> <h2 Video.js 6.7.1 released http://blog.videojs.com/Video-js-6-7-1-released/ 2018-02-01T15:40:55.000Z 2019-01-18T19:57:55.601Z Video.js 6.7.1 was released this week. This comes a month and a half since the first 6.6.0 release (which we forgot to blog about) and only a week since the latest patch release (6.6.3, which is now latest).

6.7 has two awesome new features and a couple helpers:

  • a working playerresize event
  • a new mediator type for middleware
  • getPlayer and getAllPlayers helper on videojs.

Netlify

Recently, we also switched over all our online properties to run on Netlify. This is great because it gives us HTTPS via Let’s Encrypt but also allows us much better automation for the website, docs website, and blog. Since the docs website is tied to the main Video.js repo and has a build per PR, we also had Netlify generate an example page for the PR based on the sandbox examples. Here’s the example page for a recent PR.

playerresize

This new event will fire each time the player is resized. It will fire when going fullscreen and when exiting fullscreen and when resizing the player via the dimension methods or if the player is in fluid mode and the window is resized.
It uses the new ResizeObserver in Chrome 64 and wherever it is available. If it isn’t available, a polyfill can be passed in or it will use its fallback. The fallback uses an absolutely positioned, hidden iframe that’s the size of the player and then retriggers the iframe’s resize event on a debounced handler.
Also, I wanted to note that the resize player event does not refer to the size of the player itself but rather to the native resize event, which is triggered when the videoHeight or videoWidth has changed.

Mediator type for middleware

This is the first major feature for middleware since they were released in 6.0. The main reason for the mediator is for middleware to be able to cancel requests to play(). Thus, they are currently limited to play() and pause() calls currently. Once we iron out the details we hope to enable it for further functionality.
The mediator middleware allows you to intercept the calls to the mediator methods, like play(), and then prevent the calls from occuring on the tech. This is important for methods like play() because while calling pause() immediately after play() may succeed in “cancelling” playback, it also has some unintended side-effects in a few cases. The mediator middleware can decide whether play() should go through, thus eliminating the need to call pause(). Afterwards, all middleware will be notified whether the call was terminated or it will be given the return value. In the case of play(), it will be the play promise itself.

Here’s a simple example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
videojs.use('*', (player) => ({
  setSource(src, next) {
    next(null, src);
  }

  callPlay() {
    // return this value to terminate the method call
    return videojs.middleware.TERMINATOR;
  }

  play(terminated, playPromise) {
    if (terminated) {
      return console.error(terminated, 'play was terminated');
    }

    playPromise
    .then(() => console.log('play succeeded!'))
    .catch(() => console.log('play failed :('));
  }
});

Player helpers

These are to make it easier to manage your players and reduce unintended side-effects. A lot of times, a player is being created automatically via data-setup but then to refer to it via code, videojs() is called. In some cases, this will actually initialize the player because it ended up running before the auto setup. Now, videojs.getPlayer() can be used instead and it will never create the player. It is the preferred way of getting the player once it has been created.
videojs.getAllPlayers() is just a nice way of getting a list of all the players that are currently available on the page.

Committers

Raw CHANGELOG

6.7.1 (2018-01-31)

Bug Fixes

  • middleware: do a null check in mediator methods (#4913) (7670db6)

6.7.0 (2018-01-30)

Features

Bug Fixes

  • do not patch canplaytype on android chrome (#4885) (f03ac5e)

Chores

Documentation

  • Update COLLABORATOR_GUIDE.md and CONTRIBUTING.md to include label meanings (#4874) (a345971)

Tests

  • add project and build names to browserstack (#4903) (41fd5cb)
]]> <p>Video.js 6.7.1 was released this week. This comes a month and a half since the first <a href="https://github.com/videojs/video.js/release Video.js 6.5.0 Release http://blog.videojs.com/Video-js-6-5-0-Release/ 2017-11-27T17:16:06.000Z 2019-01-18T19:57:55.598Z November 17th marked the pre-release of Video.js 6.5.0. It comes shortly after the release of 6.4.0, which has now been promoted to latest! This is a pretty exciting release because we finally got our own element! I like to call it the I Can’t Believe It’s Not Custom Elements because it isn’t an actual custom element but it’s not a standard HTML element either. Also, a nice and smooth progress bar thanks to a first time contributor; thanks @vhmth!. A pretty major memory leak fix, and many code refactors and bug fixes.
I’d like to thank everyone who contributed and the four first time contributors to Video.js: @vhmth, @FirefoxMetzger, @EhsanCh, and @shahlabs.
This post comes a week late because it was Thanksgiving week in the US after release and I was on break, if you celebrate Turkey day 🦃, hope you had a good one!

Notable Changes

  • I Can’t Believe It’s Not Custom Elements with a <video-js> element. It works exactly like the <video> embed but without requiring you to use the <video> element and the benefits and drawbacks that come with it. It also adds the video-js class name automatically for you, so, there’s no need to add it.
  • A smooth progress bar!
    before the change
    after the change
  • After much spelunking in the code base and developer tools, we’ve plugged most of the memory leaks with retained DOM elements in Video.js!
  • Many code refactorings from our old code style to the new one by @kocoten1992!
  • Previously, you could accidentally seek or toggle playback using the middle or right clicks. Now, just go ahead and try it!
  • An accessibility fix with regards to title tooltips and menu items.
  • Better handling of play() in our new asynchronous world, especially immediately after changing the source.

Committers

Raw Changelog

6.5.0 (2017-11-17)

Features

Bug Fixes

  • Avoid empty but shown title attribute with menu items and clickable components (#4746) (dc588dd)
  • Player#play: Wait for loadstart in play() when changing sources instead of just ready. (#4743) (26b0d2c)
  • being able to toggle playback with middle click (#4756) (7a776ee), closes #4689
  • make the progress bar progress smoothly (#4591) (acc641a)
  • only allow left click dragging on progress bar and volume control (#4613) (79b4355)
  • only print element not in DOM warning on player creation (#4755) (bbea5cc)
  • trigger timeupdate during seek (#4754) (1fcd5ae)

Chores

Code Refactoring

Documentation

Performance Improvements

  • null out els on dispose to minimize detached els (#4745) (2da7af1)

Tests

]]> <p>November 17th marked the pre-release of Video.js 6.5.0. It comes shortly after the <a href="https://blog.videojs.com/video-js-6-4-0-relea Video.js 6.4.0 Release http://blog.videojs.com/Video-js-6-4-0-Release/ 2017-11-02T16:01:38.000Z 2019-01-18T19:57:55.598Z Hello everyone, it’s been a while! Yesterday, I pre-released Video.js 6.4.0. It’s a pretty big release with 27 merged Pull Requests from 13 authors and 7 of them were contributors!
I’d like to thank everyone who contributed but particularly those seven. Six of them made their first PRs with Video.js: @estim, @seggev319, @nicolaslevy, @MarcAMo, @knilob, @odisei369. And @kocoten1992 returned with some great PRs to refactor things.

In this release, we fixed a bunch of bugs, refactored some things, updated some tests. We also added some new features.

As with other releases, this is released as next for a short while before being promoted to latest.
You can get these releases on GitHub Releases or from npm

Notable Changes

  • Hebrew translations are now available. Russian and Polish translations were updated as well.
  • The Progress Control can now be disabled. This is useful for when you don’t want users to be able to interact with it but still want to show play progress.
    • The Progress Control will also be fully filled out when the video ends so that we aren’t slightly short or long due to weirdnesses in duration and currentTime.
  • It’s now possible to add a hook that gets automatically removed once called with hookOnce. This mirrors our on and once event methods.
  • If controls are disabled before the modal dialog is opened, the controls stay closed when the dialog is closed.
  • player.src() will now return an empty string when no source is set to match player.currentSrc() and the native video element.
  • Video.js will now warn when the element it is given isn’t in the DOM. This was done as part of a “first-timers-only” issue which we hope to do more off in the future.

Google Analytics note

We’ve updated the README of the project to be explicit about our usage of Google Analytics on the vjs.zencdn.net hosted version of Video.js. It is a stripped down version of the Google Analytics pixel and sends data on 1% of those loads.
It can be opted out of by adding the following to the page before the zencdn-hosted version of Video.js is loaded

1
<script>window.HELP_IMPROVE_VIDEOJS = false;</script>

Our GitHub releases and npm releases do not include Google Analytics. Neither do 3rd-party CDNs like unpkg or CDNjs.

Committers

Full Changelog

6.4.0 (2017-11-01)

Features

  • lang: add Hebrew translation (#4675) (32caf35)
  • lang: Update for Russian translation (#4663) (45e21fd)
  • Add videojs.hookOnce method to allow single-run hooks. (#4672) (85fe685)
  • add warning if the element given to Video.js is not in the DOM (#4698) (6f713ca)
  • allow progress controls to be disabled (#4649) (a3c254e)
  • set the play progress seek bar to 100% on ended (#4648) (5e9655f)

Bug Fixes

  • css: update user-select none (#4678) (43ddc72)
  • aria-labelledby attribute has an extra space (#4708) (855adf3), closes #4688
  • Don’t enable player controls if they where disabled when ModalDialog closes. (#4690) (afea980)
  • don’t throttle duration change updates (#4635) (9cf9800)
  • Events#off threw if Object.prototype had extra enumerable properties, don’t remove all events if off receives a falsey value (#4669) (7963913)
  • make parseUrl helper always have a protocl (#4673) (bebca9c), closes #3100
  • Make sure we remove vjs-ended from the play toggle in all appropriate cases. (#4661) (0287f6e)
  • player.src() should return empty string if no source is set (#4711) (9acbcd8)

Chores

Code Refactoring

Documentation

Tests

]]> <p>Hello everyone, it’s been a while! Yesterday, I pre-released Video.js 6.4.0. It’s a pretty big release with 27 merged Pull Requests from Video.js 6.0 Release! http://blog.videojs.com/Video-js-6-0-Release/ 2017-04-03T17:56:51.000Z 2019-01-18T19:57:55.598Z After months of hard work, I am proud to annouce the release of Video.js 6.0 🎉!

This release is pretty exciting. It greatly improves the accessibility 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 middleware and advanced plugins. Video.js 6.0 is also the first release where Flash is unbundled from core – 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 know

Most 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 wiki. We’ll make sure to update it if there’s anything that we missed.

Feedback Wanted

If you are using Video.js and have comments or questions, please drop by on Slack. If you find a bug, please open an issue on GitHub, preferably with a reduced test case.

5.x Support

We’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.

npm tags

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 Condunct

We strive to be open and inclusive and so we have adopted a Code of Conduct, based on Contributor Covenant that applies to all Video.js projects.

Conclusion

We are super excited for this release! Please take it for a spin from next tag on npm or from the CDN. And please come chat with us on Slack.

]]> <p>After months of hard work, I am proud to annouce the release of Video.js 6.0 🎉!</p> <p>This release is pretty exciting. It greatly <a hr Feature Spotlight: Middleware http://blog.videojs.com/Feature-Spotlight-Middleware/ 2017-03-27T15:04:41.000Z 2019-01-18T19:57:55.575Z Middleware is one of the cool new features that is coming to Video.js in version 6.0

With middleware, you are now able to interact with and change how the player and the tech talk to each other. The tech is Video.js’s abstraction from the player, separating the player API from the playback technology. With techs, we can plug things like a Flash fallback or a Youtube embed into Video.js without changing the external API or the look-and-feel of the player.

Video.js middleware are like Express middleware but routes are based on video MIME types.

A lot of Video.js users may be familiar with middleware from projects like Express. Video.js middleware isn’t that different from those. In both cases you register your middleware against a particular route to call down the chain when the route is triggered. In Express, routes are based on the url paths. In Video.js, these routes are based on the video MIME type. And, like Express, there are “star” (*) middleware that match all routes.

There are two important pieces to be aware of with middleware:

  1. dynamic source handling
  2. intercepting the player and tech interactions.

A Video Catalog

With the dynamic source handling, you could load video with a custom type and source and resolve it asynchronously. A good example for this is a video catalog system. The page can be rendered with a specific catalog ID and a special MIME type, like so:

1
2
3
<video controls class="video-js">
  <source src="123" type="video/my-catalog">
</video>

Then, you could register a middleware for that route – the type video/my-catalog.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// middleware methods get the player instance as an argument
videojs.use('video/my-catalog', function(player) {

  // middleware are expected to return an object with the methods on it.
  // It can be a plain object or an instance of something.
  return {

    // setSource allows you to tell Video.js whether you're going to be handling the source or not
    setSource(srcObj, next) {
      const id = srcObj.src;

      videojs.xhr({
        uri: '/getVideo?id=' + id
      }, function(err, res, body) {

        // pass null as the first argument to say everything is going fine and we can handle it.
        next(null, {
          src: body.sourceUrl,
          type: body.sourceType
        })
      });
    }
  };
});

Then, when Video.js initializes, it’ll go through and call the middleware that are set for video/my-catalog.

Server-Side Ad Insertion

Server Side Ad Insertion (SSAI) is a great fit for middleware. It showcases the ability to intercept the play and tech interactions. For example, you have a 30 seconds ad followed by a five minute video in your HLS manifest. You want the timeline to display the ad time and the content time appropriate when each is playing. Right now, the duration displayed will be the combined duration of five minutes and 30 seconds (5:30). The solution is to add a middleware that knows when the ad is being played and tells the player that the duration is 30 seconds and when the content is playing that the duration is five minutes.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// register a star-middleware because HLS has two mimetypes
videojs.use('*', function(player) {
  return {
    setSource(srcObj, next) {
      const type = srcObj.type;

      if (type !== 'application/x-mpegurl' && type !== 'application/vnd.apple.mpegurl') {

        // call next with an error to signal you cannot handle the source
        next(new Error('Source is not an HLS source'));
      } else {

        // in here we know we're playing back an HLS source.
        // We don't want to do anything special for it, so, pass along the source along with a null.
        next(null, srcObj);
      }
    },

    // this method gets called on the tech and then up the middleware chain providing the values as you go along
    duration(durationFromTech) {
      if (areWeCurrentlyPlayingAnAd(durationFromTech)) {
        // since we're now in an ad, return the ad duration
        // in a real example you'd calculate this based on your playlist
        // rather than hardcode a value in here
        return 30;
      } else {
        // we're playing back content, so, return that duration
        return 5 * 60;
      }
    }
  }
});

Playbackrate Adjustment - A Case Study

A simple but interesting middleware to look at is the playbackrate-adjuster. 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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
videojs.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 code 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.

1
2
3
4
5
6
7
currentTime(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.

1
2
3
4
5
6
7
8
9
10
11
videojs.use('*', function(player) {
  let tech;

  return {
    setTech(newTech) {
      tech = newTech;
    }

    /* ... */
  };
});

And then, when the ratechange event triggers, we tell Video.js that the duration has changed and Video.js will update the controls accordingly:

1
2
3
4
5
6
7
8
9
10
11
12
videojs.use('*', function(player) {
  let tech;

  player.on('ratechange', function() {
    tech.trigger('durationchange');
    tech.trigger('timeupdate');
  });

  return {
   /* ... */
  }
});

You can see a live example here and the complete code here.

]]> <p>Middleware is one of the cool new features that is coming to Video.js in version 6.0</p> <p>With middleware, you are now able to interact Video.js removes Flash from core player http://blog.videojs.com/Video-js-removes-Flash-from-core-player/ 2017-02-08T19:17:21.000Z 2019-01-18T19:57:55.606Z In August of 2016, we announced 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 time
to remove Flash from the core player and move it to a separate code base. This will give us the ability
to allow developers to continue to support legacy browsers by adding the tech themselves, while allowing
us 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.

Chrome: Chrome 56 disables flash by default

Safari: Safari makes Flash a legacy plugin

Firefox: Reducing Adobe Flash Usage in Firefox

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 videojs-flash project has been created for Flash tech support.
When the videojs-flash plugin is added to the player, the Flash tech is added to the tech order.

1
2
3
4
5
6
7
8
9
10
11
<link rel="stylesheet" href="path/video.js/dist/video-js.css">
<script src="path/video.js/dist/video.js"></script>
<script src="path/videojs-flash/dist/videojs-flash.js"></script>

<video  id='vid' class='video-js' controls height=300 width=600>
  <source src="video.mp4" type="video/mp4">
</video>

<script>
  var player = videojs('vid');
</script>
]]> <p>In August of 2016, we <a href="http://blog.videojs.com/the-end-of-html-first/">announced</a> our intention of removing Flash as a part of Feature Spotlight: Accessibility http://blog.videojs.com/Feature-Spotlight-Accessibility/ 2017-02-03T15:10:33.000Z 2019-01-18T19:57:55.569Z Accessibility! The most important feature you never knew about.

In the Video.js organization we try hard to have good accessibility. Like most other software, any change can affect the system in unintended ways. For example MuteToggle and VolumeControl were married into VolumeMenuButton in Video.js 5. While this change did allow these controls to work in tandem visually, it also did something unintended. It broke accessibility. In this post we will go over what broke, what the fix was, what accessibility is, and how to test and make sure it works.

Feel free to skip to the last section 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.

See the resources section at the end of this post 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 Mozilla Developer Network.

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 ARIA attributes see the specification.

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 solution

Now 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 :

macOS `VoiceOver` Before The Fix

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:

macOS `VoiceOver` After The Fix

Outlines

Another big accessibility fix for controls comes from the removal of one small css rule:

1
outline: none;

Why did we do it? With feedback from the community and external resources, 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 up

Hopefully 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 contribute to Video.js.

If you want to keep up to date on the current state of accessibility work see the a11y label on PRs and issues.

Resources

Here are some popular screen readers that are actually used in the wild:

Resources for learning more about web accessibility:

]]> <h3 id="Accessibility-The-most-important-feature-you-never-knew-about"><a href="/Feature-Spotlight-Accessibility/#Accessibility-The-most-imp Feature Spotlight: Advanced Plugins http://blog.videojs.com/Feature-Spotlight-Advanced-Plugins/ 2017-01-26T14:41:32.000Z 2019-01-18T19:57:55.575Z

Note: Advanced plugins are being introduced in Video.js 6.0 and are only supported from that version forward.

If you’ve been a Video.js user for a while, you’re likely familiar with the concept of plugins: functions that become methods of any player you create. If you’re not familiar with Video.js plugins, we have a comprehensive plugins guide 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 Plugins

One of Video.js’ strengths is its rich ecosystem of plugins; so, in the last few months, we wanted to focus our efforts on improving the plugin author experience.

While projects like the plugin generator and videojs-spellbook 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-Like

One 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:

1
2
3
4
5
6
7
8
9
10
const Plugin = videojs.getPlugin('plugin');

class HelloWorld extends Plugin {
  constructor(player) {
    super(player);
    this.player.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:

1
2
3
4
5
const player = videojs('my-player');
const instance = player.helloWorld();

// Logs: 'true'
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.

Events

Similar 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 Data

The 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:

1
2
3
4
5
6
7
8
9
10
11
const player = videojs('my-player');
const instance = player.helloWorld();

instance.on('some-custom-event', (e, data) => {
  videojs.log(data.instance === instance); // true
  videojs.log(data.name === 'helloWorld'); // true
  videojs.log(data.plugin === videojs.getPlugin('helloWorld')); // true
  videojs.log(data.foo); // "bar"
});

instance.trigger('some-custom-event', {foo: 'bar'});

Lifecycle

Another 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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
const player = videojs('my-player');

const firstInstance = player.helloWorld();

// Logs: 'true'
videojs.log(firstInstance === player.helloWorld());

firstInstance.on('dispose', () => videojs.log('disposing a helloWorld instance'));

// Logs: 'disposing a helloWorld instance'
firstInstance.dispose();

const secondInstance = player.helloWorld(); 

// Logs: 'false'
videojs.log(firstInstance === secondInstance);

The pluginsetup Event

Plugins 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:

1
2
3
4
5
6
7
8
9
10
const player = videojs('my-player');

player.on('pluginsetup', (e, hash) => {
  if (hash.name === 'helloWorld') {
    videojs.log('A helloWorld instance was created!');
  }
});

// Logs: 'A helloWorld instance was created!'
player.helloWorld();

React-inspired Statefulness

One 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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// A static property of the constructor can be used to pre-populate state 
// for all instances.
HelloWorld.defaultState = {color: 'red'};

const player = videojs('my-player');
const instance = player.helloWorld();

instance.on('statechanged', (e) => {
  const {color} = e.changes;

  if (color) {
    videojs.log(`The helloWorld color changed from "${color.from}" to "${color.to}"!`);
  }
});

// Logs: 'The helloWorld color changed from "red" to "blue"!'
instance.setState({color: 'blue'});

Player Plugin Awareness

Finally, 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 Method

This method reports whether a plugin matching a given name is available on the player:

1
2
3
4
5
6
7
const player = videojs('my-player');

// Logs: 'true'
videojs.log(player.hasPlugin('helloWorld'));

// Logs: 'false'
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 Method

This method reports not only whether a plugin is available on a player, but whether it is currently active on the player:

1
2
3
4
5
6
7
8
9
const player = videojs('my-player');

// Logs: 'false'
videojs.log(player.usingPlugin('helloWorld'));

player.helloWorld();

// Logs: 'true'
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 lifecycle or events; so, it’s not possible to determine whether one has been “disposed”.

Go Forth and Code

We 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 to give back to the Video.js project in whatever way they can.

For a more complete discussion of plugins generally, visit the Video.js plugins guide.

]]> <blockquote class="pullquote right"><p><strong>Note:</strong> Advanced plugins are being introduced in Video.js 6.0 and are only supported f Video.js 6.0.0-RC.0: The first Release Candidate http://blog.videojs.com/Video-js-6-0-0-RC-0-The-first-RC/ 2017-01-23T16:59:11.000Z 2019-01-18T19:57:55.598Z The first Release Candidate for 6.0 has been released

Last week, we began wrapping up months of effort to make Video.js even better with the first Release Candidate (RC) of Video.js 6.0. In order to make it better, however, we had to make a few breaking changes and we also made a lot of improvements under the hood.

How to try it out

The RC is now published on npm under the beta tag with verion 6.0.0-RC.0.

1
npm install video.js@beta

Please try it out and let us know how it is on GitHub.

What to look forward to

  • We’re finally removing Flash from core as outlined in a previous post.
  • 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 Spotlights

Over the coming weeks, we’ll post feature spotlights talking about the big things that are happening.
We might also revisit some old features.

]]> <h2 id="The-first-Release-Candidate-for-6-0-has-been-released"><a href="/Video-js-6-0-0-RC-0-The-first-RC/#The-first-Release-Candidate-for-6 Introducing Thumbcoil http://blog.videojs.com/Introducing-Thumbcoil/ 2016-10-19T16:47:37.000Z 2019-01-18T19:57:55.575Z

A transmuxer takes media contained in some file format, extracts the raw compressed video and audio from inside (a process called demuxing) and repackages the compressed data into another format (termed remuxing) without performing any re-compression.

In the Beginning

While building Mux.js - the transmuxer at the heart of videojs-contrib-hls - 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 MP4s from MPEG2-TS segments that would play back in a browser with Media Source Extensions (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 World

A 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 MSE specification.

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 Thumbcoil.

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 AAC for audio and H.264 for video.

Thumbcoil

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 Thumbcoil 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 Thumbcoil, you can finally see for yourself!

Motivation

An 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.

Thumbcoil 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 Stuff

One of the more interesting things about how Thumbcoil 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 parser combinator-type setup.

Much of the data in the two parameter sets are stored using a method called exponential-golomb encoding. 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 Thumbcoil 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, Thumbcoil 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?

“Thumbcoil“ 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: thumb.co.il.

As with all Video.js projects, Thumbcoil is open-source software and we welcome suggestions, issues, and contributions at https://github.com/videojs/thumbcoil.

]]> <blockquote class="pullquote right"><p>A <strong>transmuxer</strong> takes media contained in some file format, extracts the raw compressed Video.js 5.12.0 and 5.11.5 releases http://blog.videojs.com/Video-js-5-12-0-and-5-11-5-releases/ 2016-08-25T19:28:03.000Z 2019-01-18T19:57:55.577Z Today, there are two releases of video.js.
The first, is a patch release for the 5.11 branch. With this release, we’re also updating 5.11 to stable and publishing it to the CDN.

The 5.12 release is a pre-release. It’s a pretty big milestone too. Video.js finally outputs non-pre-built files so bundlers like webpack can decide what to do with them.

Notable Changes

This release is mostly a maintenance and build-change release.

  • Lint the entire codebase with our linter 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 list of translations missing from language files based on the en.json 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 Issues

No new known issues but we have started looking into the known issues from the last release.

Looking forward

Going forward, we’re looking into switching to standard-version. 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 contrib 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 (view)
  • @misteroneill added ghooks to run linter on git push (view)
  • @BrandonOCasey removed unused base-styles.js file (view)
  • @erikyuzwa, @gkatsev updated CSS build to inlcude the IE8-specific CSS from a separate file instead of it being inside of sass (view) (view2)
  • @gkatsev added null checks around navigator.userAgent (view)
  • greenkeeper updated karma dependencies (view)
  • @BrandonOCasey updated language docs to link to IANA language registry (view)
  • @gkatsev removed unused dependencies (view)
  • @misteroneill enabled and updated videojs-standard and fixed an issue with linting (view)
  • @misteroneill updated tests to qunit 2.0 (view)
  • @gkatsev added slack badge to README (view)
  • @gkatsev reverted back to qunitjs 1.x to unbreak IE8. Added es5-shim to tests (view)
  • @gkatsev updated build system to open es5 folder for bundles and dist folder other users (view)
  • greenkeeper updated uglify (view)
  • greenkeeper updated grunt-concurrent (view)
  • greenkeeper updated karma-chrome-launcher (view)
  • @gkatsev added tests for webpack and browserify bundling and node.js requiring (view)
  • @rlchung fixed tests that weren’t disposing players when they finished (view)

Git diffstats

These are deltas between 5.11.5 and 5.12.0 with the dist folder ignored.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
.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(-)

]]> <p>Today, there are two releases of video.js.<br>The first, is a patch release for the 5.11 branch. With this release, we’re also updating 5 The End of "HTML-First" http://blog.videojs.com/the-end-of-html-first/ 2016-08-10T15:58:44.000Z 2019-01-18T19:57:55.606Z When video.js was first released 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 really complicated to get right 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 browser support for video 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 video.js 5.0, 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 a couple more hoops 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 legacy-compatiblity shim around the time Chrome begins deprecating Flash 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 HLS and DASH, and making advanced features like ads easier to integrate and better for viewers.

How does that sound? Let us know in this issue, ping @videojs on Twitter, or come say “hi” in our Slack channel.

]]> <p>When video.js was <a href="https://github.com/videojs/video.js/commit/abe9252bbb7d255dd4671cf0afd93d980c2bf6df" target="_blank" rel="exte Video.js 5.11.0 Prelease http://blog.videojs.com/Video-js-5-11-0-Prelease/ 2016-07-22T15:46:51.000Z 2019-01-18T19:57:55.577Z Today sees the prerelease of version 5.11.0. I wanted to take a moment to talk about some of the changes, additions, and known issues.

This is a pre-release only. It’s available on npm under the next tag and also available on the CDN under the fully qualified version number: //vjs.zencdn.net/5.11.0/video.js. It’ll stay in pre-release state for around a week or more to make sure that there aren’t any glaring bugs, so, please give it a shot and open issues 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 disposed SourceHandlers on subsequent loadstarts and cleared out the current source. However, this causes an issue with videojs-contrib-dash. 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 (view)
  • @hartman Correct documentation to refer to nativeTextTracks option (view)
  • @nickygerritsen Also pass tech options to canHandleSource (view)
  • @misteroneill Un-deprecate the videojs.players property (view)
  • @nickygerritsen Add title to all clickable components (view)
  • @nickygerritsen Update Dutch language file (view)
  • @hartman Add descriptions and audio button to adaptive classes (view)
  • @MattiasBuelens Retain details from tech error (view)
  • @nickygerritsen Fix test for tooltips in IE8 (view)
  • @mboles added loadstart event to jsdoc (view)
  • @hartman added default print styling (view)
  • @ldayananda updated videojs to not do anything if no src is set (view)
  • @nickygerritsen removed unused tracks when changing sources. Fixes ##3000 (view)
  • @vit-koumar updated Flash tech to return Infinity from duration instead of -1 (view)
  • @alex-phillips added ontextdata to Flash tech (view)
  • @MattiasBuelens updated components to use durationchange only (view)
  • @misteroneill improved Logging for IE < 11 (view)
  • @vdeshpande updated control text of modal dialog (view)
  • @ldayananda fixed mouse handling on menus by using mouseleave over mouseout (view)
  • @mister-ben updated language to inherit correctly and respect the attribute on the player (view)
  • @sashyro fixed nativeControlsForTouch option (view)
  • @tbasse fixed techCall null check against tech (view)
  • @rbran100 checked src and currentSrc in handleTechReady to work around mixed content issues in chrome (view)
  • @OwenEdwards fixed caption settings dialog labels for accessibility (view)
  • @OwenEdwards removed spurious head tags in the simple-embed example (view)
  • @ntadej added a null check to errorDisplay usage (view)
  • @misteroneill fixed logging issues on IE by separating fn.apply and stringify checks (view)
  • @misteroneill fixed npm test from running coveralls locally (view)
  • @gkatsev added es6-shim to tests. Fixes Flash duration test (view)
  • @misteroneill corrects test assertions for older IEs in the log module (view)
  • @gkatsev fixed setting lang by looping through loop element variable and not constant tag (view)

Git diffstats

These are deltas between 5.11.0 and 5.10.7

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
CHANGELOG.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(-)

]]> <p>Today sees the prerelease of version 5.11.0. I wanted to take a moment to talk about some of the changes, additions, and known issues.</p Video.js 5's fluid mode and playlist picker http://blog.videojs.com/Video-js-5-s-fluid-mode-and-playlist-picker/ 2016-06-01T14:50:06.000Z 2019-01-18T19:57:55.577Z How it works

In video.js 5.0, we added support for truly fluid layouts with video.js.
You can see an example of it on the video.js website.

It is done by using intrinsic ratios. Video.js does the heavy lifting for you.

How to use it in video.js

In video.js, to make a player fluid, you can either set the fluid option

1
2
3
let player = videojs('preview-player', {
  fluid: true
});

Or you can add one of the fluid classes to the player: .vjs-fluid, .vjs-4-3, .vjs-16-9:

1
<video id="preview-player" class="video-js vjs-fluid" controls data-setup={}>

.vjs-4-3 maintains a 4:3 aspect ratio for the video and .vjs-16-9 maintains a 16:9 one. .vjs-fluid is a bit more special. It waits for the video metadata to load and then uses the video width and video height to calculate the correct aspect ratio to use for the video.

Playlist picker

This works great if you only have the player by itself. What if you are trying to a attach a playlist to the video element and keep it at the same height Like we did on the advanced example page on the video.js website?

We could calculate how much the padding top should be depending on the width of the playlist picker or the container element but then each time a video changes we would need to recalculate the height of the playlist picker. Instead, we can rely on video.js to do all the work.

Attaching the playlist picker

For this example, We’re using the videojs-playlist-ui and videojs-playlist plugins for the playlist functionality.
We then wrap the player in a container and put the playlist-ui element in there as well.

1
2
3
4
5
6
7
<section class="main-preview-player">
  <video id="preview-player" class="video-js vjs-fluid" controls preload="auto" crossorigin="anonymous">
    <p class="vjs-no-js">To view this video please enable JavaScript, and consider upgrading to a web browser that <a href="http://videojs.com/html5-video-support/" target="_blank">supports HTML5 video</a></p>
  </video>

  <ol class="vjs-playlist"></ol>
</section>

Now we can relatively quickly make them align together with some CSS:

1
2
3
4
5
6
7
8
.video-js {
  width: 70%;
  float: left;
}
.vjs-playlist {
  width: 30%;
  float: right;
}

How to make it fluid

As you can see in the preceeding screenshot, it isn’t aligned correctly with the player like in the screenshot above.
Video.js calculates the aspect ratio and then adds a stylesheet to the page:

1
2
3
.preview-player-dimensions.vjs-fluid {
  padding-top: 41.66666666666667%;
}

That percentage results in a 2.4 aspect ratio which matches that of the oceans clip.

So, to make sure that the playlist picker is the same height, we can just add the player dimensions class to it:

1
<ol class="vjs-playlist preview-player-dimensions vjs-fluid"></ol>

How to make it line up

One of the easiest ways of making these two things line up correctly is to use flexbox. It’ll make the player and playlist picker grow to fill up as much space as needed. Also, the playlist picker collapse underneath the player if the width of the page is too small.
Flexbox is available on a lot of platforms. However, some browsers were implementing flexbox as the specification for it was evolving. It’s probably best to run this css through something like autoprefixer. Using autoprefixer won’t make it work on browsers that don’t support flexbox but will significantly increase platform support.

First, we set display to flex and add some properties for wrapping and sizing:

1
2
3
4
5
.main-preview-player {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-between;
}

flex-wrap allows playlist picker to wrap to the next line if the width of the container is too small.
Then we want to position the player and playlist picker relative to the container and set some default and minimum sizes:

1
2
3
4
5
6
7
.video-js,
.vjs-playlist {
  position: relative;
  min-width: 300px;
  min-height: 150px;
  height: 0;
}

And finally, we want to apply the flex setting to the player and playlist picker:

1
2
3
4
5
6
7
.video-js {
  flex: 3 1 70%;
}

.vjs-playlist {
  flex: 1 1 30%;
}

This tells the player to grow and take up 3x the space as the playlist picker and defaults to 70% of the width. The playlist picker itself defaults to 30% of the width and is allowed to grow and shrink as necessary.
Now if we load this in a browser we see a problem. The playlist isn’t the right height:

This is because the playlist-ui plugin sets its own padding on the element that ends up overriding the preview-player-dimensions padding-top. We can fix this by forcing the padding-top we want. However, while this solves our height problem, where are our items? Oh, you need to scroll to get them. That seems less than ideal.

This happens because our padding-top is inside the playlist picker; it pushed all the elements down requiring scrolling to get to them.

The final solution

Ultimately, what we need to do is wrap the playlist element in a container that flexes so that the padding-top doesn’t push the playlist items down.

1
2
3
<div class="playlist-container  preview-player-dimensions vjs-fluid">
  <ol class="vjs-playlist"></ol>
</div>

We also change the vjs-playlist references to playlist-container and absolutely position the playlist picker inside its container:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
.playlist-container {
  position: relative;
  min-width: 300px;
  min-height: 150px;
  height: 0;
}

.playlist-container {
  flex: 1 1 30%;
}

.vjs-playlist {
  margin: 0;
  position: absolute;
  top: 0;
  bottom: 0;
  left: 0;
  right: 0;
}

Now we have what we were looking for:

All together now


The HTML:

1
2
3
4
5
6
7
8
9
<section class="main-preview-player">
  <video id="preview-player" class="video-js vjs-fluid" controls preload="auto" crossorigin="anonymous">
    <p class="vjs-no-js">To view this video please enable JavaScript, and consider upgrading to a web browser that <a href="http://videojs.com/html5-video-support/" target="_blank">supports HTML5 video</a></p>
  </video>

  <div class="playlist-container  preview-player-dimensions vjs-fluid">
    <ol class="vjs-playlist"></ol>
  </div>
</section>

And the CSS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
.main-preview-player {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-between;
}

.video-js,
.playlist-container {
  position: relative;
  min-width: 300px;
  min-height: 150px;
  height: 0;
}

.video-js {
  flex: 3 1 70%;
}

.playlist-container {
  flex: 1 1 30%;
}

.vjs-playlist {
  margin: 0;
  position: absolute;
  top: 0;
  bottom: 0;
  left: 0;
  right: 0;
}

]]> <h2 id="How-it-works"><a href="/Video-js-5-s-fluid-mode-and-playlist-picker/#How-it-works" class="headerlink" title="How it works"></a>How i Video.js 5: The Only Thing That’s Changed Is Everything...except for like 3 things that didn't (including the name). http://blog.videojs.com/Video-js-5-The-Only-Thing-That’s-Changed-Is-Everything-except-for-like-3-things-that-didn-t-including-the-name/ 2015-09-29T14:00:16.000Z 2019-01-18T19:57:55.577Z First and foremost, THANK YOU to the 25 contributors who completed and merged 146 pull requests and updated just about every line of code in the project. And thank you to the hundreds of issue commenters and plugin authors who helped shape this latest version. For a widget, we’ve got a pretty awesome community.

For 5.0 we have some interesting new features, and we made A LOT of new technology choices. This will include an exhaustive dive into those choices, because… why not?

  • Redesigned and rebuilt the UI
    • Using a flex-box-based controls layout for easier add-ons
    • Improved accessibility of the controls
    • Switched from LESS to SASS
    • Switched to Material Icons
  • Rebuilt the library in ES6/Babel/Browserify including Modules and Classes
  • Added support for responsive layouts including auto-sizing to the video content
  • Added support for HLS in desktop browsers without Flash
  • Improved audio-only support
  • Added 6 more language translations bringing the total to 25
  • Switched from Closure Compiler to UglifyJS (we STOPPED mangling object properties)
  • Switched to JSDoc for documentation
  • Switched to BrowserStack for automated browser testing
  • Switched to Fastly for our CDN
  • New definition around plugins
  • New player skin designer on Codepen
  • New definition around playback technologies (“techs”)
  • New project governance model
  • New Website and Logo!

If you’re a Video.js user or lover of semver, you’re probably looking at the changelog and dying inside (or out). You’re probably already thinking about how little you want to do the mega-upgrade dance every time the major version is bumped. To be clear, there will be at least some upgrade cost between major versions because that’s just how things go. However, from 5.0 on, we plan on being a lot more liberal with major versions to avoid stop-the-world mega releases like this.

The fact is, this release cleaned up a lot of technical debt and cruft over years of maintaining a popular open source library. Working with the codebase is fun again (not like it wasn’t before, Judgy McJudgerson) and we think we’ve bought ourselves at least 6 months before we have to upgrade to ES9000. In all seriousness, we plan on being quicker with releases, both breaking and non, in order to make incremental upgrades less painful and, well, quicker. Besides, Chrome and Firefox are going to be in the thousands soon for their releases, and we want some of that fun.

Redesigned and rebuilt UI

Video.js has had an all-CSS skin (including for Flash) since it was created in 2010 (the first version was literally all CSS, no images, fonts, or svgs. And still works today!) Over those years we’ve seen some very creative customizations and learned a lot about what users are hoping to do with player design when they’re able to use native web techologies. For 5.0 we’ve both simplified the default layout and added more flexibility than ever before.

Flex Box Layout

One of our biggest challenges with the layout of the controls is keeping the control bar flexible and able to accomodate any new buttons that a plugin author might want to add. In 4.0 we used CSS floats to allow a new button to be appended to the control bar and flow into space. This however led to a very awkward tab order for anyone navigating the controls with the tab key. In 5.0 we were finally able to take advantage of flex box, which improves on the flexibility of the previous version while also maintaining the right tab order. In IE8 (because yeah, we still support that) we fall back to display:table, which works surprisingly well.

Improved accessibility

Accessibility has been a hot topic as of late, with new regulations helping push the industry forward and defining what accessbility means for a player. The tab-order mentioned previously was an eye sore in our accessiblity support, and we’re all happy to have that fixed in 5.0. Addtionally, after a long debate, we switched our Button elements to use the actual HTML button tag instead of divs. Using divs previously gave us a large degree of safety from external styles clobbering our own styles. This can be a big problem for html-based widgets that are dropped into other frameworks that add styles directly to native elements (ahem Foundation). In the end however the accessibility experts in our community made a strong enough case, pointing out that there’s still a number of devices that do not handle ARIA roles and javascript enhanced divs well enough to fully rely on them.

Switched from LESS to SASS

The original decision to use Less over Sass in version 4 was largely driven by the fact that it could be run in the browser. We knew we wanted to start using a preprocessor, but we still wanted to provide things like the skin designer which meant we needed to be able to do all pre-processing on the client. Less was totally appropriate for the job and allowed us to start modernizing the skin in appearance and tooling.

Since then, thanks to Emscripten, Sass has joined Less in the browser. This meant that we were free to use whichever of the two we liked, so all the contributors put on Less or Sass branded boxing gloves and fought until two gloves were still standing, which turned out to be Sass. Aside from the battle royale, there were a few reasons we decided to go with Sass for the new base skin in version 5.

  • Familiarity. Core contributors that started working on the new base skin were a little more experienced with Sass and simply preferred it.
  • Speed. On top of allowing us to use Sass without requiring Ruby, LibSass is fast.
  • Popularity. Your parents are right, not everything’s a popularity contest… but it is when you want to pick between two basically equivalent* tools. We wanted to pick something that more devs would be familiar with, and that seems to be Sass. On that note, it was also requested fairly often on the issue tracker.
  • Community. This goes hand in hand with popularity, but the Sass community is large and growing, with currently popular projects using it (and switching to it) and new tooling popping up every day along side industry standards such as Compass and Bourbon.

Big changes that we made during the switch that are unrelated to the tooling:

  • We broke apart the source files.
  • As mentioned above, we switched to a Flexbox-based layout. “What about IE8,” you say again? Tables. Srsly.
  • Improved support for responsive layouts.
  • We simplified the amount of customization we explicitly allow in the source to encourage people to build on top of the base skin, not edit it directly.
  • On the simplification note, we tried to simplify the base skin as much as possible. Our goal was to allow designers to build anything on top of the base without having to entirely start from scratch.
  • And more!

Switched to Material Icons

The switch to an icon font in version 4 was a huge win for Video.js. It allowed designers to do things as basic as style component icon colors with just CSS. It simplified the code base by allowing us not not worry about things like image sprites or other image optimizations. The only recurring issue we ran into was the process around adding new icons to the set, which ultimately involved just uploading the font back to IcoMoon and re-exporting.

In version 5, we’ve switched everything about our icon set. First we went with a new set of icons: Google’s Material Icons. This was a big step forward in terms of appearance, but we had the same issue as far as adding new icons. To fix that process we created new Font tooling for the project.

The tooling is really simple, but it allows anyone to write out a JSON configuration file pointing to any SVGs they have access to. The output of that tool is the font files themselves along with a new SCSS partial that gets imported into our Sass workflow in the core project at build.

We primarily use the Material icons, but occasionally we have to pull in a social media icon from another set, which this process greatly simplifies. See icons missing in the set that you’d like to use? Give the tool a try and let us know what you think!

Rebuilt the library in ES6/Babel/Browserify including Modules and Classes

5.0 comes with bit of enlightenment as we ditch our not-built-here syndrome and make a leap to post-modern development practices.

When we started work on the new version we originally planned to just use browserify and CommonJS modules, but when we took a closer look at the great work being done on Babel, it only made sense to jump again to ES6 modules and save ourselves another code transition down the road, while at the same time gaining a lot of great new JavaScript features.

Side-stepping any argument of the validity of JavaScript Classes, Video.js has always used classes for the internal UI framework. We used a custom class implementation that was of course incompatible with other custom implementations, so the move to ES6 opens the door for some potential interoperability with other frameworks as more people use ES6 classes specifically.

With the move to modules we’ve also opened the door to using more of the glorious ecosystem that is npm. We’ve started to toss out some of the non-core internal libraries that required us to be experts in just about everything, and replace them with other community-built modules. So far this includes libraries like lodash and raynos/xhr, and we’re actively looking for opportunies where we can share more code.

What does this mean for the end user?

This should make it easier for end-users of videojs, especially if they use browserify themselves. With this change, users can just
require('video.js') in their app.js or whenever they need it to instantiate players. In addition, plugins that were written
using browserify themselves can be added very easily using browserify and require as well. Of course, you can use Babel and
ES6 modules as well. For example, your app.js could look like the following, assuming browserify and babel for ES6 syntax:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// import videojs
import videojs from 'video.js';
// import several plugins.
// Each requires videojs itself and registers itself accordingly.
import 'videojs-playlist';
import 'videojs-thumbnail';
// this isn't ready yet, unfortunately
import 'videojs-contrib-hls';

// make a player
let player = videojs('my-video');
// initialize some plugins
player.playlist(myplaylist);
player.thumbnail(myThumbnailConfig);

Added support for responsive layouts including auto-sizing to the video content

Check out this video from the SF Vid Tech meetup for quick overview.

Proper support for responsive layouts has been a long time request. We’ve had tips and guides for how to make it work in the old version, but now it’s seamlessly built into the player. First we have two easy CSS classes you can just add to the embed code, vjs-16-9 and vjs-4-3.

<video class="video-js vjs-16-9 vjs-default-skin" ...></video>;

Or you can set the player to a fluid layout in the options and it will automatically update to match the aspect ratio of the content., whether you set a width, height, or neither.

1
var myPlayer = videojs(id, { fluid: true, preload: 'metadata' });

This was very tricky to implement, but well worth the effort. We have a jsbin example page where you can try out different options.

Added support for HTTP Live Streaming in desktop browsers WITHOUT Flash

We’ve been chasing down the last excuses for using Flash for video for awhile now and have reached some major milestones. videojs-contrib-hls 1.0 (it’s about time!) will use Media Source Extensions, an advanced video element API, to provide HLS playback in Chrome and Microsoft Edge. Besides the enhanced debuggability of doing everything in Javascript, most of the computation has been moved to a web worker and is hardware accelerated on platforms that support it. That means even 60fps or 4k streams should play back without a stutter and your battery will get less of a workout, too. As part of that work, we’ve split off the code we use to repackage HLS video into a separate project in the video.js org: mux.js. If you’re interested in how video works down at the bit level, check it out! We’re always looking for new contributors.

Switched from Closure Compiler to Uglify (We STOPPED mangling object properties)

In version 4.0 we introduced Google’s Closure Compiler into our build chain. It’s advanced optimizations mode saved us 25% in filesize over UglifyJS at the time. The downsides were that it required us to write the code in very specific ways and mangled internal object properties, which made contributing, debugging, and writing plugins much more difficult. The reality today is that with gzip and improved bandwidth, video.js users are pushing us less and less to squeeze the last bit of filesize out of the library. So for 5.0 we’ve switched back to UglifyJS. Plugin authors rejoice!

Improved audio-only support

Hey did you know? Video.js also supports the HTML5 audio tag. Try it out and let us know what you think.

<audio id="my_audio_1" class="video-js vjs-default-skin" controls data-setup="{}"><source src="MY_AUDIO_FILE.mp3" type="audio/mp3"></source></audio>

Added 6 more language translations

Ever since we implemented localization in Video.js there’s been a wave of contributions from all over the world. With 5.0 comes Danish, Bosnian, Serbian, Croatian, Finnish, and Turkish. This brings the number of lanugages supported to 25!

New definition around plugins

Plugins mostly have not changed from how they worked in Videojs 4.x. You still register and use them the same way.
The only major change is that if you are instantiating a plugin inside the config of a player, this plugin will get run
before the player is ready. This is so that if plugins are doing some UI work or adding themselves as children of the player
they can do so early on. This means that plugins that require the player to be ready would need to handle that themselves or
else not support instantiation via the player config. Ex:

1
2
3
4
5
videojs('my-video', {
  plugins: {
    playlists: {}
  }
});

As part of the update to videojs 5 and our switch from Google’s Closure Compiler to Uglify,
we’ve been focusing on making the plugin experience better.
We’ve made sure to export some of the utility functions that we use inside our own codebase to make writing plugins easier.
This way plugins don’t need to include extra code themselves if a function, merge, for example, is available from videojs.

Also, we’re encouraging plugin authors to publish their plugins on npm. If the plugins are tagged with videojs-plugin,
they’ll show up on our spiffy new plugins listing page.

New player skin designer on Codepen

We’re taking a slightly different approach with the designer now. Instead of exposing all CSS properties from the default skin, we’ve set up a template starter that has fewer options and allows you to get at the more common customizations more easily.

It’s also using Codepen, which is a great service and much better than hosting the designer ourselves. If you use it to make a cool skin, be sure to let us know. Tweet at @videojs or comment on the designer.

http://codepen.io/heff/pen/EarCt/left/?editors=010

New project governance model

Jumping right on that band wagon, we’re implementing a governance model for the project that’s similar to Node.js/io.js and 0MQ’s C4.1. Along with some better structure around the project it comes with a lower bar for becoming an official maintainer of the project. We’re aiming to have a more diverse set of people and companies representing the leadership of Video.js.

Improved the definition of a playback technology or “tech”

The creator of our most popular plugin (the YouTube plugin) took on the task of improving the relationship between the player and techs. “Tech” is the term we use to describe the translation layer between the player API and the underlying video objects, which can be the HTML5 video element, plugins like Flash and Silverlight, or other players like Youtube and Vimeo. If you’ve built a tech or are intersted in building one, check out the changes in 5.0.

Switched to JSDoc from a home-grown docs parser

In the last version we had a custom built docs generator that used esprima to parse the AST and create a lot of the API docs just from the code, with JSDoc tags filling in the rest. That could still be a good project, but it’s become too much to maintain and too limited for plugin authors.

For 5.0 we’ve switched to jsdoc. Check out the new docs site. Anyone want to help us design it? :)

Switched to BrowserStack for automated browser testing

For 5.0 we have moved from Sauce Labs to BrowserStack as our browser provider for automated testing. BrowserStack is a cross-browser testing tool that provides desktop and mobile browsers and are currently rolling out support for real mobile devices. We moved to BrowserStack to reduce the amount of timeout errors, build time and false positives we were seeing in our builds previously. This stability has allowed us to expand our testing coverage to include iOS, Android and all supported versions of Internet Explorer.

Switched to Fastly for our CDN

The CDN-hosted version of Video.js at vjs.zencdn.net is downloaded over 2 BILLION times every month, even with agressive browser-side caching. Video.js is relatively small in file size but that’s still 34 TB per month. We were previously piggy-backing on Brightcove’s Akamai account, but Fastly offered to host the library for free. We gave it a shot and fell in love. In full disclosure, our testing found that Fastly didn’t perform quite as well as Akamai internationally, but Fastly’s user interface, API, and real-time purge are things of beauty and make our CDN deploy process much simpler.

Video.js Logo

We simplified it a bit. What do you think?

If you don’t feel comfortable contributing to Video.js we can always use help on the website. It gets over 200,000 unique views every month. Contribute at the website repo.

HALP!

It’s our community that keeps Video.js actually decent and truly free (Apache 2), so don’t be shy. Jump in and submit a bug, build a plugin, or design a skin.

In conclusion, it’s been a good year of a lot of good work. Thanks!




]]> <p>First and foremost, <strong>THANK YOU</strong> to the 25 contributors who completed and merged <strong>146 pull requests</strong> and upd It's here: 5.0 release candidates! http://blog.videojs.com/It-s-here-5-0-release-candidates/ 2015-06-08T19:59:42.000Z 2019-01-18T19:57:55.575Z Today we’re releasing our first official 5.0 release candidate. We’re really excited to get this into the wild, but a lot has changed under hood. It should be stable for normal usage, but we’ve got a limited number of test devices (and testers for that matter), so what we need now is for people to bang on 5.0 and let us know what breaks!

You can either grab the master branch from Github and run grunt to create your own build, or we’ll push each new release candidate to the CDN. We’re going to be moving quickly and pushing new candidates when we uncover / fix bugs, so be sure to check for new versions! As of this post, the newest release is 5.0-rc.2. If you’d like to see a demo, we’ve got one up on JSBin.

What’s different?

New Base Theme

The most obvious difference you’ll see when you load up the release candidate is most likely going to be the new base theme. We’ve worked hard to simplify the theme and make it possible to do as much as possible with purely CSS.

screenshot

There are elements in the control bar that aren’t shown by default, but can be by simply overriding a little CSS. For example, if you’d rather use an inline volume control instead of the popup menu, you could make these changes:

css .video-js .vjs-volume-menu-button { display: none; } .video-js .vjs-mute-control, .video-js .vjs-volume-control { display: flex; }

This just hides the .vjs-volume-menu-button control, and unhides the mute control / inline volume control. Other things that are available but hidden by default are a time divider (.vjs-time-devider), total duration (.vjs-duration), and a spacer (.vjs-custom-control-spacer).

ES6

Thanks to the incredible Babel project, we’re able to write ES2015 and have it transpiled to ES5. It’s fantastic, and means we get glorious things such as string interpolation, so reading our codebase just got a whole lot ${_.sample(['better', 'awesomer', 'more fantastic', 'less plus-y'])}.

On our Wiki we have a page devoted to ES6 features we use extensively. There are probably a few little things missing, but if you familiarize yourself with those features you should feel comfortable reading the Video.js source.

We’re also using Browserify (with a Babelify transform), so now we’re able to take advantage of all the browser packages NPM has to offer. One big area this has allowed us to improve is utility functions, which are now provided by Lodash.

Plugins

Plugins are initialized earlier than before, giving plugin developers even more control over the player experience. They’re now initialized before other components are added (like the control bar), but after the player div is created. Keep in mind you’ll now need to wait for the ready event to do things such as append items to the control bar.

The plugin-development world should have also gotten more predictable since we’ve gotten a little less aggressive with our minification. Keep in mind that when you want to subclass a component externally (not using ES2015), you’ll want to use videojs.extends.

You can find more information on our 5.0 change details wiki page.

Want to be helpful?

Use it! We’ve spent months using this player in very specific ways while development, but there’s always the issue of “not being able to see the forest for the trees”. If you find issues while testing the player, please let us know on the issue tracker.

]]> <p>Today we&rsquo;re releasing our first official 5.0 release candidate. We&rsquo;re really excited to get this into the wild, but a lot has Video.js 4.12 - The last of the 4 minors http://blog.videojs.com/Video-js-4-12-The-last-of-the-4-minors/ 2015-02-18T13:32:00.000Z 2019-01-18T19:57:55.576Z Much improved WebVTT support

We added basic WebVTT support really early on, which we were pretty proud of. As browsers added support, however, our shim started to lag a bit, or at the very least, cause issues with browsers that required native support (here’s looking at you, iOS).

So, we’re happy to announce that our text track support is vastly improved with this version! Instead of continuing to try and build out our own WebVTT parser, we’ve pulled in Mozilla’s fantastic work, VTT.js. This is the WebVTT implementation used in Firefox / Gecko, so we’re confident that this is a substantial leap forward for Video.js and our accessibility efforts.

Don’t use captions? Feeling disappointed?

You shouldn’t feel disappointed, this is a great day! This release includes a lot of fixes, and although fixes are always exciting to the people affected, other people can feel a hefty dose of “meh”. We’re excited to say, however, that this release is exciting for another, very important reason.

This is the last minor release in the version 4 family. There might be a few patches, but from now on, master is officially version 5.0-in-waiting. Party.

party

Notable updates and fixes for 4.12

  • The hide / show methods now toggle a class (.vjs-hidden) instead of applying inline styles. Make sure to update your stylesheet as well!
  • A new .vjs-scrubbing class gets applied while, you guessed it, scrubbing so menus can be prevented from erroneously showing on hover.
  • Improved url parsing in IE9.
  • Ever wondered what version you’re using? Now there’s a VERSION key. Woot.
  • New .vjs-ended class that’s added when playback reaches the end of the timeline (also known as: ended).
  • Player networkState and readyState properties available across techs
  • Video.js is now exported as a named AMD module
  • Mobile scrolling improvements
  • And more! Fixes galore!

Translation party continues

We’re now up to 19 community submitted translations! Entirely new translations in this release include:

  • Traditional Chinese
  • Vietnamese
  • Czech
  • Catalan
  • Bulgarian
  • Turkish

Video.js in the wild

To be terribly honest, there is a level of starstruck over a few of these. Normally we just do one, but hey…

Social Media

Global News Outlets

New plugins from the community

  • videojs-Background: A plugin that allows for videos to be displayed as a full background to any element.
  • videojs-brightcoveAnalytics: Allow tracking of views/impressions & engagement data in videojs for Brightcove videos
  • videojs-caption: Have the most flexibility and power for displaying caption videojs
  • videojs-transcript: Display an interactive transcript from caption or subtitle tracks.
  • videojs-autoplay-toggle: adds an autoplay toggle which will persist to cookies or localstorage.
  • videojs-offset: Allows you to play a segment of the video.
  • videojs-youtube-progress: Preserve progress seeker when control bar is hidden.
  • projectorjs: A small no-dependencies JavaScript library that enables the display of overlays on native HTML5 video elements, or (optionally) video elements powered by videojs.
  • videojs-record: A video.js plugin for recording audio/video files.
  • videojs-dashjs: Loads dash.js as a tech to support MPEG-DASH videos.
  • videojs-silverlight: Allows you to play WMV, WMA, MP4, MP3, WAV and FLAC medias through Silverlight within Video.js.
  • videojs-vlc: Allows you to play all media through VLC web plug-in within Video.js.
  • videojs-aurora: Allows you to play WAV, OGG, MP3, M4A, AAC and FLAC medias through Aurora.js within Video.js.
  • videojs-java: Allows you to play AIFF, AVI, GSM, MID, MPG, MP2, MOV, AU and WAV medias through Java within Video.js.

Raw list of changes

  • @PeterDaveHello added a Traditional Chinese translation (view)
  • @mmcc updated the hide/show functions to use a class instead of inline styles (view)
  • @mister-ben added better handling of the additional videojs() arguments when the player is already initialized (view)
  • @anhskohbo added a Vietnamese translation (view)
  • @Sxmanek added a Czech translation (view)
  • @jcaron23 added the vjs-scrubbing CSS class and prevented menus from showing while scrubbing (view)
  • @dmlap fixed URL parsing in IE9 (view)
  • @gkatsev Fixed issue where ManualTimeUpdatesOff was not de-registering events (view)
  • @brycefisher Added a guide on player disposal (view)
  • @toniher added a Catalan translation (view)
  • @mmcc added a VERSION key to the videojs object (view)
  • @mmcc fixed an issue with text track hiding introduced in #1681 (view)
  • @dmlap exported video.js as a named AMD module (view)
  • @dmlap fixed poster hiding when the loadstart event does not fire (view)
  • @chikathreesix fixed an object delete error in Chrome (view)
  • @steverandy fixed an issue with scrolling over the player on touch devices (view)
  • @mmcc improved tap sensitivity (view)
  • @mister-ben added a vjs-ended class when playback reaches the end of the timeline (view)
  • @dmlap Add network and ready state properties (view)
  • @woollybogger exported the hasClass function (view)
  • @DevGavin fixed the Chinese translation (view)
  • @iSimonWeb added font-path variable (view)
  • @shoshomiga added a Bulgarian translation (view)
  • @ragecub3 added a Turkish translation (view)
  • @gkatsev greatly improved text track support and implemented vtt.js as the webvtt parser (view)
  • @gkatsev fixed captions showing by default in Chrome and Safari (view)
  • @mister-ben fixed a woff warning in Firefox (view)
]]> <h2 id="Much-improved-WebVTT-support"><a href="/Video-js-4-12-The-last-of-the-4-minors/#Much-improved-WebVTT-support" class="headerlink" tit Video.js 4.9 - Now <audio> can join the party! http://blog.videojs.com/Video-js-4-9-Now-can-join-the-party/ 2014-10-02T20:49:00.000Z 2019-01-18T19:57:55.577Z HTML5 Audio support

A common request we’ve seen is to be able to use Video.js with an &lt;audio&gt; tag, and now you can! Usage is almost identical, you can just include a data-setup={} attribute on an &lt;audio&gt; tag or initialize via Javascript.

&lt;audio id="audio_example" class="video-js vjs-default-skin" controls 
  preload="auto" width="600" height="600" 
  poster="/img/awesome-album-art.png" data-setup='{}'&gt;
  &lt;source src="/audio/awesome-music.mp3" type='audio/mp3'/&gt;
&lt;/audio&gt;

The only differences in behavior are that the poster image and controls are never hidden. This allows you to keep up something like album art during playback rather than a black video element. Since there’s no interesting content to hide (other than the poster image), we leave the controls showing to mimic a familiar audio player experience.

Audio Screenshot

Note: The Flash fallback still doesn’t support audio-only sources, but we’d like to add that in the future. In the meantime, audio playback with MP3 and Ogg sources should work fine in any (modern) browser that’s not IE8, so enjoy!

More translations!

We’ve been really excited by the continued support in terms of new translations. This release contains Brazilian Portuguese, Japanese, Italian, French, and Korean, as well as some improvements to the previous Spanish translation. We’d love to see the trend continue, so if you’re fluent in a language please consider submitting improvements or whole new localizations!

Video.js in the wild

Coursera is an education platform that offers free courses online from some of the world’s top institutions. They’ve built great tools for video interaction on top of Video.js, and are even going to talk about some of the work they’re doing at October’s SF Video Meetup.

Coursera Screenshot

New Plugins

videojs-wavesurfer - Adds a navigable waveform for audio files, using the excellent wavesurfer.js library.

Full list of changes

  • @deedos added a Brazilian Portuguese translation (view)
  • @baloneysandwiches added a hasClass method (view)
  • @mynameisstephen fixed an issue where slider event listeners were not being cleaned up (view)
  • @alexrqs cleaned up the Spanish translation (view)
  • @t2y added a Japanese translation (view)
  • @chikathreesix fixed an issue where data-setup options could be missed (view)
  • @seniorflexdeveloper added new translations and translation updates (view)
  • @chikathreesix exported the videojs.Flash.embed method (view)
  • @doublex fixed an issue with IE7 backwards compatibility (view)
  • @mmcc made it possible to override the font-size of captions and subtitles (view)
  • @philipgiuliani added an Italian translation (view)
  • @twentyrogersc fixed the return value when setting the poster source (view)
  • @heff updated to swf v4.5.0 to fix event issues (view)
  • @rpless made the VolumeMenuButton volume more accesible via tab navigation (view)
  • @mmcc added support for audio tags (html5 audio only) (view)
]]> <h3 id="HTML5-Audio-support"><a href="/Video-js-4-9-Now-can-join-the-party/#HTML5-Audio-support" class="headerlink" title="HTML5 Audio suppo Video.js 4.8.0 released...Prost! http://blog.videojs.com/Video-js-4-8-0-released-Prost/ 2014-09-03T16:50:09.000Z 2019-01-18T19:57:55.576Z This isn’t the flashiest minor release ever, but it’s hot off the press and ready for use. As mentioned in the last (few) release posts, we’re making a concerted effort to be more consistent with releases, so hopefully the trend of bite-sized, scheduled releases will continue.

Translations

We only just released localization with version 4.7, but we’ve already had two pull-requests for new translations! The German translation is included with this release, and you’ll find the French translation in the next patch release. If you’re fluent in another language, you can help Video.js be even more internationally accessible by submitting a pull request translating just 24 words / phrases. &lt;/shameless_plug&gt;

Video.js in the wild

Heavybit Industries has a speaker series they host at their office, and they’ve been kind enough to start posting these sessions online in their library. The experience they’ve built using Video.js is impressive, including syncing the video progress with a transcript below the player.

Heavybit Screenshot

New plugins

  • videojs-ass: Adds Advanced SubStation Alpha subtitles support.
  • videojs-hdtoggle: HD button which toggles between HD and non-HD source.

Full list of changes

  • @andekande added a German translation (view)
  • @mattosborn fixed a bug where getting the video element src would overwrite it (view)
  • @songpete fixed a bug where keyboard events were bubbling and causing additional actions (view)
  • @knabar made the inactivity timeout configurable (view)
  • @seniorflexdeveloper added language files to the distribution for including specific languages (view)
  • @gkatsev improved handling of null and NaN dimension values (view)
  • @gkatsev fixed an issue where the controls would break if Flash was initialized too quickly (view)
  • @mmcc fixed an issue where if no playback tech was supported the error could not be caught (view)
]]> <p>This isn&rsquo;t the flashiest minor release ever, but it&rsquo;s hot off the press and ready for use. As mentioned in the last (few) rel Video.js v4.7.0 - Built mostly by NEW contributors! Also Google chooses Video.js http://blog.videojs.com/Video-js-v4-7-0-Built-mostly-by-NEW-contributors-Also-Google-chooses-Video-js/ 2014-08-06T14:42:00.000Z 2019-01-18T19:57:55.606Z We’re continuing to work hard on improving the contributor experience around the Video.js project and it’s paying off. Over half of the changelog is thanks to brand new contributors! Issues and pull requests are getting addressed faster than ever, and I was even allowed to give a talk at OSCON on some of the strategies we’re using. If you’re instersted in getting involved, join the #videojs IRC room or post an issue to let us know.

Google Chooses Video.js for Google Media Framework

Google recently announced a new framework for building video experiences and monetization. There are versions of the framework for native iOS and Android apps, and for the browser they chose to use Video.js. Check out their video.js plugin, and as it says in their announcement, “Stay tuned as well for a deeper dive into Video.js with IMA soon!”

Localization

In this release we’ve built the infrastructure for displaying text in other languages. Examples of text include error messages and text used for accessibility. This feature can extend to plugins as well.

Today you can include other languages by including the JSON translations object from the language you want with the player, like in this example for Spanish (es).

videojs.options.languages['es'] = { [translations object] }

You can find translations files in the lang folder of the project. We don’t have many translations yet, but we’re looking for translators if you’d like to help!

Multiple buffered regions

With HTML5 video you can skip ahead in the video and the browser will start downloading the part of the file needed for the new position, which is different from how Flash video works by default. Flash will download from the start to the end of the file so you can only skip ahead once it has download that part of the video.

In the HTML5 video API we’re given the buffered property which returns a list of time ranges that the browser has downloaded data for. Early on in HTML5 video, browsers only ever reported one time range, but now we have a direct view of what’s been downloaded.

In the newest version of the video.js skin you can see the specific regions.

We’ve kept it subtle so it’s not too big of a change. We’d love to hear your thoughts on it.

DASH Everywhere-ish

If you haven’t seen it yet, check out the post on Tom Johson’s work getting DASH supported in Video.js, using Flash or the new Media Source Extensions. MPEG-DASH is an adaptive streaming format that Netflix and YouTube are using to stream video to cutting-edge browsers. It has the potential to replace Apple’s HTTP Live Streaming format as the main format used for adaptive streaming.

Video.js on Conan!

Conan O’Brien’s TeamCoco site is using Video.js with a nicely customized skin and ads integration. Check it out!

New Skin by Cabin

The team at Cabin put together a simple and clean new skin for video.js.

New Plugins

A lot of great new plugins have been released!

  • videojs-ima: Easily integrate the Google IMA SDK into Video.js to enable advertising on your video content.
  • videojs-brightcoveAnyaltics: Allow tracking of views/impressions & engagement data in videojs for Brightcove videos
  • videojs-logobrand: Add a logo/brand image to the player that appears/disappears with the controls. (also useful as a basic plugin template for learning how Video.JS plugins work.)
  • videojs-seek: Seeks to a specific time point specified by a query string parameter.
  • videojs-preroll: Simple preroll plugin that displays an advertisement before the main video
  • videojs-framebyframe: Adds buttons for stepping through a video frame by frame
  • videojs-loopbutton: Adds a loop button to the player
  • videojs-ABdm: Use CommentCoreLibrary to show comments (which is called as DanMu) during playing.
  • videojs-hotkeys: A plugin for Video.js that enables keyboard hotkeys when the player has focus.

New Release Schedule

As part of improving the contributor experience we’re moving to scheduled releases. We’ll now put out a release every other Tuesday as long as there’s new changes to release. This will help give everyone a better idea of when specific features and fixes will become available.

Full list from the change log

  • Added cross-browser isArray for cross-frame support. fixes #1195 (view)
  • Fixed support for webvtt chapters. Fixes #676. (view)
  • Fixed issues around webvtt cue time parsing. Fixed #877, fixed #183. (view)
  • Fixed an IE11 issue where clicking on the video wouldn’t show the controls (view)
  • Added a composer.json for PHP packages (view)
  • Exposed the vertical option for slider controls (view)
  • Fixed an error when disposing a tech using manual timeupdates (view)
  • Exported missing Player API methods (remainingTime, supportsFullScreen, enterFullWindow, exitFullWindow, preload) (view)
  • Added a base for running saucelabs tests from grunt (view)
  • Added additional browsers for saucelabs testing (view)
  • Added support for listening to multiple events through a types array (view)
  • Exported the vertical option for the volume slider (view)
  • Fixed Component trigger function arguments and docs (view)
  • Now copying all attributes from the original video tag to the generated video element (view)
  • Added files to be ignored in the bower.json (view)
  • Fixed an error that could happen if Flash was diposed before the ready callback was fired (view)
  • The up and down arrows can now be used to control sliders in addition to left and right (view)
  • Added a player.currentType() function to get the MIME type of the current source (view)
  • Fixed a potential conflict with other event listener shims (view)
  • Added support for multiple time ranges in the load progress bar (view)
  • Added vjs-waiting and vjs-seeking css classnames and updated the spinner to use them (view)
  • Now restoring the original video tag attributes on a tech change to support webkit-playsinline (view)
  • Fixed an issue where the user was unable to scroll/zoom page if touching the video (view)
  • Added “sliding” class for when slider is sliding to help with handle styling (view)

Cheers,

-heff

Discuss on Twitter | Discuss on Hacker News

]]> <p>We&rsquo;re continuing to work hard on improving the contributor experience around the Video.js project and it&rsquo;s paying off. Over h DASH Everywhere-ish (hack project) http://blog.videojs.com/DASH-Everywhere-ish-hack-project/ 2014-07-22T11:01:00.000Z 2019-01-18T19:57:55.569Z A couple of times a year Brightcove has an internal hackweek where engineers work on any project they’d like. In the latest hackweek (2014-07-14) Tom Johnson decided to see if he could get DASH supported in as many places as possible, by combining a few of the existing DASH player implementations with Video.js.

MPEG-DASH (Dynamic Adaptive Streaming over HTTP) is a streaming format similar to Apple’s HTTP Live Streaming (HLS). It allows you to provide multiple versions of a video at different bitrates, and then the player can switch between those versions depending on the user’s bandwidth (which is more complicated than you might think).

The two DASH playback implementations used were Dash.js and Dash.as. They were combined using video.js’s playback tech architecture, which means you can include plugins and custom skins and they’ll work the same with either playback method.

See the results.

Browser/Device Coverage

Using a combination of DASH.AS and DASH.JS will give us the following browser/device coverage:

DASH.JS (media source extensions support)

  • Internet Explorer: 11+
  • Chrome: 23+
  • FireFox: 25+ (upcoming version)
  • Safari (Desktop): 8+ (OSX Yosemite - Fall 2014)
  • iOS: No
  • Android: 4.2+ (Chrome)

DASH.AS

Fallback to any environment that supports Flash Player 10.3

iOS

As you can see, the one remaining holdout is iOS and there’s currently no word when or if that will happen. Seeing media source extensions support in Safari 8 gives some hope, but my understanding is the requirements for getting support built into iOS are much more significant. My guess is it will happen eventually, but not for a while (and hopefully in-line playback + the fullscreen API will be supported at the same time).

Today, to provide adaptive streaming everywhere, you still need either DASH + HLS, or just HLS (you can use the video.js HLS plugin to support HLS in more browsers).

Tom’s Notes

The demo shows that for environments which support Media Source Extensions (MSE) we use a full Javscript implementation via Dash.js and as a fallback we use Flash built around OSMF and Dash.as, an open-source plugin provided by Castlabs.

Tom has been working on videojs-osmf on the side, which helped make this possible.

DASH.AS Requirements

Player

  • Environment must support Flash Player 10.3+
  • Video.js OSMF Tech (videojs-osmf)
  • CastLabs Dash.AS plugin for OSMF (dash.as)

Server/Host

  • Since the requests are fired from within Flash, a crossdomain.xml file is required.* Ability to serve byte range requests via query string (myFile.mp4?range=0-1000 || myFile.m4s?bytes=0-1000) is necessary because Flash Player restricts use of the ‘Range’ request header. Castlabs has an .htaccess file which uses mod_rewrite to achieve this. Akamai edge servers accept the bytes query string var as well.

Notes

  • Something we may want to modify is handling the request/response portions of the workload outside of the Flash Player similar to the Video.js HLS solution. This would remove the need for having a crossdomain.xml, which cannot be normally expected to exist in a DASH focused environment.
  • Akamai edgesuite appear to be an exception to the above rule, as those domains do in fact have the crossdomain from it’s use as a serving platform under Akamai HD. The Akamai param syntax is ‘myFile.m4s?bytes=XXXX-YYYY’.
  • In it’s current form the Dash.AS manifest parser is very rigid. We may want to look into implementing a version of the DASH.JS manifest parsing on the AS side, as it is a lot more flexible in terms of structure recognition.
  • Deeper class inspection shows that the Dash.AS plugin is based on using Netstream in data generation mode, similar to our HLS solution. There may be better way to share the codebase between the two to reduce code duplication.

DASH.JS Requirements

Player

Server/Host

  • Open CORS headers: Access-Control-Allow-Origin: *
  • Accept use of the Range request header: Access-Control-Allow-Headers:Range, Options

Notes

  • Dash.js MPD parsing is significantly more robust in comparison to the Dash.AS solution.
  • Most streams tested are Akamai based, we should probably try more local and non-Akamai hosted options moving forward.* In my testing I did see a Youtube DASH/MSE example, and those streams were confirmed to work within Dash.JS as well.
  • Dash.JS streaming lifecycle and segment loading lifecycle tend to be directly coupled and don’t necessarily fire the element media events at the time expected. For example is duration. While known at the parse complete stage of the manifest load cycle, is not reported to the player until the first of the segments is received.

Tech Compatibility

The independant techs work well together. A slight modification had to be made to the Dash.AS library to insure that it only checked for resources which 1. had a URL and 2. url contained the file extension of either ‘mpd’ or ‘m4s’ for DASH manifests/segments.

NOTE: Dash.JS tech should be loaded into DOM prior to OSMF tech to insure the OSMF tech is the fallback scenario for DASH playback.

]]> <p>A couple of times a year Brightcove has an internal hackweek where engineers work on any project they&rsquo;d like. In the latest hackwee Video.js version 4.6.0 released! It's been a productive month. http://blog.videojs.com/Video-js-version-4-6-0-released-It-s-been-a-productive-month/ 2014-05-20T17:29:00.000Z 2019-01-18T19:57:55.606Z The video.js community has been in full force lately and it’s resulted in a lot of great features and fixes, including UI updates, better error messages, and even a Video.js Polymer element built by Addy Osmani himself.

New Live UI

Video.js has supported different forms of live video for a while, but a recent update has made the user experience a little clearer. Specifically, a ‘LIVE’ badge is added to the controls and the seek bar is hidden when seeking isn’t permitted.

Clearer Errors

A big effort went into improving error situations that developers and viewers might encounter. In cases where the viewer’s browser supports neither JavaScript nor HTML5 Video, a more helpful message is shown that informs the viewer how they can support video playback.

In cases where a common media error occurs (e.g. the file doesn’t exist or the network fails), an “X” icon is displayed showing that playback can’t continue, and a message is shown describing the issue. Additionally an error message is logged to the javascript console.

For developers, better logging functions have been added including videojs.log.error(), and they’re being used throughout the code base to provide better information and help track down issues.

IE11 Fullscreen

Video.js relies on native browser fullscreen even when Flash is used. IE11 is the first version of Internet Explorer to support native browser fullscreen, and video.js has now been updated to take advantage of that feature and provide a better fullscreen experience for those users.

Playback Rate Switching

If you ever wanted to speed up or slow down the rate of a video, now you can! HTML5 video browsers have been adding support for playback rate switching, and video.js now has an optional UI component that will let you select the speed. Flash however does not support playback rate switching, so unfortunately it’s not a feature that users on older browsers (e.g. IE8) can use.

See a demo.

New community plugins

The latest plugins to be added to the video.js plugins list.

  • videojs-vr: Project video onto different geometric shapes (Sphere, Cube, Cylinder) and view in 3d with optional Oculus Rift support
  • video-speed: Adds customizable video-speed control
  • OpenVideoAnnotation - create annotations in video-js using annotator
  • videojs-overlay: display simple HTML overlays during video playback
  • video.js-polymer: A video.js element for the Polymer web components framework

If you’d like a head-start on the scaffolding for a new video.js plugin, check out the Yeoman video.js plugin generator.

Full list from the change log

  • Updated the UI to support live video (view)
  • The UI now resets after a source change (view)
  • Now assuming smart CSS defaults for sliders to prevent reflow on player init (view)
  • Fixed the title element placement in menus (view)
  • Fixed title support for menu buttons (view)
  • Fixed extra mousemove events on Windows caused by certain apps, not users (view)
  • Fixed error due to undefined tech when no source is supported (view)
  • Fixed the progress bar not finishing when manual timeupdate events are used (view)
  • Added a more informative and styled fallback message for non-html5 browsers (view)
  • Added the option to provide an array of child components instead of an object (view)
  • Fixed casing on webkitRequestFullscreen (view)
  • Made tap events on mobile less sensitive to touch moves (view)
  • Fixed the default flag for captions/subtitles tracks (view)
  • Fixed compilation failures with LESS v1.7.0 and GRUNT v0.4.4 (view)
  • Added better error handling across the library (view)
  • Updated captions/subtiles file fetching to support cross-origin requests in older IE browsers (view)
  • Added support for playback rate switching (view)
  • Fixed an issue with the loadstart event order that caused the big play button to not hide (view)
  • Modernized the fullscreen API and added support for IE11 (view)
  • Added cross-browser testing with SauceLabs, and added Karma as the default test runner (view)
  • Fixed saucelabs integration to run on commits in TravisCI (view)
  • Added a clearer error message when a tech is undefined (view)
  • Added a cog icon to the font icons (view)
  • Added a player option to offset the subtitles/captions timing (view)

The new version is available on videojs.com and has been added to the CDN.

Cheers,

-heff

]]> <p>The video.js community has been in full force lately and it&rsquo;s resulted in a lot of great features and fixes, including UI updates, Video.js version 4.5.0 released! Nothing to see here, move along http://blog.videojs.com/Video-js-version-4-5-0-released-Nothing-to-see-here-move-along/ 2014-03-27T18:49:04.000Z 2019-01-18T19:57:55.606Z Well, sort of… this release is the result of a lot of hard work to speed up the version release process, meaning they’ll be coming a lot faster now with smaller sets of changes.

In this release we’ve added support for the Component(1) package manager, fixed the captions positioning when the controls are hidden, and helped Android devices know when they can support HLS. ;-) There were a few other changes as well but a lot of the work this round was done on the processes around the project. If you’ve spent time in the github issues, you’ll hopefully notice an improvement in the response rate on issues and the speed in which bugs get fixed.

New plugins

  • videojs-vast: A VideoJS plugin to play pre-roll videos from a VAST feed
  • videojs-comscore: Reports to comScore using their latest Streaming Tag SDK

Video.js in the wild

Toyota Europe! (click a video on that page) I was in Paris a few weeks ago and stopped by the Toyota store on Champs-Elysées. Next to the cars are multimedia touch screens that tell you details and allow you to watch videos. The video player looked kind of familiar, and sure enough it was video.js with a very nice custom skin. It turns out the Toyota Europe website uses video.js as well. Very cool.

If you find video.js on an interesting site somewhere, let us know in the comments.

Full list from the change log

  • Added component(1) support (view)
  • Captions now move down when controls are hidden (view)
  • Added the .less source file to the distribution files (view)
  • Changed src() to return the current selected source (view)
  • Added a grunt task for opening the next issue that needs addressing (view)
  • Fixed Android 4.0+ devices’ check for HLS support (view)

The new version is available on videojs.com and has been added to the CDN.

Cheers,

-heff

]]> <p>Well, sort of… this release is the result of a lot of hard work to speed up the version release process, meaning they&rsquo;ll be coming Video.js version 4.4.0 released - Now supporting RequireJS and Browserify http://blog.videojs.com/Video-js-version-4-4-0-released-Now-supporting-RequireJS-and-Browserify/ 2014-02-19T17:49:00.000Z 2019-01-18T19:57:55.606Z Version 4.4.0 is here with over 20 updates and fixes. The most notable addition may be support for AMD and CommonJS module loaders, meaning you can now include Video.js using RequireJS or Browserify. Video.js can be installed through npm already, and we’ll soon add support for bower and component(1) as well.

New plugins

The plugin list continues to grow, with more in the works. Checkout the new endcard plugin built by The Onion.

Video.js in the wild

The Brightcove Play 2014 website recently went live with Video.js as the player. We’re also hard at work building Brightcove’s next-gen player with Video.js at the core, so stay tuned.

Full list from the changelog

  • Made the poster updateable after initialization (view)
  • Exported more textTrack functions (view)
  • Moved player ID generation to support video tags with no IDs (view)
  • Moved to using QUnit as a dependency (view)
  • Added the util namespace for public utility functions (view)
  • Fixed an issue with calling duration before Flash is loaded (view)
  • Added player methods to externs so they can be overridden (view)
  • Fixed html5 playback when switching between media techs (view)
  • Fixed Firefox+Flash mousemove events so controls don’t hide permanently (view)
  • Fixed a test for touch detection (view)
  • Updated the src file list for karma tests (view)
  • Added more tests for API properties after minification (view)
  • Updated projet to use npm version of videojs-swf (view)
  • Added support for dist zipping on windows (view)
  • Fixed iOS fullscreen issue (view)
  • Fixed touch event bubbling (view)
  • Fixed ARIA role attribute for button and slider (view)
  • Fixed and issue where a component’s dispose event would bubble up (view)
  • Quieted down deprecation warnings (view)
  • Update seek handle to display the current time (view)
  • Added requirejs and browserify support (UMD) (view)

The new version is available on videojs.com and has been added to the CDN.

Cheers,

-heff

]]> <p>Version 4.4.0 is here with over 20 updates and fixes. The most notable addition may be support for AMD and CommonJS module loaders, meani Video.js version 4.3.0 released w/ shiny new API docs http://blog.videojs.com/Video-js-version-4-3-0-released-w-shiny-new-API-docs/ 2013-11-05T19:29:00.000Z 2019-01-18T19:57:55.606Z The biggest change in this update is actually an overhaul of the API docs. The best example of the new docs is the Player doc, which is the API most video.js users will work with.

The new docs are now automatically generated from the code and code comments, making it easier to keep them up to date with what’s currently in the codebase.

One interesting note about the doc-generator is that it uses esprima, a tool that reads javascript files and gives back the “abstract syntax tree” of the code.

For the following javascript:

var hi;

Esprima would generate:

{
    "type": "Program",
    "body": [
        {
            "type": "VariableDeclaration",
            "declarations": [
                {
                    "type": "VariableDeclarator",
                    "id": {
                        "type": "Identifier",
                        "name": "hi"
                    },
                    "init": null
                }
            ],
            "kind": "var"
        }
    ]
}

We’re using the AST of the video.js codebase to generate the majority of the information in the docs, which means it requires fewer comments and less work to keep the docs really great as we continue to build. If you’re interested in seeing how we’re handling that, check out the doc-generator repo (it’s currently only useful with the video.js codebase, but it could be extended to support more).

New CSS Options

Additional updates include new loading spinner icon options, and a new class for centering the big play button.

Many users have been clear that they’d prefer the big play button in the center of the video. While we feel the trend is still moving towards getting the play button out of the way of the content, we wanted to make this feature easier to customize. You can now use the vjs-big-play-centered class on your video tag to center the play button.

To try the new spinner icon options, check out the designer and change the icon name used by the spinner class.

Even more plugins!

Finally, the most exciting developments are actually happening in the video.js community, with more and more plugins being built. We’re up to 26 in the plugins list, with more on the way.

If you have some code you’ve built on top of video.js that you think might be valuable to others, please share it on the plugins list, or post an issue on the video.js repo if you have questions about the plugin process.

Full list from the changelog

  • Added Karma for cross-browser unit testing (view)
  • Unmuting when the volume is changed (view)
  • Fixed an accessibility issue with the big play button (view)
  • Exported user activity methods (view)
  • Added a classname to center the play button and new spinner options (view)
  • Added API doc generation (view)
  • Added support for codecs in Flash mime types (view)

The new version is available on videojs.com and has been added to the CDN.

Cheers,

-heff

]]> <p>The biggest change in this update is actually an overhaul of the <a href="https://github.com/videojs/video.js/tree/v4.3.0/docs/api" targe The Guardian uses Video.js in feature article http://blog.videojs.com/The-Guardian-uses-Video-js-in-feature-article/ 2013-11-05T18:15:11.000Z 2019-01-18T19:57:55.576Z It’s always nice to find Video.js in the wild, but this article from The Guradian is an especially cool use case. Most of the players don’t use controls at all, but rather play/pause based on the user scrolling the page. The ones that do use controls are styled with a white on light gray theme that matches the rest of the page really well.

The article begins with a full-width video that includes controls.
Big Player

Most of the videos are short dialogs that are triggered based on scrolling to a certain point in the page. These have no controls other than an external play/pause button.
No Controls

Smaller player with controls.
Small Player

]]> <p>It&rsquo;s always nice to find Video.js in the wild, but this <a href="http://www.theguardian.com/world/interactive/2013/nov/01/snowden-n 4.2.2 Patch Release http://blog.videojs.com/4-2-2-Patch-Release/ 2013-10-15T18:26:00.000Z 2019-01-18T19:57:55.568Z Two bugs have been squashed with this patch:

  • An issue most commonly seen in Firefox where video playback would break when a race condition would occur during video loading (#756)
  • An issue where the duration would get stuck at 0:00 when loading the player dynamically (#775)

See the changes made

This version can be downloaded on videojs.com, is available on the CDN, and the existing /4.2/ CDN version has been updated to 4.2.2. (may take time to propagate to your area)

Cheers,

-heff

]]> <p>Two bugs have been squashed with this patch:</p> <ul> <li>An issue most commonly seen in Firefox where video playback would break when a Running Video.js unit tests in real browsers with Karma http://blog.videojs.com/Running-Video-js-unit-tests-in-real-browsers-with-Karma/ 2013-09-18T23:21:00.000Z 2019-01-18T19:57:55.576Z If you’ve ever cloned the video.js repository, either to contribute or to build your own version, you’ve no doubt run the video.js unit tests. Until just recently, though, we only had support for running unit tests with grunt, using the PhantomJS browser. Well, that’s changed, with the first phase of our integration with Karma. Now, you’ll be able to run your tests in real browsers.

Setting things up is a snap. After you pull down the latest from video.js and run npm install, simply copy the test/karma.conf.js.example file to test/karma.conf.js, add the browsers you wish to test to the browsers array, and run grunt karma:dev. That’s it. Of course, there are more options that you can configure, but if you want to get the ball rolling quickly, just add browsers, and run the tests. See the test/karma.conf.js.example file for more instructions.

For our next phases of integration, we’re planning to include support for running tests on mobile devices, as well as running these tests in a publicly-available location, so that anyone can tell at a glance how things are going.

You can learn more about Karma here.

Cheers!

-Jim

]]> <p>If you’ve ever cloned the video.js repository, either to contribute or to build your own version, you’ve no doubt run the video.js unit t Unauthorized modification of Video.js CDN files http://blog.videojs.com/Unauthorized-modification-of-Video-js-CDN-files/ 2013-09-15T11:23:00.000Z 2019-01-18T19:57:55.576Z UPDATE 2013-09-19:

The CDN continues to be secure and we have taken significant steps to ensure it never falls under a similar attack again.

  • Access to the CDN has been restricted to a few key individuals
  • A third-party service is now monitoring changes made to the CDN
  • Processes have been defined for responding to any such future issues

The original source of this event was the Sendori Auto-update Hack, which possibly affected millions of people including, unfortunately, an admin of the CDN.

On the morning of September 14, 2013 at 6:25am PDST, we discovered that certain versions of video.js being served from our content delivery network (CDN) had been modified by an unknown attacker. The file was changed to contain malicious code that would attempt to install malware on any Windows or Macintosh computer that loaded the video.js file. The malware has been identified to be a variant of Trojan.PWS.Stealer.1932 or Trojan.Ransom.ED. We quickly reverted to safe versions of the video.js file, and took steps to ensure that the issue could not reoccur.

The specific files affected were:

vjs.zencdn.net/c/video.js

vjs.zencdn.net/4.0/video.js

vjs.zencdn.net/4.1/video.js

No patch-level versions (e.g. vjs.zencdn.net/4.1.0/video.js) were affected, and neither was the latest version (4.2). Users who host their own copy of Video.js were also not affected.

Potential Impact: Any browsers that loaded the affected files during the compromised period may have prompted users to install malicious software on their computers.

It has been determined that the files were originally modified at 4:30am PDST. The files were repaired at 7:15am PDST and completed propagation to CDN edge caches around the world at 7:51am PDST.

Rest assured that video.js is once again safe to load. We are currently investigating the root cause. Once we fully understand the nature of the incident, we will provide an update with additional information.

Keeping our users safe is one of our top priorities, and we sincerely apologize to anyone who was negatively impacted by this event.

]]> <p><strong>UPDATE 2013-09-19:</strong></p> <p>The CDN continues to be secure and we have taken significant steps to ensure it never falls un Video.js 4.2.0 released! RTMP, CSS designer, and stability http://blog.videojs.com/Video-js-4-2-0-released-RTMP-CSS-designer-and-stability/ 2013-09-06T15:51:00.000Z 2019-01-18T19:57:55.576Z Happy September! The 4.2.0 release of Video.js has a few interesting updates, and a bunch of stability and polish.

RTMP Support

First of all, thanks to an impressive collaboration of community members, we now have RTMP support (in beta). Check out the example.

It’s still pretty basic support for RTMP, but we think it will cover a lot of the general use cases. The feature support includes:

  • Single stream (no client-side adaptive support)
  • Flash only, HTML5 video doesn’t support RTMP (but HLS is supported on iOS devices)
  • On-demand only. We haven’t updated the UI to support live yet.

To load an RTMP stream in a Video.js player, you’ll use a source tag in the same way you would other source types:

<source src="rtmp://your.streaming.provider.net/cfx/st/&mp4:path/to/video.mp4" type="rtmp/mp4">

The connection and stream parts are determined by splitting the URL on the first ampersand (&) or the last slash (/).

[http://myurl.com/streaming&/is/fun](http://myurl.com/streaming&/is/fun) -->
  connection: [http://myurl.com/streaming](http://myurl.com/streaming)
  stream: /is/fun

-or-

[http://myurl.com/streaming/is/fun](http://myurl.com/streaming/is/fun) -->
  connection: [http://myurl.com/streaming/is](http://myurl.com/streaming/is)
  stream: fun

The available source types include rtmp/mp4 or rtmp/flv.

RTMP has been a much requested feature over the years and it’s great to finally have it in the player. Thanks to everyone involved in that work.

Player Skin Designer

If you missed the previous blog post, be sure to check out the new interface for designing the player skin. It really shows off the customizability of the video.js controls, which are built completely in HTML and CSS.

With the 4.2 release the styles in the designer have been brought up-to-date with the latest player styles.

Control Bar Updates

Also in a previous post, I described a number of updates that were made to the control bar to fix cross browser/device issues and improve the overall functionality. As of 4.2.0 all of those updates have made it into the stable release.

Other Updates

Along with previous updates there’s been a number of patches and enhancements along the way. Here’s a full list:

  • Added LESS as a CSS preprocessor for the default skin (view)
  • Exported MenuButtons for use in the API (view)
  • Fixed ability to remove listeners added with one() (view)
  • Updated buffered() to account for multiple loaded ranges (view)
  • Exported createItems() for custom menus (view)
  • Preventing media events from bubbling up the DOM (view)
  • Major reworking of the control bar and many issues fixed (view)
  • Fixed an issue with minifiying the code on Windows systems (view)
  • Added support for RTMP streaming through Flash (view)
  • Made tech.features available to external techs (view)
  • Minor code improvements (view)
  • Updated time formatting to support NaN and Infinity (view)
  • Fixed an undefined error in cases where no tech is loaded (view)
  • Exported addClass and removeClass for player components (view)
  • Made the fallback message customizable (view)
  • Fixed an issue with the loading spinner placement and rotation (view)
  • Fixed an issue with fonts being flaky in IE8

The latest version can be found on videojs.com through the download link or the CDN hosted version.

Cheers,

-heff

]]> <p>Happy September! The 4.2.0 release of Video.js has a few interesting updates, and a bunch of stability and polish.</p> <h2 id="RTMP-Suppo Hiding and Showing Video Player Controls http://blog.videojs.com/Hiding-and-Showing-Video-Player-Controls/ 2013-08-09T18:51:47.000Z 2019-01-18T19:57:55.575Z Last week I decided to tackle a number of outstanding issues around the control bar, and then proceeded to fall down a rabbit hole of related player updates. I’ve thankfully resurfaced now, and figured I’d write about a few of the updates that came from it.

One of the expected behaviors of the player’s control bar is that it will fade out after a couple of seconds when the user is inactive while watching a video. Previously, the way we achieved this with video.js was through a bit of a CSS trick. When the user’s mouse would move out of the video player area, the control bar would be given the classname vjs-fade-out. This class had a visibility transition with an added 2 second delay.

.vjs-fade-out {
  display: block;
  visibility: hidden;
  opacity: 0;

  -webkit-transition: visibility 1.5s, opacity 1.5s;
     -moz-transition: visibility 1.5s, opacity 1.5s;
      -ms-transition: visibility 1.5s, opacity 1.5s;
       -o-transition: visibility 1.5s, opacity 1.5s;
          transition: visibility 1.5s, opacity 1.5s;

  /* Wait a moment before fading out the control bar */
  -webkit-transition-delay: 2s;
     -moz-transition-delay: 2s;
      -ms-transition-delay: 2s;
       -o-transition-delay: 2s;
          transition-delay: 2s;
}

When the user’s mouse moved back over the player, the class would be removed, canceling any delayed fade-out. This provided a similar experience to how you might expect the controls fading to work, and only took a few lines of javascript to add/remove the class.

player.on('mouseout', function(){ 
  controlBar.addClass('vjs-fade-out'); 
});

player.on('mouseover', function(){ 
  controlBar.removeClass('vjs-fade-out'); 
});

There’s a few drawbacks though that have made it necessary to move away from this approach.

  1. Controls don’t fade out in fullscreen mode because the mouse can never move out of the player area.
  2. There is no mouse on mobile devices so different events and interactions are needed to show/hide the controls.

In addition to these issues, we want it to be possible for any player component or plugin to hook into the same trigger that hides the controls. Components like social sharing icons should fade out in the same way that the controls do.

User State

One of the first things that is being added is a userActive property on the player, that can be either true or false. What this does is abstract the controls hiding out to what it is we’re actually concerned with, that is, whether the user is currently interacting with the player or just passively watching the video. This also decouples the control bar from tracking the user activity itself, and allows other components to more easily behave the same way as the control bar, through a player-level state.

That actual property is player.userActive() and returns either true or false. When this value is changed, it triggers an event on the player.

player.userActive(true)
    // -> 'useractive' event triggered
player.userActive(false)
    // -> 'userinactive' event triggered

A CSS classname of either vjs-user-active or vjs-user-inactive is also added to the player element. The classname is what’s actually used now to hide and show the control bar.

.vjs-default-skin.vjs-user-inactive .vjs-control-bar {
  display: block;
  visibility: hidden;
  opacity: 0;

  -webkit-transition: visibility 1.5s, opacity 1.5s;
     -moz-transition: visibility 1.5s, opacity 1.5s;
      -ms-transition: visibility 1.5s, opacity 1.5s;
       -o-transition: visibility 1.5s, opacity 1.5s;
          transition: visibility 1.5s, opacity 1.5s;
}

The 2 second delay has been removed from the CSS, and instead will be built into the process of setting the userActive state to false through a javascript timeout. Anytime a mouse event occurs on the player, this timeout will reset. e.g.

var resetDelay, inactivityTimeout;

resetDelay = function(){
    clearTimeout(inactivityTimeout);
    inactivityTimeout = setTimeout(function(){
        player.userActive(false);
    }, 2000);
};

player.on('mousemove', function(){
    resetDelay();
})

The mousemove event is called very rapidly while the mouse is moving, and we want to bog down the player process as little as possible during this action, so we’re using a technique written about by John Resig.

Instead of resetting the timeout for every mousemove, the mousemove event will instead set a variable that can be picked up by a javascript interval that’s running at a controlled pace.

var userActivity, activityCheck;

player.on('mousemove', function(){
    userActivity = true;
});

activityCheck = setInterval(function() {

  // Check to see if the mouse has been moved
  if (userActivity) {

    // Reset the activity tracker
    userActivity = false;

    // If the user state was inactive, set the state to active
    if (player.userActive() === false) {
      player.userActive(true);
    }

    // Clear any existing inactivity timeout to start the timer over
    clearTimeout(inactivityTimeout);

    // In X seconds, if no more activity has occurred 
    // the user will be considered inactive
    inactivityTimeout = setTimeout(function() {
      // Protect against the case where the inactivity timeout can trigger
      // before the next user activity is picked up  by the 
      // activityCheck loop.
      if (!userActivity) {
        this.userActive(false);
      }
    }, 2000);
  }
}, 250);

That may be a lot to follow, and it’s a bit simplified from what’s actually in the player now, but essentially it allows us to take some of the processing weight off of the browser while the mouse is moving.

Hiding controls in fullscreen

Thanks to the new userActive state and the javascript timeout for the delay, the controls no longer require the mouse to move outside of the player area in order to hide, and can now hide in fullscreen mode the same way they do when the player is in the page. This also means we can now hide the mouse cursor in the same way we do the controls, so that it doesn’t sit over the player while watching in fullscreen.

.vjs-fullscreen.vjs-user-inactive {
  cursor: none;
}

Hiding controls on touch devices

The expected behavior on touch devices is a little different than in desktop browsers. There is no mousemove event to help determine if the user is active or inactive, so typically a longer delay is added before the controls are faded out. Also, while a click on the video itself in desktop browsers will typically toggle between play and pause, a tap on the video on mobile devices will toggle the controls visibility.

Luckily the framework we’ve set up around userActive has made this last part easy enough to set up.

video.on('tap', function(){
  if (player.userActive() === true) {
    player.userActive(false);
  } else {
    player.userActive(true);
  }
});

Manually toggling userActive between true and false will apply the appropriate classnames and trigger the events needed to show and hide the controls as you’d expect on a mobile device.

The tap event is actually a custom made event, similar to the tap event you’ll find in jQuery mobile, Hammer.js, and other mobile touch libraries. A tap event occurs whenever a touchstart event is fired with the associated touchend event firing within 250 milliseconds. If the touchend event takes longer to fire, or if a touchmove event happens between the two, it is not considered a tap.

Conclusion

I hope this has given some insight into how that piece of the controls operate in Video.js, and how you can mimic the same interaction if you’re building your own plugins for Video.js. Feedback is always appreciated.

Cheers,

-heff

]]> <p>Last week I decided to tackle a number of outstanding issues around the control bar, and then proceeded to fall down a rabbit hole of rel New Player Skin Designer for Video.js http://blog.videojs.com/New-Player-Skin-Designer-for-Video-js/ 2013-07-15T19:44:00.000Z 2019-01-18T19:57:55.576Z

Last week Brightcove had an internal hack week where everyone could work on any project they wanted. One of the projects that came out of that was a new video.js skin designer.

The designer allows you to watch changes happen to the skin live as you edit the CSS, making it easier to create a custom look.

Check out this familiar looking example that was done in just a few minutes.

Try creating your own and let us know what you think. Better yet, create your own, share it on CodePen.io and post a link in the comments. (It’s probably easiest if you start by forking this unedited example.)

One of my favorite things about video.js is that the skins are built in HTML and CSS, while working across both HTML5 and Flash video. I think this designer does a nice job of showing off how easy that makes it to customize a player’s skin.

Some notes on how we built it…

As a starting point we used Brian Frichette’s awesome LESS2CSS, which gave us a huge head start. Brian has offered to help with the skin designer as well, so that’s great!

We haven’t added a CSS preprocessor to video.js before because we didn’t want the extra layer of abstraction, or the extra step in the build process. When looking at the CSS in the new designer however, it became clear how valuable things like variables can be for helping people understand what’s happening in the CSS. Still, we’re trying to find the balance between using LESS features and keeping the CSS easily readable by anyone who just knows CSS. That means avoiding some of the more advanced LESS features like conditional statements (though we do use one for big play button positioning).

We chose to use LESS because of the ability to parse the LESS markup in javascript in the browser. I’m not aware of any up-to-date in-browser SASS parsers. The completeness of LESS2CSS also influenced that decision. We’re using a small enough subset of features that it doesn’t really matter which one we use otherwise, though I do like the idea of using $ for variables over @.

It’s hosted on Nodejitsu, and we’re taking advantage of their free hosting for open source. I have to say, it was pretty simple to get the app deployed with their command line tool.

Let us know if you have any thoughts. The code for the designer can be found here: https://github.com/videojs/designer

Cheers,
-heff

]]> <p><a href="http://designer.videojs.com" title="Video Player Skin Designer" target="_blank" rel="external"><img src="http://65.media.tumblr. Video.js 4.1.0 Released http://blog.videojs.com/Video-js-4-1-0-Released/ 2013-06-28T19:34:00.000Z 2019-01-18T19:57:55.576Z Just in time for the weekend, the next minor version of Video.js is now available. Updates include:

  • Turned on method queuing for unready playback technologies (flash) (view)
  • Blocking user text selection on player components (view)
  • Exported requestFullScreen() and cancelFullScreen() in the minified version (view)
  • Exported the global players reference, videojs.players (view)
  • Added google analytics to the CDN version (view)
  • Exported fadeIn/fadeOut for the Component API (view)
  • Fixed an IE poster error when autoplaying (view)
  • Exported bufferedPercent for the API (view)
  • Augmented user agent detection, specifically for Android versions (view)
  • Fixed IE9 canPlayType error (view)
  • Fixed various issues with captions (view)

You can get the latest version on videojs.com, either as a download or hosted on our CDN.

Have a great weekend!

-heff

]]> <p>Just in time for the weekend, the next minor version of Video.js is now available. Updates include:</p> <ul> <li>Turned on method queuing Video.js 4.0 now available! http://blog.videojs.com/Video-js-4-0-now-available/ 2013-05-09T13:10:00.000Z 2019-01-18T19:57:55.576Z Today we’re releasing Video.js 4.0, which is the most solid, lightweight, and I dare say prettiest version yet. It’s available for download, on Github, and hosted for free on our CDN.

Version 4.0 received the most community collaboration of any previous version, which speaks to the growing strength of the JavaScript community, the growing popularity of HTML5 video, and an increase in Video.js usage. Over the last year the number of sites using Video.js has more than doubled, and each month there are over 200 million hits to the CDN-hosted version alone! Thank you to all of the Video.js community members for contributing code and filing bug reports.

This version is also a milestone in that it’s the first version released since Brightcove acquired Zencoder last year. For those who missed the announcement, it was a very good thing for Video.js. In the past, Video.js was a side project for Zencoder that I maintained on top of my regular responsibilities (as if startup life isn’t exciting enough). Post-acquisition, Brightcove has not only put me full-time on Video.js, but the Brightcove video player team has become contributors to the project. The Brightcove team is probably the most experienced video player team in the world, supporting the most advanced video technology, for the biggest brands, across all the devices. It’s been a privilege to work with them and they’ve made major contributions to this version.

4.0 Major Feature Summary:

Improved performance through an 18% size reduction using Google Closure Compiler in advanced mode

  • Greater stability through an automated cross-browser/device test suite using TravisCI, Bunyip, and Browserstack.
  • New plugin interface and plugin listing for extending Video.js
  • New default skin design that uses font icons for greater customization
  • Responsive design and retina display support
  • Improved accessibility through better ARIA support
  • Moved to Apache 2.0 license
  • 100% JavaScript development tool set including Grunt

Improved Performance

With version 4.0, performance was our top priority, and a major factor of performance is the time it takes to load the library. What would seem to be minor size reductions can have a big impact, especially when a library will be loaded millions of times a month all over the world. We chose to use Google’s Closure Compiler because its “advanced mode” currently provides the most aggressive options for code minification, and so far we’ve seen an 18% reduction in code size, with the potential for more.

Closure Compiler also claims to rewrite code for better runtime performance, though we haven’t had a chance to benchmark this yet.

Some preliminary load-time benchmarking* shows:

  • Player load times in under 50 milliseconds
  • Playback start times in under 150 milliseconds
  • Actual video playback seen in under 0.5 seconds (using a CDN hosted MP4)

*Initial tests used Chrome with an empty cache on a modern MacBook Pro with a Wi-Fi connection. More formal testing to follow.

Greater Stability

Automated cross-browser, cross-device testing is the Holy Grail of testing for a JavaScript library. While building version 4.0, we’ve been able to reach that goal through the use of a number of tools, including:

  • TravisCI - Automatically runs unit tests through PhantomJS on every pull request made to the Video.js source code
  • Bunyip + Browserstack - Allows us to run tests in cloud-hosted instances of any browser from IE6 to the latest Chrome, and also a wide range of iOS and Android devices.

This ability to easily run tests across environments before any new release will give us more protection against regressions, and can allow for a faster feature release cycle.

New Plugin Interface

The new plugins API allows developers to more easily add custom features to Video.js. The API works similarly to the jQuery plugin interface, giving developers access to add to or overwrite any piece of Video.js. Once a plugin has been created, it can be shared on the Video.js plugin list page on the wiki.

New Default Skin

With help from the Brightcove UX team, we’ve created a new default skin that’s simpler, more polished, and more customizable. One of the most interesting features is that we’ve moved from using images for icons to font icons. The use of font icons allows you to change the color and size of the icons simply by changing a CSS value. You can see an example of this on the Video.js homepage.

Improved Accessibility

Greg Kraus, a Video.js community member from NCSU.edu, did some great work testing and improving Video.js accessibility through better use of ARIA roles. The changes make it so keyboard-only users, screen reader users, and voice-interface users will be able to interact with the video player. UPDATE: Read more in Greg’s blog post.

Moved to Apache 2.0 License

Earlier versions of Video.js were released under the LGPLv3 license. LGPL often gets confused with its stricter sibling, GPL, which requires that all code the software touches must also be open source. Video.js is meant to be open and free to use in all contexts, and we want that to be clear, so version 4.0 is now released under Apache 2.0, the same license Twitter Bootstrap is released under.

100% JavaScript Tool Set

Previously Video.js used Ruby for development tools, including Rake for deployment tasks, and zenflow–an internal Zencoder tool that builds on gitflow for development process workflow. With 4.0 we’ve moved to Grunt for tasks and we’re building out a tool similar to zenflow in Node.js.

Videojs.com Now Open Source

As part of this release we’ve also made the Videojs.com website open source. So if you see something that should be added or fixed, fork it.

What now?

Even with all of the updates listed above, this is simply a jumping-off point for what will be an exciting year for Video.js. We’re continuing to improve performance, multi-platform stability, and customizability through plugins and skins. Members of the community have already started work on plugins for some of the more requested features, like playlists, analytics, and advertising.

Follow @videojs or sign up for our newsletter to stay up-to-date on new features and roadmap updates.

If you’d like to get involved in the project, check out our contributing guide.

Cheers,
-heff

]]> <p>Today we&rsquo;re releasing Video.js 4.0, which is the most solid, lightweight, and I dare say prettiest version yet. It&rsquo;s availabl Repo Moved! http://blog.videojs.com/Repo-Moved/ 2013-05-06T16:56:59.000Z 2019-01-18T19:57:55.576Z In preparation for the next version we’ve moved the source code repository from github.com/zencoder/video-js to github.com/videojs/video.js

If you have a local clone you can update your clone’s upstream URL with:

git remote set-url upstream git://github.com/videojs/video.js.git

The relationship between your fork (e.g. github.com/you/video-js) should still be intact, including any pull requests.

Cheers,
-heff

]]> <p>In preparation for the next version we&rsquo;ve moved the source code repository from github.com/zencoder/video-js to <a href="http://git Site and Support Updates http://blog.videojs.com/Site-and-Support-Updates/ 2012-11-15T14:54:18.000Z 2019-01-18T19:57:55.576Z After a brief hiatus of helping Brightcove and Zencoder come together, I’m moving full time to developing and supporting Video.js. Thank you to everyone who has continued to commit code and help out in the forums.

As part of this move I’m trying to optimize the tools used for video.js project management and support. The first big change is that the forums are being replaced with Stack Overflow (tag with “video.js”) and Github Issues.

Over the last few years Video.js has become more popular than I ever expected, and at the same time Stack Overflow has come up as an incredible tool for supporting developer communities. So along with many other projects like Facebook, Android, and HTML5 Boilerplate, I’m excited to move support to Stack Overflow’s awesome tool and community. I’ll be leaving the forums up for bit but from here forward please post questions to Stack Overflow and use the “video.js” tag.

I’ve also begun cleaning up and organizing the Github Issues for Video.js, which previously existed, but issues were split between the forum and Github. If you find specific bugs with video.js please submit them there.

On the project management side of things I’ll be using Trello, and exposing boards so others can see the progress of development.

I’m also paring down the site and moving more complex sections to other services that can better handle them. I’ve already moved the blog to Tumblr, and I’m moving the docs to the Github repo, which has built-in docs formatting.

For those starting an open source project today, you can look at this as my guide to supporting an open source project. I wish I would have know to do all this when I started on Video.js.

More project updates coming soon.

Cheers,
-heff

]]> <p>After a brief hiatus of helping <a href="http://blog.videojs.com/post/35666994917/brightcove-acquires-zencoder" title="Zencoder acquired Brightcove Acquires Zencoder http://blog.videojs.com/Brightcove-Acquires-Zencoder/ 2012-07-26T00:00:00.000Z 2019-01-18T19:57:55.569Z

Today, Zencoder announced that it is being acquired by Brightcove, the leading online video platform (OVP). You can read more on the specifics in the Zencoder blog post and press release, but I also wanted to be clear on what this means for Video.js. As you may know, Video.js was created by me (Steve Heffernan, Co-founder of Zencoder) and Zencoder continues to be its core contributor and sponsor (like 37signals to Rails or Joyent to Node.js).

This acquisition means only great things for Video.js. To quickly summarize, Video.js will continue to be a free and open source video player & framework, and Brightcove will be investing more in Video.js than Zencoder ever could.

I wrote the first version of Video.js in early 2010 during Zencoder’s time in Y Combinator (while secluded in our rented house deep in the Santa Cruz mountains). Over the past few years I’ve continued to build the library and pull in contributions from other Zencoder team members and the community, but only on the side of my ongoing Founder and VP of Marketing duties at Zencoder. While Video.js has continued to gain popularity among developers and is now being used on over 25,000 websites, there’s still work to be done and room to grow. So one of the more significant changes that will be happening is that Brightcove will be putting me on Video.js full time, freeing me up to work on the core of the project and to better support the Video.js community, both users and contributors.

Beyond this, Brightcove has a first-class player development team backing their platform’s video player. While the specifics of how the two teams and players will work together are still being discussed, we have agreement on our philosophies and views about where player technology is going. This combined knowledge and collaboration is sure to have a positive impact for both players.

While the additional resources will have a big impact, the best open source software projects only got to where they are through the contributions of developers in the community. So if you’ve previously been cautious to dig into the source or push back a specific feature or bug fix, I hope this news only helps encourage you to jump in and help make Video.js the best resource for working with video in the browser.

There will be more info to come as things progress, but please feel free to ask any questions in the comments below.

Cheers,

Steve & The Zencoder Team

]]> <p><img src="http://66.media.tumblr.com/tumblr_mdgad5rr0S1qzc111.png" alt=""></p> <p>Today, Zencoder announced that it is being acquired by Version 3.2 Update http://blog.videojs.com/Version-3-2-Update/ 2012-03-23T00:00:00.000Z 2019-01-18T19:57:55.576Z First of all, check out the new video tag builder. The previous version of this site had an embed code builder, and people were pretty disappointed that the new site didn’t. So I’m happy to announce that it’s available again, now as an HTML5 video tag builder that could probably be used outside of Video.js, it includes track tags, and even lets you test the settings. Let me know if you have any feedback on it.

The most notable change in this release is probably the completely overhauled <track> tag support.

https://gist.github.com/4092295.js?file=html5-track-tag.html

The new version supports subtitles, captions, and even chapters. When you include tracks of different kinds, Video.js will automatically create menus in the player where users can select the language to display, or which chapter to jump to. Video.js also now supports the new WebVTT text format, which is not far off from the previously supported WebSRT format but did take some tweaking in the parser. Not all WebVTT placement features are supported yet, but the basics of displaying text are, and we’ll be working to get more WebVTT features built in.

Additionally there was work done to make some API methods accessible earlier. For any method that isn’t a getter (returns a specific value from the player), if you call the method before the playback technology (HTML5/Flash) is ready, it will now cache the call until it is ready. So where previously you might have had to wait for the ready callback:

https://gist.github.com/4092295.js?file=wait-for-ready.js

You could now do:

https://gist.github.com/4092295.js?file=no-wait-for-ready.js

Again, that’s just for methods where you are setting a value or triggering an action. If you try to get a value back like myPlayer.duration(), you’ll get nothing until the player is ready.

One other feature that was requested in the forums was automatically translating relative video URLs to absolute URLs for the flash fallback. This was an issue with the CDN hosted version which involved loading a remote SWF file which didn’t have the same context as the player. Before we would just tell people to use full URLs (http://) but that shouldn’t be an issue anymore.

Thanks to everyone that’s helped contribute code lately, and apologies for any long response times in the forums as I continue to try to push out code.

Here’s the full change log for the release.

3.2.0 / 2012-03-20 / baxter

  • Updated docs with more options.
  • Overhauled HTML5 Track support.
  • Fixed Flash always autoplaying when setting source.
  • Fixed localStorage context
  • Updated ‘fullscreenchange’ event to be called even if the user presses escape to exit fullscreen.
  • Automatically converting source URL to absolute for Flash fallback.
  • Created new ‘loadedalldata’ event for when the source is completely downloaded
  • Improved player.destroy(). Now removes elements and references.
  • Refactored API to be more immediately available.

Cheers,
-Heff

]]> <p>First of all, check out the new <a href="/Version-3-2-Update//tag-builder/">video tag builder</a>. The previous version of this site had Version 3.1 Update http://blog.videojs.com/Version-3-1-Update/ 2012-01-30T00:00:00.000Z 2019-01-18T19:57:55.576Z This is the first release since the initial 3.0 launch, aside from some hotfixes that went out immediately. It includes a number of fixes for things that users in the forums found right off the bat.

One feature that’s optional for testing in this release is iFrame Mode for Flash. One the of the unique things about Video.js is we haven’t built any controls into our Flash player, and instead use HTML and CSS to create the controls for the Flash side as well. This keeps the experience consistent and the Flash player very lightweight, however there’s a number of issues that you run into with Flash when you take an approach like this. If you’ve ever tried to resize the parent of a Flash object, or hide a Flash object and then show it again, you’ve probably run into the issue of Flash reloading in Firefox. This is a bug that’s been in Firefox for quite a long time however it looks like it might be fixed by version 13 (currently 9). To add on top of this, with the new browser fullscreen API, the other browsers now also reload Flash when you go to native fullscreen.

We’ve found a bit of a fix where if you embed the Flash object in an iframe first, it can get around the reloading in some of these cases. So in the new version there’s an option to turn this on and try it.

https://gist.github.com/4092929.js?file=iframe-mode.js

We’ll be doing some more testing to make sure it’s stable before we push it out to everyone.

Here’s the full change log for the release.

3.1.0 / 2012-01-30 / leonardo

  • Added CSS fix for Firefox 9 fullscreen (in the rare case that it’s enabled)
  • Replaced swfobject with custom embed to save file size.
  • Added flash iframe-mode, an experimental method for getting around flash reloading issues.
  • Fixed issue with volume knob position. Improved controls fading.
  • Fixed ian issue with triggering fullscreen a second time.
  • Fixed issue with getting attributes in Firefox 3.0
  • Escaping special characters in source URL for Flash
  • Added a check for if Firefox is enabled which fixes a Firefox 9 issue
  • Stopped spinner from showing on ‘stalled’ events since browsers sometimes don’t show that they’ve recovered.
  • Fixed CDN Version which was breaking dev.html
  • Made full-window mode more independent
  • Added rakefile for release generation

Cheers,
-Heff

]]> <p>This is the first release since the initial 3.0 launch, aside from some hotfixes that went out immediately. It includes a number of fixes Video.js Version 3.0! http://blog.videojs.com/Video-js-Version-3-0/ 2012-01-10T00:00:00.000Z 2019-01-18T19:57:55.606Z After months and months of work we’re happy to announce Video.js version 3.0. Some of the exiting new features include:

  • Same HTML/CSS Skin for both HTML5 and Flash video
  • Super lightweight Flash fallback player for browsers that don’t support HTML5 video
  • Free CDN hosting by Level3 A lot more releases and developments are on their way!

Cheers,
-Heff

]]> <p>After months and months of work we&rsquo;re happy to announce Video.js version 3.0. Some of the exiting new features include:</p> <ul> <l Lynda.com HTML5 Video Tutorial Released http://blog.videojs.com/Lynda-com-HTML5-Video-Tutorial-Released/ 2011-06-17T00:00:00.000Z 2019-01-18T19:57:55.575Z Lynda HTML5 Video Tutorial

I recently filmed a series of HTML5 video tutorials for Lynda.com, a really great service for online training. It was a great experience, and the videos are now available for viewing. You can get a 7-day free trial here and check them out. Let me know if they’re helpful at all.

-Heff

]]> <p><a href="http://goo.gl/y0SZb" target="_blank" rel="external"><img src="http://videojs.com/img/blog/2011/06/lynda_com.jpg" alt="Lynda HTML How are you using video.js? http://blog.videojs.com/How-are-you-using-video-js/ 2011-06-07T00:00:00.000Z 2019-01-18T19:57:55.575Z I’d love to hear where and how people are using video.js. If you’re using it somewhere, leave a note/link in the comments.

Cheers,
-Heff

]]> <p>I&rsquo;d love to hear where and how people are using video.js. If you&rsquo;re using it somewhere, leave a note/link in the comments.</p New MPEG LA WebM/VP8 Patent Pool http://blog.videojs.com/New-MPEG-LA-WebM-VP8-Patent-Pool/ 2011-02-11T00:00:00.000Z 2019-01-18T19:57:55.576Z One of the things that browser and device vendors stand behind when deciding to support MP4/h.264 over Google’s Webm video format and VP8 codec, is that while VP8 is open source, it may still be encumbered by patents. So far none of these submarine patents have surfaced, but now MPEG LA has put out a call, and hopes to form a patent pool that would create a license for VP8, and essentially put a price on it. In Google’s own license, it says:

“If you or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of VP8 or any code incorporated within this implementation of VP8 constitutes direct or contributory patent infringement, or inducement of patent infringement, then any patent rights granted to you under this License for this implementation of VP8 shall terminate as of the date such litigation is filed.”

So if you claim VP8 infringes on a patent and sue, your license to use VP8 is terminated. Not sure exactly how that would affect a patent pool, but an interesting battle could be ahead.

]]> <p>One of the things that browser and device vendors stand behind when deciding to support MP4/h.264 over Google&rsquo;s Webm video format a Apple adds AirPlay to Mobile Safari http://blog.videojs.com/Apple-adds-AirPlay-to-Mobile-Safari/ 2011-01-28T00:00:00.000Z 2019-01-18T19:57:55.568Z AirPlay is a video feature on iOS devices that lets you play video from your device on your TV, by streaming it to an Apple TV on the same wireless network. Before now this was only available in the iPod and YouTube apps, but with iOS 4.3 (now in beta) it will be available through Mobile Safari as well.

AirPlay Feature in Mobile Safari

In order to allow AirPlay as an option, video publishers have to add an attribute to the HTML5 video tag. <video width=“480” height=“300” controls x-webkit-airplay=“allow”> … We’ll be adding this as a default attribute in the next VideoJS version.

Read the whole story on MacRumors.

]]> <p>AirPlay is a video feature on iOS devices that lets you play video from your device on your TV, by streaming it to an Apple TV on the sam Google is dropping h.264 from Chrome http://blog.videojs.com/Google-is-dropping-h-264-from-Chrome/ 2011-01-11T00:00:00.000Z 2019-01-18T19:57:55.575Z UPDATE: Added a chart that shows what format support will look like without Chrome supporting h.264.

Google Chrome Drops h.264 Support

Google has decided to support the open source community by dropping h.264 support from Chrome. Previously Chrome was the only browser that could play all 3 major HTML5 formats—MP4/h.264, WebM/VP8, and Ogg/Theora. This is probably a strategic move at the same time, since h.264 seems unlikely to be beaten at this point, especially with IE9 supporting h.264 while requiring an extra plugin to use VP8. In my opinion, there’s two major events that could end the format war.

  1. Apple adopts WebM/VP8 (which would require adequate hardware to include in iOS devices)
  2. MPEG LA removes all royalties from h.264

Read the original post.

]]> <p>UPDATE: Added a chart that shows what format support will look like without Chrome supporting h.264.</p> <p><img src="http://videojs.com/ Over 50% of web users now support HTML5 Video http://blog.videojs.com/Over-50-of-web-users-now-support-HTML5-Video/ 2011-01-07T00:00:00.000Z 2019-01-18T19:57:55.576Z As we roll into 2011, HTML5 video hits a major milestone. 50.5% of web users now support HTML5 video playback. This number was gathered by comparing browser versions that support HTML5 video with StatCounter’s world-wide browser version statistics. HTML5 Video StatisticsThis is a 66% growth in HTML5 video user support since December of 2009. With the expected release of Internet Explorer 9 in the near future, 2011 could see a major increase in websites adopting HTML5 video as their primary playback method. Of browsers that support HTML5 video, Mozilla’s Firefox is the clear leader, with Google’s Chrome in second place. Much of the growth in HTML5 video support can be attributed to Chrome’s success in stealing market share from Internet Explore over the last year.

Video Formats

The format war continues to be a deterrent of HTML5 video adoption, and there’s no clear end in sight. While Apple has helped accelerate HTML5 video by requiring it for video playback on the iPhone, it’s also the one vendor that will not support Google’s WebM/VP8 format, which has the highest potential for becoming the standard format for HTML5 video. Among other reasons, Apple has invested a lot of money in the mp4/h.264 format, including hardware built into iPads and iPhones to decode/encode it. Meaning even if Apple decided to support WebM, it would take more than a simple software update to get WebM to the many iPhone and iPad users. Microsoft has said they will support WebM/VP8 in Internet Explorer 9, however only “when the user has installed a VP8 codec”. Which basically means they won’t support it. Microsoft’s preference for MP4/h.264 was made more obvious with their release of a plugin that allows h.264 to be played back in Firefox on Windows. The following graphs show the support and growth of the different video formats. HTML5 Video Format Statistics WebM had a sharp rise in August as Google released Chrome 6 and pushed out updates to its users. In the following charts you can see different views of how formats are divided among HTML5 video users. The first chart shows user support by combinations of formats. The second compares support of open vs. closed formats. HTML5 Video Format Group Statistics From an HTML5 video perspective, open formats win out significantly over closed formats, with Apple and IE9 hanging on to the last 10%. This may change over the next year with the official release of IE9, unless Microsoft decides to support WebM/VP8 without the need for an additional installation. Finally, if you are interested in the Flash vs. HTML5 debate, Flash is well entrenched and HTML5 video still has a long way to catch up. According to Adobe, Flash is supported by over 99% of web users. Statistics from other sites seem to support this, though according to Omniture (now Adobe), the internet average is 116.8% (sic). Omniture Flash Support Statistic As of Flash 9 update 3 (9.0.115), Flash has supported the MP4/h.264 format for video playback. In the following chart, you can see how considering Flash affects the comparison of video format support. Flash vs. HTML5 Video Statistics However, Adobe has said they will support WebM/VP8 in a later release of Flash. The rate that users upgrade to the latest version of Flash is relatively fast, so this could have a big impact on WebM support when it happens. Overall, Flash will be difficult for HTML5 to dethrone. Beyond user support and format discrepancies there is a long list of features that Flash players have supported for years, which will take time for all browsers to build in. However, many of those features can be built with JavaScript, which allows them to be used across browsers immediately. It’s up to the open source community to build the features people need to accept HTML5 as their primary means of video playback. VideoJS is an open source HTML5 video player and framework that makes it easy to support HTML5 video as well as Flash for older browsers. It provides a consistent interface across browsers and solves many browser/mobile device bugs. There are still quite a few rough edges with HTML5 video, but the many contributors to VideoJS are smoothing those over and expanding VideoJS to meet the needs of web users.

]]> <p>As we roll into 2011, HTML5 video hits a major milestone. 50.5% of web users now support HTML5 video playback. This number was gathered b HTML5 Video + Google Maps Mashup http://blog.videojs.com/HTML5-Video-Google-Maps-Mashup/ 2010-12-16T00:00:00.000Z 2019-01-18T19:57:55.575Z Mozilla has a cool demo of playing a video while drawing a line on a Google map similar to what you’d see in an Indiana Jones film. Check out the original post and the demo.

]]> <p>Mozilla has a cool demo of playing a video while drawing a line on a Google map similar to what you&rsquo;d see in an Indiana Jones film. 2.0.2 Release - Subtitle Optimization + Safari on Leopard FS Fix http://blog.videojs.com/2-0-2-Release-Subtitle-Optimization-Safari-on-Leopard-FS-Fix/ 2010-12-10T00:00:00.000Z 2019-01-18T19:57:55.568Z Smallish update with some fixes and optimizations. Rewrote the subtitles parser so it’s a lot more optimized and fixes a subtitle display bug. Put in a check for Safari running on Mac OSX 10.5 (Leopard), which doesn’t like native fullscreen for some reason. Triggering full window mode instead.

Full List

  • Feature: Rewrote and optimized subtitle code.
  • Feature: Protecting against volume ranges outside of 1 and 0.
  • Fix: Bug in Safari for Mac OS 10.5 (Leopard) that was breaking fullscreen.

Download version 2.0.2

]]> <p>Smallish update with some fixes and optimizations. Rewrote the subtitles parser so it&rsquo;s a lot more optimized and fixes a subtitle d 2.0.0 Release - Behaviors, fallback APIs, and more. http://blog.videojs.com/2-0-0-Release-Behaviors-fallback-APIs-and-more/ 2010-11-22T00:00:00.000Z 2019-01-18T19:57:55.568Z Big update. The biggest change for current users is a move back to using DIVs for control bar elements instead of unordered lists. There were a lot of conflicting styles issues when using lists, which shouldn’t be an issue with divs. So if you upgrade, don’t forget to upgrade your stylesheets as well.

Beyond that, a lot of code was reorganized and modularized to create a platform for further expansion, like custom plugins and controls. The concept of “behaviors” was added, so you can activate any element on the page to act like a video controls. For instance, the following code snippet will make the specified element act like a play button, and play the video when clicked.

myplayer.activateElement(myElement, "playButton");

The next code snippet will make the element act like a play progress bar, meaning it will grow horizontally as the video plays.

myplayer.activateElement(myElement, "playProgressBar");

More documentation on this is coming.

The code is now prepped for APIs to the fallback flash players. So if you call myPlayer.play(), it will trigger a play in both the HTML5 and the Flash version, whichever is currently being used. A flowplayer API is just about done, and other popular Flash players will follow.

Finally, you can change the fallback order by modifying the playerFallbackOrder option, which is an array of player platforms. So if you want Flash to be dominant, you would pass the following option.

VideoJS.setupAllWhenReady({
  playerFallbackOrder: ["flash", "html5", "links"]
});

This also leaves room for other platforms to be added, like Quicktime.

So coming up is Flash player APIs, and another cool feature I don’t want to mention just yet.

Full list:

  • Feature: Created “behaviors” concept for adding behaviors to elements - Feature: Switched back to divs for controls, for more portable styles
  • Feature: Created playerFallbackOrder array option. [“html5”, “flash”, “links”]
  • Feature: Created playerType concept, for initializing different platforms
  • Feature: Added play button for Android
  • Feature: Added spinner for iPad (non-fullscreen)
  • Feature: Split into multiple files for easier development
  • Feature: Combined VideoJS & _V_ into the same variable to reduce confusion
  • Fix: Checking for m3u8 files (Apple HTTP Streaming)
  • Fix: Catching error on localStorage full that safari seems to randomly throw
  • Fix: Scrubbing to end doesn’t trigger onEnded

Download version 2.0.0

]]> <p>Big update. The biggest change for current users is a move back to using DIVs for control bar elements instead of unordered lists. There Make sites serve you HTML5 video in Safari http://blog.videojs.com/Make-sites-serve-you-HTML5-video-in-Safari/ 2010-11-19T00:00:00.000Z 2019-01-18T19:57:55.575Z John Gruber of Daring Fireball has a cool post on tricking websites to display HTML5 video when they say they can only play Flash. Many sites will tell you they require Flash, even when they actually support HTML5 video for iOS devices.

To add to Gruber’s post, there’s two reasons a site might do this:

  1. They’re trying to protect their content from being easily downloaded, which HTML5 video can’t do very well yet.
  2. They assume everyone with a browser has Flash, and just serve HTML5 video to iOS devices.

So for this first, this is actually a hack to download content some publishers might not want you to. I probably shouldn’t be publishing this since security of the content is one of the main reasons HTML5 video will still take time to spread. But for that purpose, it’s really not hard to figure out.

For the second, it’s kind of lazy implementation of fallbacks. It’s pretty easy to check if Flash is supported, and if not, fall back to HTML5, instead of checking for a specific user agent string. So for sites using VideoJS, this method wouldn’t work, but there also wouldn’t be a need because VideoJS would fallback appropriately to HTML5.

Gruber has disabled Flash in Safari for better performance with video. That says a lot. Most people probably won’t go to same effort he has, but I know he’s not the only one.

]]> <p>John Gruber of Daring Fireball has a cool post on <a href="http://daringfireball.net/2010/11/masquerading_as_mobile_safari" target="_blan 1.1.5 Release - Subtitles using track, Android fix & more http://blog.videojs.com/1-1-5-Release-Subtitles-using-track-Android-fix-more/ 2010-11-09T00:00:00.000Z 2019-01-18T19:57:55.568Z
  • Feature: Switched to track method for setting subtitles. Now works like spec.
  • Feature: Created “players” concept for defining fallbacks and fallback order
  • Fix: Android playback bug.
  • Fix: Massive reorganization of code to make easier to navigate

    • I’ve switched the subtitles to use the new track element defined in the HTML5 spec. You can now add subtitles by creating a track element pointing to your WebSRTsubtitles source.

    <video ...>
  <track kind="subtitles" src="../demo-subtitles.srt" srclang="en-US" label="English"></track>
</vide>

    The closing track tag is needed, otherwise Safari thinks everything else is a child of the track, even with a self-closing track tag. Not sure why that is, but it’s kind of annoying.

    Also a fix for Android playback was added. Android HTML5 video is pretty rough. The canPlayType function returns nothing on Android so VideoJS has a check to see if the source is mp4/m4v, and assumes it’ll play. Then VideoJS adds a click event to the video so it’ll play when you touch it. Also the Android will show the poster image, but no indication that it’s a video and not just an image. Hopefully this will be improved in the next Android version.

    Beyond that, I did a massive reorganization of the code, so it should be easier to navigate if you’re planning to hack at it or contribute.

    Download version 1.1.5

    ]]>     <ul> <li>Feature: Switched to track method for setting subtitles. Now works like spec.</li> <li>Feature: Created &ldquo;players&rdquo; conce     Version 1.1.4 Release - CSS Loading Spinner & More http://blog.videojs.com/Version-1-1-4-Release-CSS-Loading-Spinner-More/ 2010-11-06T00:00:00.000Z 2019-01-18T19:57:55.576Z The most notable update in this version is a loading indicator (spinner), for when the video is buffering or seeking. The spinner works pretty well, however it’s limited by how accurately each browser tells us what it’s currently doing through triggered events. The spinner works best in Firefox so far. Safari/Chrome are less consistent with what events are triggered and when. For this reason I’m using a more careful approach that makes sure the spinner gets hidden, as opposed to making sure the spinner always shows when the player is busy. There’s a few bugs I had to account for too, like when Safari throws a “waiting” event, but then no other event to let us know it’s not waiting anymore.

    The spinner icon is made with CSS3 effects (border-radius and transform). The spinning animation is created with a little javascript for now. In webkit browsers the animation could have been done with CSS3 animation, but I’d rather keep it consistent between browsers. The technique comes from Kilian Valkhof with initial integration into VideoJS by Janez Troha (dz0ny)

    Other features and fixes include:

    • Feature: Added loading spinner.
    • Feature: Improved styles loaded checking.
    • Feature: Added volume() function to get and set volume through the player. - Fix: Fix issue where FF would loop video in background when ended.
    • Fix: Bug in Chrome that shows poster & plays audio if you set currentTime too quickly.
    • Fix: Bug in Safari where waiting is triggered and shows spinner when not needed
    • Fix: Updated to show links if only unplayable sources and no Flash.
    • Fix: Issue where if play button was loaded after play, it wouldn’t hide.

    Download version 1.1.4

    ]]>     <p>The most notable update in this version is a loading indicator (spinner), for when the video is buffering or seeking. The spinner works p     Version 1.1.3 Release http://blog.videojs.com/Version-1-1-3-Release/ 2010-10-19T00:00:00.000Z 2019-01-18T19:57:55.576Z Version 1.1.3 of VideoJS is now available.

    Probably the most notable change is a switch to using a big play button before the movie plays for the first time, as opposed to showing the control bar. The main reason for doing this is actually a bug in Safari. If you try to call any functions on the video other than play, before the video has loaded, Safari will error out. Some people mentioned that fullscreen mode did not work in Safari for them, and this is most likely what was happening for them. This would only happen if you were not preloading the video. You can still go back to showing the controls first through the showControlsAtStart option, but it’s not recommended.

    Other features and fixes include:

    • Feature: Width/Height functions for resizing the player
    • Feature: Made initial click & hold trigger new value on progress and volume
    • Feature: Made controls not hide when hovering over them
    • Fix: Removed trailing comma that was breaking IE7
    • Fix: Removed some vars from global scope
    • Fix: Changed a document.onmousemove to an eventListener to prevent conflicts
    • Fix: Added a unique ID to FlowPlayer demo object to fix a FlowPlayer bug. Thanks @emirpprime.
    • Fix: Safari error on unloaded video

    Let me know if you have any questions.

    ]]>     <p>Version 1.1.3 of VideoJS is now available.</p> <p>Probably the most notable change is a switch to using a big play button before the movi     Facebook Adds HTML5 Video http://blog.videojs.com/Facebook-Adds-HTML5-Video/ 2010-10-12T00:00:00.000Z 2019-01-18T19:57:55.569Z What

    Among other new HTML5 features, Facebook has an HTML5 video player for playback on the iPhone and iPad. They say that on other mobile browsers, Flash outperformed the HTML5 implementation. That’s a little discouraging to hear, but HTML5 video is still young.

    Read the full post

    In contrast, check out this video of HTML5 vs. Flash on a Mac. Spoiler: HTML5 wins.

    ]]>     <p><a href="http://www.flickr.com/photos/24374884@N08/4603715307/" title="What" target="_blank" rel="external"><img src="http://farm2.static     iPad & iPhone Video Poster Fix (bonus Javascript Placement Fix) http://blog.videojs.com/iPad-iPhone-Video-Poster-Fix-bonus-Javascript-Placement-Fix/ 2010-09-20T00:00:00.000Z 2019-01-18T19:57:55.606Z Bug #1 - Poster Attribute

    If you include the poster attribute on the video tag when you’re using <source> tags, the video won’t work on iPads & iPhones using iOS 3. You’ll see a broken play button, or no play button at all. On the iPad specifically, playback in inconsistent. Sometimes it’ll work and sometimes it won’t. This is documented on the Video for Everybody site.

    Bug #2 - Javascript in the Head

    This is a fun one… If you include Javascript in the head of your page, it’ll break playback on the iPad (also inconsistent). If you move the Javascript to the bottom of the page, and still include a stylesheet, the iPad will work, but the iPhone 3 won’t. I first read about this in a post on the No.inc blog, and then ran into it myself when redesigning the VideoJS site. Their original solution was to put the JS at the bottom of the page for iPads only (fun).

    Apple’s iOS4 seems to fix both of these problems on the iPhone, but until iOS4 is available on the iPad, and everyone in the world upgrades their devices, we have to deal with this.

    Fix for iOS 3

    The problem seems to be some kind of race condition, that trips up the devices. The solution that has fixed both of these for me is to add the playable source directly to the video tag, and tell the video to load (all through Javascript).

    I’ve added all this to VideoJS 1.1.2, but here’s the basics of how it works.

    var video = document.getElementById("your_video");
    var children = video.children;
    for (var i=0,j=children.length; i<j; i++) {
      if (children[i].tagName.toUpperCase() == "SOURCE") {
        var canPlay = video.canPlayType(children[i].type);
        if(canPlay == "probably" || canPlay == "maybe") {
          video.src = children[i].src;
          video.load();
          break; // or return or whatever
        }
      }
    }

    So loop through the source elements, find the one that’s compatible, and add that source to the video src. Then trigger the video’s load() function.

    That seems to fix both issues. This will not make the poster show up in either device.It just makes makes the video playable. Sometimes you’ll see it flash the controls and then go back to the big play button.

    Any feedback is appreciated.

    Let’s go Apple, get iOS4 out to everybody!

    ]]>     <h3 id="Bug-1-Poster-Attribute"><a href="/iPad-iPhone-Video-Poster-Fix-bonus-Javascript-Placement-Fix/#Bug-1-Poster-Attribute" class="header     VideoJS is IE9 Compatible http://blog.videojs.com/VideoJS-is-IE9-Compatible/ 2010-09-15T00:00:00.000Z 2019-01-18T19:57:55.606Z After an initial test, VideoJS works with the new Internet Explorer 9 preview. Great news, and a little surprising considering the CSS layout of the controls, and the general nature of IE. Other VideoJS site layout stuff seems to break, but for now as long as the player works I’m happy.

    If you find differently let me know (along with any info that might be helpful).

    ]]>     <p>After an initial test, VideoJS works with the new <a href="http://ie.microsoft.com/testdrive/" target="_blank" rel="external">Internet Ex     New VideoJS Site (Now with more HTML5)! http://blog.videojs.com/New-VideoJS-Site-Now-with-more-HTML5/ 2010-09-15T00:00:00.000Z 2019-01-18T19:57:55.576Z I told myself when the site reached 100,000 visits I would redesign it. Well that number’s come and gone, so here it is.

    I also took this as an opportunity to code an HTML5 based site, using tags like header, footer, and section. And I built it on the newly popular HTML5 Boilerplate. Actually I built a WordPress them for HTML5 Boilerplatefirst, in case you’re interested in doing the same.

    I got to use some fun CSS tricks throughout as well. One of them is the thin color bar at the top of the page. Resize the window and watch it go!

    I also added this blog and a twitter account, where I’ll be posting updates to VideoJS, as well as general HTML5 video news.

    ]]>     <p>I told myself when the site reached 100,000 visits I would redesign it. Well that number&rsquo;s come and gone, so <a href="http://videoj