Video: Virtues of Recycling in Multi-rate Encoding

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.

Watch now!
Speakers

Alex Giladi Alex Giladi
Distinguished Architect,
Comcast

Video: Reasons to cry –  living room device app development

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 Williams has spent a lot of time getting services working on HbbTV-compliant hardware. STB manufacturers always have to balance very carefully the cost of the box against the components and hence performance. This leads to some unfortunate compromises when it comes to ‘secondary features’ such as rendering HTML, CSS or Javascript even if they are required in order to validate a box against a standard. This talk is a synthesis of what’s he’s learnt, fought against and endured making, sometimes very simple, things work.

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!

Speaker

James Williams James Williams
Solutions Engineer,
Mux

Video: The Basics of SMPTE ST 2110 in 60 Minutes

SMPTE ST 2110 is a growing suite of standards detailing uncompressed media transport over networks. Now at 8 documents, it’s far more than just ‘video over IP’. This talk looks at the new ways that video can be transported, dealing with PTP timing, creating ‘SDPs’ and is a thorough look at all the documents.

Building on this talk from Ed Calverley which explains how we can use networks to carry uncompressed video, Wes Simpson goes through all the parts of the ST 2110 suite explaining how they work and interoperate as part of the IP Showcase at NAB 2019.

Wes starts by highlighting the new parts of 2110, namely the overview document which gives a high level overview of all the standard docs, the addition of compressed bit-rate video carriage and the recommended practice document for splitting a single video and sending it over multiple links; both of which are detailed later in the talk.

SMPTE ST 2110 is fundamentally different, as highlighted next, in that it splits up all the separate parts of the signal (i.e. video, audio and metadata) so they can be transferred and processed separately. This is a great advantage in terms of reading metadata without having to ingest large amounts of video meaning that the networking and processing requirements are much lighter than they would otherwise be. However, when essences are separated, putting them back together without any synchronisation issues is tricky.

ST 2110-10 deals with timing and knowing which packets of one essence are associated with packets of another essence at any particular point in time. It does this with PTP, which is detailed in IEEE 1588 and also in SMPTE ST 2059-2. Two standards are needed to make this work because the IEEE defined how to derive and carry timing over the network, SMPTE then detailed how to match the PTP times to phases of media. Wes highlights that care needs to be used when using PTP and AES67 as the audio standard requires specific timing parameters.

The next section moves into the video portion of 2110 dealing with video encapsulation on the networks pixel grouping and the headers needed for the packets. Wes then spends some time walking us through calculating the bitrate of a stream. Whilst for most people using a look-up table of standard formats would suffice, understanding how to calculate the throughput helps develop a very good understanding of the way 2110 is carried on the wire as you have to take note not only of the video itself (4:2:2 10 bit, for instance) but also the pixel groupings, UDP, RTP and IP headers.

Timing of packets on the wire isn’t anything new as it is also important for compressed applications, but it is of similar importance to ensure that packets are sent properly paced on wire. This is to say that if you need to send 10 packets, you send them one at a time with equal time between them, not all at once right next to each other. Such ‘micro bursting’ can cause problems not only for the receiver which then needs to use more buffers, but also when mixed with other streams on the network it can affect the efficiency of the routers and switches leading to jitter and possibly dropped packets. 2110-21 sets standards to govern the timing of network pacing for all of the 2110 suite.

Referring back to his warning earlier regarding timing and AES67, Wes now goes into detail on the 2110-30 standard which describes the use of audio for these uncompressed workflows. He explains how the sample rates and packet times relate to the ability to carry multiple audios with some configurations allowing 64 audios in one stream rather than the typical 8.

‘Essences’, rather than media, is a word often heard when talking about 2110. This is an acknowledgement that metadata is just as important as the media described in 2110. It’s sent separately as described by 2110-40. Wes explains the way captions/subtitles, ad triggers, timecode and more can be encapsulated in the stream as ancillary ‘ANC’ packets.

2110-22 is an exciting new addition as this enables the use of compressed video such as VC-2 and JPEG-XS which are ultra low latency codecs allowing the video stream to be reduced by half, a quarter or more. As described in this talk the ability to create workflows on a single IP infrastructure seamlessly moving into and out of compressed video is allowing remote production across countries allowing for equipment to be centralised with people and control surfaces elsewhere.

Noted as ‘forthcoming’ by Wes, but having since been published, is RP 2110-23 which adds back in a feature that was lost when migrating from 2022-6 into 2110 – the ability to send a UHD feed as 4x HD feeds. This can be useful to allow for UHD to be used as a production format but for multiviewers to only need to work in HD mode for monitoring. Wes explains the different modes available. The talk finishes by looking at RTP timestamps and SDPs.

Watch now!
The slides for this talk are available here
Speakers

Wes Simpson Wes Simpson
President,
Telecom Product Consulting

Video: RIST Pre-Shared Key Encryption

An important factor when sending production video feeds and other media over the internet for most people is encryption. When distributing to the end user, it’s different, but for contribution having the assurance that no-one else can view the video is very reassuring to all parties even when the content doesn’t necessitate it. RIST has been in development for a while and has grown beyond the simple profile which only dealt with packet loss. Now with the main profile, encryption is possible; there are actually two ways to encrypt. One uses DTLS which is the UDP-based equivalent of the same TLS encryption that https:// websites use, the other uses pre-shared keys (PSK).

Sergio Ammirata from DVEO starts the talk by introducing the main profile and the use of GRE tunnels. The use of a tunnel from sender to receiver allows for a single connection to carry multiple channels of multiplexed data. Importantly. it also allows the encryption to happen to the tunnel rather than to each media stream separately.

The next section of the talk revises what DTLS is: part of the main profile providing TLS encryption to UDP. Given this is an encryption method, it’s important to realise it is not part of the data-loss recovery algorithms. Since DTLS is based on TLS, it will also need certificates. Just like websites you have the choice of having a self-signed certificate or one signed by a trusted authority. This means that you not only know that you are sending encrypted data, you are also sending it to a trusted computer, not someone unintended. Sergio takes us through the workflow of verifying the certificates highlighting, for instance, the requirement for a realtime clock otherwise the start and expiry dates in the certificates wouldn’t have any meaning.

With PSK, there is no authentication. It encrypts the whole of the GRE tunnel except for headers with an AES key related to the pre-shared passphrase. The encryption is changed periodically by an automatic process. It’s important to realise that because this is so deterministic, this can be used for bonded connections. When Sergio then looks at the data flow for using PSK, we see that that it is much simpler with many fewer handshakes.

As to when PSK is the route to take over using DTLS, one-to-many transmission is an obvious candidate but also where there is only one-way communication such as most satellite links. Sergio finishes the talk by looking at the use of FEC and taking questions from the floor.

Watch now!
Speaker

Sergio Ammirata Sergio Ammirata
CTO,
DVEO