Your browser is not supported. Please update it.

21 November 2019

DVB pours clear water between DVB-I and HbbTV

The DVB has now formally ratified the DVB-I standard for broadcast over IP that we previewed back in July ahead of pre-announcements at IBC. As we observed then, that was one of a spate of DVB announcements for IBC but it was the focal point, bringing together the three key ingredients for IP streaming, multicast ABR delivery, low latency and enhanced service discovery. It was the latter that DVB made most of in positioning DVB-I as a long-awaited fix for delivery of linear TV over IP. More specifically, the DVB placed the new specification as the technology required to bring linear TV over the internet up to the standard of traditional broadcast in terms of both video quality and user experience.

This led to some confusion because the DVB also appeared to be hoisting the standard as a successor to HbbTV for hybrid broadcast, offering a migration path to eventual all-IP delivery. Back in July we put this to Peter Siebert, Head of Technology at DVB, who was keen to stress DVB-I was not designed to be a successor or replacement to HbbTV in any way. He noted that HbbTV was built on elements of DVB standards, along with technologies from the Open IPTV Forum, CEA and W3C, therefore having followed a related but distinct trajectory.

Siebert was right in the sense that the HbbTV looks like plotting its own parallel path to the same destination of all-IP delivery. However, it does also seem that DVB-I is a natural successor to HbbTV in a looser context. HbbTV was originally designed for interactive broadcast and then evolved into a hybrid at the service level, combining traditional linear broadcast and broadband in a given box. As such, HbbTV still required a tuner in the box so that broadcast could continue as before, with integration at the level of the UI. DVB-I takes this integration down to the IP level, so that linear broadcast content is also packetized, even if it goes over the same traditional physical infrastructure.

HbbTV then was still geared to broadcast, while DVB-I then evolved almost a decade later for the forthcoming era when all content goes over IP, even if still inside the broadcast domain. The medium itself can still be satellite, cable or DTT, but services will be encapsulated in IP.

DVB-I still supports hybrid services within the IP domain, so that connected TV and broadcast can continue coexisting without needing software or firmware upgrades. This means for example that a tablet lacking a broadcast connection can be automatically routed to the internet, while a TV or set top without broadband connectivity would be switched to IP over a broadcast medium.

While focusing just on IP, DVB-I relies on those three components developed separately within DVB, the low latency operation, multicast streaming and advanced service discovery. The latter is based on a newly approved specification for service discovery and programme information, enabled through DVB-I Service Lists, designed for connected devices to find curated linear TV services, whether these are delivered over broadband or broadcast. This also allows broadcasters to insert their own electronic program (EPG) data for these services to help viewers access their content via the familiar user interface. This is voluntary but will enable a consistent user experience across all services.

This brings us to a link with HbbTV, since a DVB-I service list can include content delivered via an HbbTV app that then takes responsibility for presenting both video and audio. Under this scenario, DVB-I can be seen as a further migration step, enabling the two to coexist.

Then low latency mode is enabled through an enhancement to the DVB-DASH streaming specification known as DVB Bluebook A168, which will be published as the ETSI TS 103 285 V1.3.1. This incorporates the chunked transfer encoding of the MPEG CMAF (Common Media Application Format), developed to enable coexistence between the two principle flavors of adaptive bit rate streaming (ABRS), HLS and DASH.

In streaming, around 90% of latency typically results from playout, being delays associated with the length of video segments. The point is that players typically buffer multiple segments to reduce the likelihood of stuttering. But this can still be achieved with shorter segments, comprising say 1 second rather than 5 seconds of video, providing the impact on quality of encoding is minimized. Shorter segments make it harder for encoders to work efficiently. Chunked transfer encoding is a compromise where the encoder itself splits the segments into groups of frames none of which requires a frame from a later group to enable decoding. The encoder is then configured to output a group of frames almost every second, in fact every 960 ms. The DASH packager then puts each group of frames into a CMAF chunk and pushes it to the CDN. DVB claims this cuts end-to-end stream latency from a typical 20s to 30s down to 3s to 4s, which we have no means of verifying but sounds slightly optimistic for many scenarios.

The third key component of DVB-I is the forthcoming DVB specification for multicast adaptive bit rate streaming (DVB-mABR), for cases where the same linear content is delivered simultaneously over managed broadband networks to multiple receivers. Live sports and breaking news are two major use cases, the savings resulting from only transmitting a single stream of that content along a given link between nodes on the core network.

Multicast ABR, we hasten to add, is not a DVB development but has emerged from earlier work, with French CDN technology vendor Broadpeak among the early pioneers leading to its nanoCDN multicast ABR. The ideas were then taken up by various industry bodies, such as CableLabs in developing its M-ABR Reference Architecture to stimulate vendor interoperability, which in turn has been incorporated largely in the DVB Blue Book.

Multicast ABR has required reconciling the push nature of multicast where content radiates out through the network and the pull aspect of unicast where each device receives the stream it wants and can juggle between different resolutions. It does this by combining the managed and unmanaged domains, noting that multicast ABR can only operate in the former. An operator then brings traffic from the unmanaged internet domain into a managed multicast network, reduces the size and number of chunks there to buffer for a smooth playout and incorporates low latency packaging with CMAF and chunk transfer encoding. Then from the managed network edge, which could be a CDN, the multicast streams are converted back to unicast for delivery to the end user. It is possible to extend the managed domain to the access network, as Broadpeak has done with its nano CDN.