HbbTV 2.0: Could This Standard Become the Future of Television?

Hybrid Broadcast Broadband TV (HbbTV) is only 5 years old, but it has already become the de facto interactive TV standard in many European countries, and is generating a significant traction across the globe. While the current version (1.5) brought a lot of improvements—especially for streaming with the introduction of MPEG-DASH—HbbTV 2.0 is bringing a much more powerful toolset that has the potential not only to take precedence over other Interactive TV standards, but also to change the whole television game.

Solving the Pain Points

In the late 2000s, the connected TV market was heating up, driving the promise of an intelligent hub able to connect to all audiovisual services. But each TV had its own OS, its own app store, and its own app development process. Things started to change in 2012, when TP Vision (formerly known as Philips), LG, Panasonic, and Toshiba founded the Smart TV Alliance with the goal of providing a unified SDK for applications development, but still limited to broadband features requiring other SDKs on other TV brands.

While proprietary TV environments provided a suitable option for pure OTT players to reach all devices, it wasn’t—and still isn’t—a satisfying environment for broadcasters that want to develop connected services tightly bound to the air. Connected TV applications are living in a silo—they can’t integrate the live broadcast signal, and each platform uses different streaming formats and DRM, which makes it difficult to standardise content preparation workflows. In parallel to the connected TV app challenges, some broadcasters experienced the difficulties of building second-screen applications: the need for a watermarking SDK, time synchronisation latency, mandatory audio volume to transport the watermarks, and the difficult challenge of getting end users to install specific mobile apps.

HbbTV 2.0—an open specification—was published in February 2015, so it’s fair to call it a pretty young technology assembly. But the work done by the HbbTV Specification Working Group on this version of the standard has spread over more than 2 years of intense discussions and synchronisation with the DVB organisation, and the result is a dense specifications document. And the work done on the previous versions also represented several years of work. HbbTV 2.0 leverages the technical basis of versions 1.1 and 1.5 and adds up decisive features that can solve most, if not all, of the pain points mentioned above, and bring the TV experience to a new level.

Web Stack Evolution

Many observers used to say that HbbTV was outdated in terms of web technologies it integrated. That was somewhat true, as HbbTV 1.5 still mandates the old HTML4/DOM2/CSS2 family, not even mentioning the CE-HTML tags that have been added to the mix. But version 2.0 intends to propel HbbTV into modernity: HTML5/DOM3 and CSS3 are now the norm, and it integrates many HTML5 satellite specs, such as Canvas 2D or the Web Open Font Format for graphical experiences, WebSockets and Server-Sent Events for the communication capabilities, Web Workers, and Web Storage for the processing capabilities and the data persistence. That’s a whole set of features allowing highly dynamic user interfaces. Moreover, they represent a huge boost in terms of reusability of the application code between the desktop web and the TV screen, something that could not be achieved previously. Overall, the evolution of the web stack holds the potential to radically change content providers’ views on HbbTV applications, which are usually seen as an evolved version of teletext. Now, the HbbTV applications will be as dynamic and appealing as the best applications available in proprietary TV stores—the only difference is that they don’t need to be published on each of those stores individually.

Streaming Stack Evolution

Regarding streaming, HbbTV 1.5 already referenced MPEG-DASH as the exclusive technology. Version 2.0 goes beyond by updating MPEG-DASH to its core specification version 2.0, and introduces the DVB DASH profile (urn:dvb: dash:profile:dvb-dash:2014), which is close to DASH Industry Forum’s DASH-IF Interoperability Points— it’s basically merging ISO-BMFF Live and on-demand profiles—but with some specificities. For example, DVB DASH goes up to UHDTV Main 10 L5.1, while DASH-265 goes up to 2K Main 10 L4.1 and will be updated to support the same scope as DVB DASH. Convergence between the two approaches is currently happening through continuous exchanges between DVB and DASH-IF. The same goes for subtitles: after the integration of the new EBU-TT-D format as the reference format in DVB DASH, DASH-IF is considering it also, which is a significant development, as EBU-TT-D has the potential to simplify cross-platform delivery of subtitles while allowing a close integration with broadcast workflows.

There are three other major points where DVB DASH stands out. The first one is the management of multiple audio tracks, where DVB DASH proposes a strong approach to distinguish the different audio adaptation sets, through combined use of role and accessibility descriptors—making it easy to identify audio description tracks, for example.

The second point comes from the fact that DVB DASH has a strong focus on linear TV, with live metadata management. DVB DASH specifies that Content Programme Metadata shall be carried as TVAnytime XML data through EventStream in the manifests, and through Inband-EventStream in media segments—ideally both, as manifest events are good for players entering the stream and inband events work better with already connected players, since there is no latency due to reloading the manifest. When it comes to refreshing manifests, MPD validity expiration events are the proposed trigger.

Finally, DVB DASH defines an interesting mechanism that can be used both for resilience and load balancing between CDNs: the BaseURL element has been extended to support priority and weight parameters. This way, content providers can define a complex set of rules that the DVB DASH player will follow to retrieve the media segments in a redundant mode and at the same time following the business model derived from hosting costs. This mechanism goes hand-in-hand with a comprehensive set of rules for error handling on the player side, as well as a simple mechanism for error reporting to content providers.

While ensuring backward compatibility with MPEG-DASH contents produced for version 1.5, HbbTV 2.0 is gaining with DVB DASH the missing piece that was needed to get linear streaming to a broadcast-grade quality level, if not better in terms of resilience. With the support for Common Encryption and multi-DRM, all the pieces are in place for extensive support of premium video services. Compared to the rather chaotic history of HbbTV 1.5 DASH interoperability, what is the chance that DVB-DASH interop will run more flawlessly? Ignacio Gómez, director of analytics and new projects at RTVE, has spent a lot of time working on HbbTV projects in Spain and is confident that things can go better now.

“As opposed to what happened with the HbbTV 1.5 version, this time the test suites for the new version will be available much earlier, and that will surely help,” Gómez says. “However, it is also very important that we as publishers or broadcasters deploy new HbbTV services supporting DVB-DASH, because this is also what encourages manufacturers to work with us, either on a one-to-one basis or through interoperability workshops, to fix the issues that may arise with their own devices and to ensure that our streams run smoothly.”

Interactivity Stack Evolution

Previous versions of HbbTV already allowed content providers to inject “Do It Now” stream events in the broadcast mux and have the DSM-CC client extract these events on the player side, which could in turn make the extracted data available to HbbTV applications’ JavaScript logic, for use cases such as new questions in play-along quiz games. These events are rather precise in terms of synchronisation, but so far their usage was limited to handle interactions on the first screen. To have the same kind of synced interactions on second screen, content providers so far needed to embed an audio watermark in the broadcast signal and have the mobile device analyse the audio track a few seconds to find the time reference, get the events data from an IP source, and sync it with the broadcast time. Mute your TV and you lose this possibility of interaction. Here HbbTV 2.0 is dramatically changing the game, as the standard mandates every compatible TV to embed a WebSocket server, to which both the HbbTV application and the mobile application can connect easily (through DIAL protocol for the mobile application), pair to each other and exchange messages. If we go back to our Do It Now events use case, the transport path will then be DSM-CC client > HbbTV application > TV WebsocketServer > Mobile application.

The advantages of such a mechanism is that no third-party technology is needed anymore, that it’s not depending anymore on audio not being muted, and that you can easily develop play-along applications where several players interact in the home network as they are all connected to the same TV’s WebSocket server. That’s a whole new field of second-screen interactivity development opportunities opening up.

There’s also a wide field of applications on the first screen when it comes to ad insertion, as broadcast ads can be replaced by ads delivered over IP that can be dynamically customised on a per-user basis; Fraunhofer FOKUS was demonstrating such a use case since HbbTV 1.5 during the last EBU BroadThinking Conference, with its FAMIUM Multiscreen Advertisement solution.

Multistream Synchronisation

Getting the Do It Now events flow through the WebSocket server might be just fine if you want to trigger interactive events that don’t require less timing accuracy than a few tenths of a second, but if you need perfect accuracy, then a more powerful toolset is required. That’s why HbbTV 2.0 integrates the DVB CSS protocols (go2sm.com/ dvbcss), which are defining how TV and mobile devices can synchronise the playback of several streams across devices. DVB-CSS defines how to discover and associate to each other (CSS-DA, over UPnP), share wall clock information for a perfect synchronisation (CSS-WC, over UDP), exchange broadcast content ID (CSS-CII) and over WebSocket, time the position of the content being displayed (CSS-TS), and trigger DSM-CC Do It Now events (CSS-TE). The companion device gets the synchronised contents URLs from a Material Resolution Service over HTTP (CSS-MRS). The precision of the wall clock allows an accuracy of a few milliseconds; it’s therefore possible to stream to the mobile device in an alternative language not included in the broadcast signal. The end user listening on headphones can then experience a clean lip-sync with the TV program.

But things get really powerful when it comes to video synchronisation. For instance, when you watch additional camera views on your tablet alongside the main video signal on your TV, HbbTV 2.0 specifies an optional feature allowing the TV to buffer the broadcast signal and align its playback position on an external time reference. While it’s not a necessary mechanism when streaming additional audio tracks, it is, for all practical purposes, necessary when syncing with video streams on the second screen, as it’s still difficult to rival broadcast latency when streaming video on mobile devices.

Syncing multiple video streams, including a broadcast signal, was previously a real technical challenge; it will soon become a commodity, at least for broadcasters who’d accept a small delay in the signal. But this local buffer on TV is quite similar to the timeshifting features that are commonly deployed on most DTV set-top boxes, so it might not be blacklisted by broadcasters that let the end user risk hearing his neighbour shouting before the TV shows a goal being scored.

UltraHD and Push VOD

While HbbTV 2.0 doesn’t dictate the support of HEVC and UltraHD resolutions in TV sets, it supports it fully. Any TV that supports HEVC for broadcast must also support HEVC for broadband delivery. This means that even if the DTV delivery chain is not ready for UltraHD in a given country, the TVs can still benefit from UltraHD over HEVC by connecting to OTT services delivering the streams over IP, in DVB DASH or in 1.5-compliant MPEG-DASH as we do today. Through the DVB-CSS mechanisms mentioned before, it also means that IP could be used to complement the 1080p broadcast signal and bring the synced UltraHD version of the program being watched. This could be a great facilitator of UltraHD development in the transition phase to terrestrial/ satellite UltraHD delivery, which can take several years from now to finish.

In the meantime, content providers will also be able to distribute UltraHD contents overnight, through broadcast-based push VOD services, as HbbTV 2.0 offers this new optional delivery channel for ISO-BMFF files protected by CENC, using the HbbTV File Delivery Protocol (FDP), which encapsulates data in TS packets and ensures delivery with optional FEC and recovery HTTP URLs. So far, push VOD services have had limited success worldwide, but we can expect that broadband bandwidth limitations for UltraHD on-demand streaming will foster the growth of such services, as they have the capability to deliver buffer-free streams to end users.

The Hub for All Content Types

With the new DVB DASH profile and more powerful hybrid and interactive features, HbbTV 2.0 can grab a strong position in the broadcasters’ world by blending together live broadcast, PVR, catch-up, VOD, and even pay-per-view. The keys for a successful mix will probably be that broadcast and IP delivery can complement each other transparently as the QoS will be guaranteed equally whatever the transport means, and that the contents are perfectly synchronised and linked from a metadata perspective. This last aspect is not covered by the specification; a broadcaster’s know-how is needed when it comes to content cross-referencing and contextual content suggestions. If it’s well-executed and transparent to end users, the hybridisation of broadcast and broadband channels opens up the way for the creation of many additional IP channels to complement the main broadcast channel on a permanent or event-based basis. No more spectrum limitations, only new programmatic opportunities.

Risk Factors

While there is no doubt of the fact that HbbTV 2.0 carries a lot of significant innovations, there is also no guarantee that it will succeed quickly—as its worst enemy is also the HbbTV industry itself. Since its first generation in 2010, HbbTV has certainly scored a lot of points against the proprietary smart TV environments, as we can see today with Samsung joining the HbbTV club, but this success is limited by intrinsic characteristics of the ecosystem.

Free

for qualified subscribers

Subscribe Now Current Issue Past Issues

Hulu’s Move to DASH

The U.S. OTT service's Baptiste Coudurier talks about the hard work—and black magic—behind the smooth migration to MPEG-DASH, which now accounts for 75% of its traffic

08 Jul 2015

HbbTV Growing Outside Europe, Now Compatible with 20M Devices

Don't think of HbbTV as a purely European platform anymore, says the HbbTV Association. It's reach is global.

28 Oct 2014