The Broadcast Knowledge

Video: Live Closed Captioning and Subtitling in SMPTE 2110 (update)

Posted on 25th February 2020 by Adam K

The SMPTE ST 2110-40 standard specifies the real-time, RTP transport of SMPTE ST 291-1 Ancillary Data packets. It allows creation of IP essence flows carrying the VANC data familiar to us from SDI (like AFD, closed captions or ad triggering), complementing the existing video and audio portions of the SMPTE ST 2110 suite.

This presentation, by Bill McLaughlin from EEG, is an updated tutorial on subtitling, closed captioning, and other ancillary data workflows using the ST 2110-40 standard. Topics include synchronization, merging of data from different sources and standards conversion.

Building on Bill’s previous presentation at the IP Showcase), this talk at NAB 2019 demonstrates a big increase in the number of vendors supporting ST 2110-40 standard. Previously a generic packet analyser like Wireshark with dissector was recommended for troubleshooting IP ancillary data. But now most leading multiviewer / analyser products can display captioning, subtitling and timecode from 2110-40 streams. At the recent “JT-NM Tested Program” event 29 products passed 2110-40 Reception Validation. Moreover, 27 products passed 2110-40 Transmitter Validation which mean that their output can be reconstructed into SDI video signals with appropriate timing and then decoded correctly.

Bill points out that ST 2110-40 is not really a new standard at this point, it only defines how to carry ancillary data from the traditional payloads over IP. Special care needs to be taken when different VANC data packets are concatenated in the IP domain. A lot of existing devices are simple ST 2110-40 receivers which would require a kind of VANC funnel to create a combined stream of all the relevant ancillary data, making sure that line numbers and packet types don’t conflict, especially when signals need to be converted back to SDI.

There is a new ST 2110-41 standard being developed for additional ancilary data which do not match up with ancillary data standardised in ST 291-1. Another idea discussed is to move away from SDI VANC data format and use a TTML track (Timed Text Markup Language – textual information associated with timing information) to carry ancillary information.

Watch now!

Download the slides.

Speakers

Bill McLaughlin
VP of Product Development
EEG

Video: AV1 at Netflix

Posted on 24th February 2020 by Russell Trafford-Jones

Netflix have continually been pushing forward video compression and analysis because their assets are played so many times that every bit saved is real money saved. VMAF is a great example of Netflix’s desire to push the state of the art forward. Developed by Netflix and two universities, this new objective metric allowed them to better evaluate the quality of videos using computer analysis and has continued to be the foundation of their work since.

One use of VMAF has been to verify the results of Netflix’s Per-Shot Encoding method which alters encoding parameters for each shot of the film rather than using a fixed set of parameters for the whole film. The Broadcast Knowledge has featured talks on their previous technique, per-title encoding (among others).

AV1, however must be the most famous innovation that Neflix is behind. A founding member of the Alliance for Open Media (AoM), Netflix saw a need a for a better codec and by making an open one, which also played to the needs of other internet giants such as Google, was a good way to create a vibrant community around it driving submissions to the codec itself but also, it is hoped, in the implementation and adoption.

In this two-part talk, LiWei Guo starts off by explaining the ways in which AV1 will be used by Netflix. Since this talk took place, Netflix has started streaming in AV1 to Android clients. LiWei points out that AV1 supports 10-bit video as standard – a notable difference from other codecs like AVC and HEVC. This allows Netflix to use 10-bit without worrying about decoder compatibility and he shows examples of skies and water which are significantly by the use of 10-bit.

Another feature of AV1 is the Film Grain synthesis which seeks to improve encoding efficiency by removing the random film grain of the source during the encode process then inserting a similar random noise on top to recreate the same look and feel. As anything random can’t be predicted, noise such of this is very wasteful for a codec to try and encode, therefore it’s not <a surprise that this can result in as much as a 30% reduction in bitrate. Before concluding, LiWei briefly explains per-shot encoding then shows data showing the overall improvements.

Andrey Norkin, also from Netflix explains their work with Intel on the SVT-AV1 software video encoder which leverages Intel’s SVT technology, a framework optimised for Xeon chips for video encoding and analysis. Netflix’s motivations are to further increase adoption by delivering a data centre-ready, optimised encoder and to create an AV1 encoder they can use to support their own internal research activities (did someone say AV2?). SVT allows for parallelisation, important for any computer nowadays with so many cores available.

Finishing up, Andrey points us to the Github repository, lets us know the development statement (as of November 2019) and looks at the speed increases that have taken off, comparing SVT-AV1 against the reference libaom encoder.

Watch now!
Speakers

	Andrey Norkin Senior Research Scientist, Netflix
	LiWei Guo Senior Software Engineer, Netflix

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

Posted on 21st February 2020 by Russell Trafford-Jones

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
Chief Software Architect,
VizRT

Video: Integrating CMAF Into A VOD Workflow

Posted on 20th February 2020 by Russell Trafford-Jones

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.

Watch now!
See Streamflow’s blog post supporting the talk
Speakers