Will Law | Chief Media Architect | Akamai Optimizing the Black Box of HTML

The video tag seems like the simple solution to our online video problems

Let’s take a typical site

and dress it up by adding some video tations/velocitynyc13/preloadnone/oreilly -preload-none.html

Problem #1: Embedding a video object on page load nearly always causes additional download penalty.  Add a poster image to the page, in the same size and location as the video  When the user clicks it, hide the poster and dynamically add a video element in its place, with autoplay enabled  If we perform this in the same function that handles the image click then we can autostart the video under iOS and Android.  Solution: defer instantiation of the object until we need it How:

Problem #2: progressive videos continue downloading when you pause. Solution: remove the video object source on pause. How:  Instantiate the element when the user wants the video  When they click pause, store the playhead position, set the src to “”, remove the element.  Add the element back to the page with the correct src  When they hit play, issue a seek() to the stored position. 

The myth of SBR  Any single bitrate you choose for a video is by definition the wrong video for 99% of users. These users will rebuffer These have lower quality than they could sustain

Problem #3: a single bitrate is not optimal for all users. Solution: let’s select an appropriate bitrate before we start delivering the video. How:  When the users loads the page, estimate their throughput by timing the download of a small binary object  Select the appropriate source streams based on this bitrate estimate bitrate and then dynamically add that source to the video object. 

Problem #4: this timed download is wasteful if the user never watches the video. Solution: defer the bandwidth estimate until the user actually selects the video to watch.. How:  When the user selects the video, estimate their throughput by timing the download of a small binary object  Immediately select the appropriate source streams based on this bitrate estimate bitrate and then dynamically add that source to the video object and start playback 

Bandwidth is never constant  Even preselecting bitrates will lead to rebuffering problems as bandwidth fluctuates over the duration of the vide, especially for long form content  Ideally we would like to switch bitrates constantly to always give the user the highest quality they can sustain at any point in time. Buffering

Bandwidth is never constant  Even preselecting bitrates will lead to rebuffering problems as bandwidth fluctuates over the duration of the vide, especially for long form content  Ideally we would like to switch bitrates constantly to always give the user the highest quality they can sustain at any point in time. Buffering 500kbps 1000kbps 1500kbps Adaptive delivery

Adaptive media delivery is the notion of constantly changing the bitrate (quality) of the video being delivered to suit the throughput at that point in time.  It’s typically controlled by the client == smart(er) clients  The stream is delivered in segments in enable switching

How does segmentation work? Incoming video 1 3 into multiple short blocks. Each block holds the same section of video, encoded at a different size and bitrate. 500 kbps 2000 kbps 1000 kbps is split by an encoder 2

How does adaptive delivery work? The segmented video is stored on a server, along with a text file which describes the names of each segment. This text file is called a manifest. A player downloads the manifest and then begins requesting individual segments of video. It makes its choice based on bandwidth conditions, grabbing the best quality it can at the time. SERVERCLOUDPLAYER

Which adaptive streaming formats exist today?  HTTP Live Streaming (HDS) -Controlled by Apple -Known as HLS, it is supported well by iOS, Safari and half-heartedly by Android.  HTTP Dynamic Streaming (HDS) -Controlled by Adobe -Known as HDS, it is played back only by Flash clients with custom apps.  Smooth Streaming (SMOOTH) -Controlled by Microsoft -Played back via Silverlight clients, Xbox,  MPEG-DASH (DASH) -An ISO standard -Playback via MSE in browsers, native apps on iOS, Android and WInOS.

Simple HLS example

Media Source Extension – the future of browser video  A W3C standard - source.htmlhttps://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media- source.html  Supported today by Chrome, IE11 and Opera  MSE allows JavaScript to -fetch and parse a manifest -retrieve video, audio and text segments using XHR -feed them to the tag to be decoded and rendered. MSE gives developers incredible control over playback, buffering and adaption logic of in-page video.

dash.js  An open-source project on Github:  Provides a library for playback of DASH adaptive content using MSE.  Let’s put it all together and make an implementation which -Uses MBR DASH under Chrome/IE11 -Uses MBR HLS under iOS -Uses progressive media with bitrate selection outside of those environments. -Let’s do all this with a 9KB initial page load. -

Take these thoughts home …  Due to its size, video can have a disproportionate effect on page performance and load times.  Try to defer instantiation of video components until the user actually wants to watch  If using progressive video delivery, use some sort of speedtest to pick the best quality stream your user can enjoy at that moment.  Adaptive delivery gives a better user experience, especially for long form content.  MediaSource extensions in HTML5 are the precursors of the browser becoming the dominant video player application environment among devices. Become familiar with them and enjoy the ride.  All code samples available at Questions?