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