1. Video.js version 4.5.0 released! Nothing to see here, move along

    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

  2. Video.js version 4.4.0 released - Now supporting RequireJS and Browserify

    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

  3. Video.js version 4.3.0 released w/ shiny new API docs

    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

  4. The Guardian uses Video.js in feature article

    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

  5. 4.2.2 Patch Release

    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

  6. Running Video.js unit tests in real browsers with Karma

    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

  7. Unauthorized modification of Video.js CDN files

    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.

  8. Video.js 4.2.0 released! RTMP, CSS designer, and stability

    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 -->
      connection: http://myurl.com/streaming
      stream: /is/fun
    
    -or-
    
    http://myurl.com/streaming/is/fun -->
      connection: 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

  9. Hiding and Showing Video Player Controls

    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

  10. New Player Skin Designer for Video.js

    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