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

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:

Twitter stream looking pretty good, but as usual, about 30 seconds behind broadcast

— Oriana Schwindt (@Schwindter) September 16, 2016

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.