HTTP/2 is an evolution of what most people know as HTTP with the aim of increasing the speed of websites by streamlining the request and delivery of resources. Apple have mandated the use of HTTP/2 for their LL-HLS protocol. Within a typical web page there can easily be 100 requests to the web server so it’s easy to see how increased efficiency could be a benefit. For low latency streaming such as LL-HLS, there are many requests each second so again, even small gains in efficiency can add up.
Rolf W Rasmussen from VizRT explains in this talk the benefits of HTTP/2 taking us through the differences from HTTP. He starts simply by looking at HTTP/1.1 with the messages sent between the client and the server and shows how the requests and responses are sent. Rolf then looks at how the messages are sent at each of the layers of the OSI model. By doing this we discover that the messages are sent in binary.
Binary sending and header compression are ways in which the data to be sent is minimised. We see though that the HTTP/2 is a connection which multiplexes different streams on the same connection. Maintaining the same connection for multiple data streams again reduces the amount of negotiation needed. Multiplexing helps increase the efficient use of that connection. Unlike before, we now see that small requests are cheap whereas there has traditionally been a lot of work to reduce the number of small requests in HTTP/1.1.
Server Push is another key improvement where the server itself can push data into the open connection without a corresponding request. This was originally a requirement of the LL-HLS protocol but has been made optional since. For web pages, there are times when if a page needs resource A, the server knows that it will require resource B later. It’s in these situations that server push is used. Clearly for online streaming, it’s known when the client will need certain chunks or playlist files hence the potential use of server push.
Rolf concludes with questions from the flow and looking at some practical examples of debugging with curl, using proxies and Wireshark as well as dealing with encryption.
CMAF is often seen as the best hope for streaming to match the latency of broadcast. Fully standards based, many see this as the best route over Apple’s LL-HLS. Another benefit of it over LL-HLS is that it’s already a completed standard with growing support.
This talk from Tomas Bacik starts by explaining CMAF to us. Standing for the Common Media Application Format, it’s based on the standardised ISOBMFF container format and whilst CMAF isn’t by default low-latency, it is flexible enough to deliver just that. However, as Tomas from CDN77 points out, there are other major benefits in terms of its use of the Common Encryption format, reduces storage fees and more.
MPEG DASH is a commonly found streaming format based on ISO BMFF. It has always had the benefit of supporting other codecs such as HEVC and AV1 over HLS which is an AVC-only specification. CMAF is an extension of MPEG DASH which goes one step further in that it can deal with both HLS-style manifest files (.hls) as well as MPEG DASH format (.mpd) inheriting, of course, the multi-codec ability of DASH itself.
Next is central theme of the talk, looking at VoD workflows showing how CMAF fits in and, indeed, changes workflows for the better. CMAF directly impacts packaging, storage and CDN which is where we focus now. Given that some devices can play HLS and some can play DASH, if you try to serve both, you will double your requirements of packaging, storage etc. Dynamic packaging allows for immediately repackaging your chunks into either HLS or DASH as needed. Whilst this reduces the storage requirements, it increases processing and also increases the time to first byte. As you might expect, using CMAF throughout, Tomas explains in this talk, allows you to package once and store once which solves these problems.
Tomas continues by explaining the DRM abilities of CMAF including AES-CBC and finishes by taking questions from the audience.
Recycling may be good for the environment, but it turns out it’s good for bit rate too. Remembering that MPEG (and similar) video compression includes splitting the picture into blocks, decomposing them into basic patterns and also estimating their motion, this talk wonders whether calculations made on the blocks and the motion of these blocks done on the SD picture can be re-used on the HD picture and then again on the UHD picture. If so, this would surely reduce the computation needed.
“The content is perceptually identical,” explains Alex Giladi from Comcast, “…the only difference is how many pixels it occupies.” as he highlights the apparent wastefulness of ABR encoding where the same video is taken in multiple resolutions and encoded independently. The technique starts by analysing the lowest resolution video for motion and re-using the calculations at a higher resolution. Naturally there are aspects which can’t be captured in the lower resolutions, but also there are sensitivities to the bitrate so Alex explains the refinement options which have been developed to adapt to those.
As the talk wraps up, Alex presents the results found which show that the quality is not degraded and there is a better than 2x speed increase. Finally we look at a real-life flow of encoding.
HbbTV is a transmission standard seeking to unify over-the-air transmissions and broadband-delivered services into a seamless service. This aim is the same as ATSC 3.0 though the means of achieving it are not the same. HbbTV has seen growing use since its debut in 2006 and is now on its 2nd iteration.
James starts by looking at the boxes available and, importantly, the SDKs behind them which are many and varied. We’re then taken through some of the XML necessary to get an HbbTV app up and running including some key “dos and don’ts”. Now that we’ve seen how to invoke a program, James takes us on an amusing journey into getting a loading spinner to work and the many attempts, all highly reasonable, to convince this to be rendered.
For a video service, playing videos is probably the most important function so next we look at the surprising number of ways one can fail to get video to play using quite rational parameters in MPEG DASH seeing the ways to make it work and the ones to avoid. Finally we see the variety of responses that boxes report back their failure to render video.
A cautionary tale, or a guide to survive? You decide. Watch now!