Author Archive: Kevin Streeter

About Kevin Streeter

Kevin Streeter is the Principal Scientist and Chief Architect of Adobe Primetime. In this role, Kevin is responsible for the overall product architecture as well as strategy on standards and open source technologies. He works in standards organizations including MPEG, W3C, and OATC. Kevin holds an MBA from the University of San Francisco School of Management and a BS in Computer Science from the University of California at San Diego.

HTTP/2 Provides a Path to Delay-Free Live Streaming

Live streaming without a delay

One challenge facing media companies today is that live streaming isn’t actually live. It’s delayed by a few seconds or more. This is especially problematic when live broadcast viewers engage on social media with online viewers who are seconds behind in their viewing because the broadcast viewers can spoil the show for the online viewers.

In recent news, Twitter’s first NFL Thursday Night Football live stream ran on a 30-second delay. CNN reported that it was met with largely rave reviews. But the negative reviews were all about the delay. For example, here’s what Oriana Schwindt, TV News Editor at Variety, had to say about the stream:

One future solution to this challenge will be to leverage HTTP/2 in order to make live streaming work without a delay. In a technical presentation at IBC last month, I covered how to achieve this with a system for live streaming that compares well with broadcast.

Here’s the emerging best practices from that talk:

  • Minimize Video Segment Size — The size, in seconds, of a video segment dictates the minimum live delay in a system because it represents the amount of time that an encoder/packager needs to accumulate the segment. Live delay can be reduced by making the segment as small as possible, although the mechanics of congestion control over TCP puts a floor on how small we can make the segments and still keep the TCP channel full. A segment size of 2 seconds to 4 seconds provides a good balance of low delay and efficient use of the channel.
  • Use HTTP/2 Server Push — One downside of making segments really small is that the total number of network transactions goes up by an equivalent amount. HTTP/2’s server push counteracts this by pushing multiple segments in a single network transaction. It also allows for smaller segments than what would otherwise be possible due to the TCP slow start/congestion control issues mentioned above, by effectively creating large “virtual” segments.
  • Optimize Your Video Client for Low Latency — HTTP/2 helps the network deliver content with low delay, but you need a video player that operates with low delay as well. The player needs to carefully manage its playback buffer, and take action (skip frames, etc.) if it is falling behind. We are currently working to ensure that the Adobe Primetime TVSDK has a really low live delay.

These best practices will become relevant when both your content delivery network (CDN) and your video client endpoints support HTTP/2. So, ask your CDN about HTTP/2. And, for more details about the best practices listed above, download this zip file containing all the white papers from the IBC session, “Advanced Developments in Dynamic Video Streaming.” Then, read the paper in that batch titled, “Improving Live Performance in HTTP Adaptive Streaming Systems.

Adobe Primetime Support for MPEG-DASH

For those of us working to develop MPEG-DASH, Apple’s recent support of the W3C’s Media Source Extensions (MSE) API in Safari on OS X Yosemite is great news.  MSE and DASH have a complementary relationship, and expanded support for MSE will make it much easier for publishers to adopt DASH.

While MSE itself is designed to be media container format neutral, one of the primary container format recommendations made in the specification is compatible with the ISO Base Media File Format (ISO BMFF) “fragmented MP4” profile of MPEG-DASH.  At this time, MSE implementations in most desktop browsers (Chrome, IE, Safari) are available and support the ISO BMFF container.  Firefox is also working on compatible implementations, which are already partially available in their development branches.

The widespread support for the ISO BMFF container is mainly driven by the influence of Netflix’s content library, which is built around an ISO BMFF container. Although browser vendors may or may not feel that ISO BMFF MPEG-DASH is the best way to deliver content, the requirement to support DASH in order to receive content from a major content provider will ensure continued support for this container.

Creating a broad footprint of available clients is one of the main things slowing down adoption of DASH.  We here at Adobe announced our support for DASH in our Adobe Primetime video stack and demonstrated it at this year’s NAB Show.  Primetime will support DASH using an ISO BMFF container, and it will work everywhere our video engine runs, including Flash in the browser, Android, Roku, RDK-based set-top boxes, and many other platforms.  Primetime’s DASH implementation will also include complete support for all of the capabilities that we offer in HLS today, including DRM and ad insertion, making it even easier for publishers to adopt DASH.

dash

Click to enlarge

Between increasing support for DASH using MSE in desktop browsers, and support for DASH on many other platforms using Primetime, we are nearing a point where it is easy to deploy video players to consume DASH content.  With the availability of client endpoints, it will make more sense for publishers to adopt DASH for their delivery workflows.  This won’t happen overnight, but clearing this significant hurdle positions the digital video ecosystem to truly embrace MPEG-DASH.