Webinar: ATSC 3.0 Signaling, Delivery, and Security Protocols

ATSC 3.0 is bringing IP delivery to terrestrial broadcast. Streaming data live over the air is no mean feat, but nevertheless can be achieved with standard protocols such as MPEG DASH. The difficulty is telling the other end what’s its receiving and making sure that security is maintained ensuring that no one can insert unintended media/data.

In the second of this webinar series from the IEEE BTS, Adam Goldberg digs deep into two standards which form part of ATSC 3.0 to explain how security, delivery and signalling are achieved. Like other recent standards, such as SMPTE’s 2022 and 2110, we see that we’re really dealing with a suite of documents. Starting from the root document A/300, there are currently twenty further documents describing the physical layer, as we learnt last week in the IEEE BTS webinar from Sony’s Luke Fay, management and protocol layer, application and presentation layer as well as the security layer. In this talk Adam, who is Chair of a group on ATSC 3.0 security and vice-chair one on Management and Protocols, explains what’s in the documents A/331 and A/360 which between them define signalling, delivery and security for ATSC 3.0.

Security in ATSC 3.0
One of the benefits of ATSC 3.0’s drive into IP and streaming is that it is able to base itself on widely developed and understood standards which are already in service in other industries. Security is no different, using the same base technology that secure websites use the world over to achieve security. Still colloquially known by its old name, SSL, the encrypted communication with websites has seen several generations since the world first saw ‘HTTPS’ in the address bar. TLS 1.2 and 1.3 are the encryption protocols used to secure and authenticate data within ATSC 3.0 along with X.509 cryptographic signatures.

Authentication vs Encryption
The importance of authentication alongside encryption is hard to overstate. Encryption allows the receiver to ensure that the data wasn’t changed during transport and gives assurance that no one else could have decoded a copy. It provides no assurance that the sender was actually the broadcaster. Certificates are the key to ensuring what’s called a ‘chain of trust’. The certificates, which are also cryptographically signed, match a stored list of ‘trusted parties’ which means that any data arriving can carry a certificate proving it did, indeed, come from the broadcaster or, in the case of apps, a trusted third party.

Signalling and Delivery
Telling the receiver what to expect and what it’s getting is a big topic and dealt with in many places with in the ATSC 3.0 suite. The Service List Table (SLT) provides the data needed for the receiver to get handle on what’s available very quickly which in turn points to the correct Service Layer Signaling (SLS) which, for a specific service, provides the detail needed to access the media components within including the languages available, captions, audio and emergency services.

ATSC 3.0 Receiver Protocol Stack

ATSC 3.0 Receiver Protocol Stack

Media delivery is achieved with two technologies. ROUTE (Real-Time Object Delivery over Unidirectional Transport ) which is an evolution of FLUTE which the 3GPP specified to deliver MPEG DASH over LTE networks. and MMTP (Multimedia Multiplexing Transport Protocol) an MPEG standard which, like MPEG DASH is based on the container format ISO BMFF which we covered in a previous video here on The Broadcast Knowledge

Register now for this webinar to find out how this all connects together so that we can have safe, connected television displaying the right media at the right time from the right source!

Speaker

Adam Goldberg Adam Goldberg
Chair, ATSC 3.0 Specialist Group on ATSC 3.0 Security
Vice-chair, ATSC 3.0 Specialist Group on Management and Protocols
Director Technical Standards, Sony Electronics

Video: Low Latency Streaming

There are two phases to reducing streaming latency. One is to optimise the system you already have, the other is to move to a new protocol. This talk looks at both approaches achieving parity with traditional broadcast media through optimisation and ‘better than’ by using CMAF.

In this video from the Northern Waves 2019 conference, Koen van Benschop from Deutsche Telekom examines the large and low-cost latency savings you can achieve by optimising your current HLS delivery. With the original chunk sizes recommended by Apple being 10 seconds, there are still many services out there which are starting from a very high latency so there are savings to be had.

Koen explains how the total latency is made up by looking at the decode, encode, packaging and other latencies. We quickly see that the player buffer is one of the largest, the second being the encode latency. We explore the pros and cons of reducing these and see that the overall latency can fall to or even below traditional broadcast latency depending, of course, on which type (and which country’s) you are comparing it too.

While optimising HLS/DASH gets you down to a few seconds, there’s a strong desire for some services to beat that. Whilst the broadcasters themselves may be reticent to do this, not wanting to deliver online services quicker than their over-the-air offerings, online sports services such as DAZN can make latency a USP and deliver better value to fans. After all, DAZN and similar services benefit from low-second latency as it helps bring them in line with social media which can have very low latency when it comes to key events such as goals and points being scored in live matches.

Stefan Arbanowski from Fraunhofer leads us through CMAF covering what it is, the upcoming second edition and how it works. He covers its ability to use .m3u8 (from HLS) and .mpd (from DASH) playlist/manifest files and that it works both with fMP4 and ISO BMFF. One benefit from DASH is it’s Common Encryption standard. Using this it can work with PlayReady DRM, Fairplay and others.

Stefan then takes a moment to consider WebRTC. Given it proposes latency of less than one second, it can sound like a much better idea. Stefan outlines concerns he has about the ability to scale above 200,000 users. He then turns his attention back to CMAF and outlines how the stream is composed and how the player logic works in order to successfully play at low latency.

Watch now!
Speakers

Koen van Benschop Koen van Benschop
Senior Manager TV Headend and DRM,
Deutsche Telekom
Stefan Arbanowski Stefan Arbanowski
Director Future Applications and Media,
Fraunhofer FOKUS

Video: Adaptive Bit Rate video delivery (MPEG-DASH)

MPEG-DASH has been in increasing use for many years and while the implementations and versions continue to improve and add new features, the core of its function remains the same and is the topic of this talk.

For anyone looking for an introduction to multi-bitrate streaming, this talk from Thomas Kernen is a great start as he charts the way streaming has progressed from the initial ‘HTTP progressive download’ to dynamic streaming which adapts to your bandwidth constraints.

Thomas explains the way that players and servers talk and deliver files and summarises the end-to-end distribution ecosystem. He covers the fact that MPEG DASH standardises the container description information, captioning and other aspects. DRM is available through the common encryption scheme.

MPD files, the manifest text files, which are the core of MPEG-DASH are next under the spotlight. Thomas talks us through the difference between Media Presentations, Periods, Representations and Segment Info. We then look at the ability to use the ISO BMFF format or MPEG-2 TS like HLS.

The DASH Industry Forum, DASH-IF, is an organisation which promotes the use of DASH within businesses which means that not only do they do work in spreading the word of what DASH is and how it can be helpful, but they also support interoperability. DASH264 is also the output from the DASH-IF and Thomas describes how this specification of using DASH helps with interoperability.

Buffer bloat is still an issue today which is a phenomenon where for certain types of traffic, the buffers upstream and locally in someone’s network can become perpetually full resulting in increased latency in a stream and potentially instability. Thomas looks briefly at this before moving on to HEVC.

At the time of this talk, HEVC was still new and much has happened to it since. This part of the talk gives a good introduction to the reasons that HEVC was brought into being and serves as an interesting comparison for the reasons that VVC, AV1, EVC and other codecs today are needed.

For the latest on DASH, check out the videos in the list of related posts below.

Watch now!
Speaker

Thomas Kernen Thomas Kernen
Staff Software Architect, Mellanox
Co-Chair SMPTE 32M Technology Committee, SMPTE
Formerly Technical Leader, Cisco,

Video: Scaling Live OTT with DASH


MPEG DASH is a standard for streaming which provides a stable, open chain for distribution detailing aspects like packaging and DRM as well as being the basis for low-latency CMAF streaming.

DASH Manifest files, text files which list the many small files which make up the stream, can be complicated, long and take a long time to parse, demonstrates Hulu’s Zachary Cava. As the live event continues, the number of chunks to describe increases and so manifest files can easily grow to hundred of KB and eventually to megabytes meaning the standard way of producing these .mpd files will end up slowing the player down to the point it can’t keep up with the stream.

Zachary goes over some initial optimisations which help a lot in reducing the size o the manifests before introducing a method of solving the scalability issue. He explains that patching the mid file is the way to go meaning you can reference just the updated values in the latest .mpd.

With on-secreen examples of manifest files, we clearly see how this works and we see that this method is still compatible with branching of the playback e.g. for regionalisation of advertising or programming.

Zachary finishes by explaining that this technique is arriving in the 4th edition of MPEG-DASH and by answering questions from the audience.

Watch now!

Speaker

Zachary Cava Zachary Cava
Video Platform Architect.
Hulu