Video: HTTP/2 – Abstraction, protocol design, and practical use

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.

Watch now!
Speakers

Rolf W. Ramussen Rolf W. Ramussen
Chief Software Architect,
VizRT

Video: Introducing Low-Latency HLS

HLS has taken the world by storm since its first release 10 years ago. Capitalising on the already widely understood and deployed technologise already underpinning websites at the time, it brought with it great scalability and the ability to seamlessly move between different bitrate streams to help deal with varying network performance (and computer performance!)

HLS has continued to evolve over the years with the new versions being documented as RFC drafts under the IETF. It’s biggest problem for today’s market is its latency. As originally specified, you were guaranteed at least 30 seconds latency and many viewers would see a minute. This has improved over the years, but only so far.

Low-Latency HLS (LL-HLS) is Apple’s answer to the latency problem. A way of bringing down latency to be comparable with broadcast television for those live broadcast where immediacy really matters.

This talk from Apple’s HLS Technical Lead, Roger Pantos, given at Apple’s WWDC conference this year goes through the problems and the solution, clearly describing LL-HLS. Over the following weeks here on The Broadcast Knowledge we will follow up with some more talks discussing real-world implementations of LL-HLS, but to understand them, we really need to understand the fundamental proposition.

Apple has always been the gatekeeper to HLS and this is one reason the MPEG DASH exists; a streaming standard that is separate to any one corporation and has the benefits of being passed by a standards body (MPEG). So who better to give the initial introduction.

HLS is a chunk-based streaming protocol meaning that the illusion of a perfect stream of data is given by downloading in quick succession many different files and it’s the need to have a pipeline of these files which causes much of the delay, both in creating them and in stacking them up for playback. LL-HLS uses techniques such as reducing chunk length and moving only parts of them in order to drastically reduce this intrinsic latency.

Another requirement of LL-HLS is HTTP/2 which is an advance on HTTP bringing with it benefits such as having multiple requests over a single HTTP connect thereby reducing overheads and request pipelining.

Roger carefully paints the whole picture and shows how this is intended to work. So while the industry is still in the midst of implementing this protocol, take some time to understand it from the source – from Apple.

Watch now!
Download the presentation

Speaker

Roger Pantos Roger Pantos
HLS Technical Lead,
Apple

Video: What’s the Deal with LL-HLS?

Low latency streaming was moving forward without Apple’s help – but they’ve published their specification now, so what does that mean for the community efforts that were already under way and, in some places, in use?

Apple is responsible for HLS, the most prevalent protocol for streaming video online today. In itself it’s a great success story as HLS was ideal for its time. It relied on HTTP which was a tried and trusted technology of the day, but the fact it was file-based instead of a stream pushed from the origin was a key factor in its wide adoption.

As life has moved on and demands have moved from “I’d love to see some video – any video – on the internet!” to “Why is my HD stream arriving after my flat mate’s TV’s?” we see that HLS isn’t quite up to the task of low-latency delivery. Using pure HLS as originally specified, a latency of less than 20 seconds was an achievement.

Various methods were, therefore, employed to improve HLS. These ideas included cutting the duration of each piece of the video, introducing HTTP 1.1’s Chunked Transfer Encoding, early announcement of chunks and many others. Using these, and other, techniques, Low Latency HLS (LHLS) was able to deliver streams of 9 down to 4 seconds.

Come WWDC this year, Apple announced their specification on achieving low latency streaming which the community is calling ALHLS (Apple Low-latency HLS). There are notable differences in Apple’s approach to that already adopted by the community at large. Given the estimated 1.4 billion active iOS devices and the fact that Apple will use adherence to this specification to certify apps as ‘low latency’, this is something that the community can’t ignore.

Zac Shenker from Comcast explains some of this backstory and helps us unravel what this means for us all. Zac first explains the what LHS is and then goes in to detail on Apple’s version which includes interesting, mandatory, elements like using HTTP/2. Using HTTP/2 and the newer QUIC (which will become effectively HTTP/3) is very tempting for streaming applications but it requires work both on the server and the player side. Recent tests using QUIC have been, when taken as a whole, inconclusive in terms of working out whether this it has a positive or a negative impact on streaming performance; experiemnts have shown both results.

The talk is a detailed look at the large array of requirements in this specification. The conclusion is a general surprise at the amount of ‘moving parts’ given there is both significant work to be done on the server as well as the player. The server will have to remember state and due to the use of HTTP/2, it’s not clear that the very small playlist.m3u8 files can be served from a playlist-optimised CDN separately from the video as is often the case today.

There’s a whole heap of difference between serving a flood of large files and delivering a small, though continually updated, file to thousands of end points. As such, CDNs currently optimised separately for the text playlists and the media files they serve. They may even be delivered by totally separate infrastructures.

Zac explains why this changes with LL-HLS both in terms of separation but also in the frequency of updating the playlist files. He goes on to explore the other open questions like how easy it will be to integrate Server-Side Add Insertion (SSAI) and even the appetite for adoption of HTTP/2.

Watch now!
Speaker

Zac Shenker Zac Shenker
Director of Engineering, Video Experience & Optimization,
CBS Interactive

Video: QUIC in Theory and Practice


Most online video streaming uses HTTP to deliver the video to the player in the same way web pages are delivered to the browser. So QUIC – a replacement for HTTP – will affect us professionally and personally.

This video explains how HTTP works and takes us on the journey to seeing why QUIC (which should eventually be called HTTP/3) speeds up the process of requesting and delivering files. Simply put there are ways to reduce the number of times messages have to be passed between the player and the server which reduces overall overhead. But one big win is its move away from TCP to UDP.

Robin Marx delivers these explanations by reference to superheroes and has very clear diagrams leading to this low-level topic being pleasantly accessible and interesting.

There are plenty of examples which show easy-to-see gains website speed using QUIC over both HTTP and HTTP/2 but QUIC’s worth in the realm of live streaming is not yet clear. There are studies showing it makes streaming worse, but also ones showing it helps. Video players have a lot of logic in them and are the result of much analysis, so it wouldn’t surprise me at all to see the state of the art move forward, for players to optimise for QUIC delivery and then all tests to show an improvement with QUIC streaming.

QUIC is coming, one way or another, so find out more.
Watch now!

Speaker

Robin Marx Robin Marx
Web Performance Researcher,
Hasslet University