The ATSC 3.0 suite of standards is complete, and real-world trials and deployments are underway. There’s a lot of buzz about ATSC 3.0 in the broadcast industry, and we’re hoping to bring some clarity on the topic of ATSC 3.0 hybrid services.
For starters, with ATSC 3.0, DASH video and audio segments can feed both the broadcast over-the-air delivery chain via ROUTE and the OTT delivery chain via HTTP. Through a standard DASH client, an ATSC 3.0 TV set can receive hybrid services mixing components delivered over-the-air (OTA) and others delivered over a broadband connection. Using DASH on both delivery paths provides the common layer that unifies broadcast and OTT, making it possible to implement hybrid services without reinventing an entire streaming ecosystem. Broadcasters can combine the efficient one-to-many broadcast delivery with the personalized user experience viewers have grown accustomed to. But what’s the best way to establish a hybrid service workflow?
Synchronization is key
Hybrid services require tight synchronization between the broadcast and broadband delivery paths. How do you achieve that?
The DASH MPD (Media Presentation Description) enables synchronization by providing timing information for the consumption and presentation of A/V segments in the DASH client. Here’s how it works:
- Each segment has start time information for the media carried in the segment.
- Each segment has the earliest availability information that defines when the client can request and retrieve the segment via HTTP.
In the diagram above, the origin is the repository of the encoded channel after DASH packaging.
Looking over the diagram, you can see:
- A single representation for the channel is sent OTA.
- The same and/or additional representations for the channel are available via broadband.
- The DASH client can receive from either delivery path, switch among representations and rebuild a valid presentation timeline.
- The DASH packager can adjust the “availability start time” to cover for the latency of the longest delivery path.
Keeping it simple: Implementing hybrid services in the cloud
Recently, we at Harmonic helped implement hybrid services at Chicago 3.0 trial. Chicago 3.0 is an ATSC 3.0 trial launched by Weigel Broadcasting Co. last year in one of the largest U.S. TV markets.
Chicago 3.0’s hybrid service is based on cloud processing and OTT delivery.
In the diagram above, you can see how Harmonic’s VOS®360 SaaS was used at Chicago 3.0 to create a complete DASH service in the cloud, including the representations delivered over the air and the ones delivered over the top. All A/V segments, plus the MPD describing the complete service, are available on the VOS360 origin server.
Here’s how Chicago 3.0 is using SaaS to simplify their ATSC 3.0 workflow: The DASH client in the ATSC 3.0 receiver pulls components of the service via the broadband path in the same way that a traditional OTT service is retrieved. The ROUTE/signaling server at the TV station also pulls from the origin server, but only the MPD and the components that are configured for OTA transmission.
The DASH segments for the OTA representation are ROUTE-encapsulated and passed to the rest of the 3.0 transmission chain.
Specific signaling is sent over the broadcast path to indicate that the service has components available over broadband. In this case:
- A broadband URL pointing to the VOS360 origin server is added to the SLT (service list table).
- The SLT is part of the low-level signaling that can be acquired quickly by the receiver when doing a channel scan.
If the broadband URL is present in the SLT, the DASH client receives the MPD over the internet. Otherwise, it gets the MPD over broadcast.
Chicago 3.0 is a great example of how broadcasters can implement some exciting hybrid use cases for ATSC 3.0, using the cloud to bridge broadcast and OTT worlds. Stay tuned for practical examples of what you can do with hybrid services.