Exploring the Role of HbbTV in the DVB-I Environment

In the rapidly evolving world of digital broadcasting, the intersection of traditional broadcast technologies and modern internet-based solutions has become a focal point. The DVB-I standard, which aims to bring the familiar linear TV experience to IP-based networks, has introduced new opportunities and challenges for broadcasters. One of the critical elements in this hybrid ecosystem is the integration of DVB-I with HbbTV. This article looks closely at the relationship between HbbTV and DVB-I, exploring their synergy, technical challenges, and the potential impact on the future of television.
Understanding DVB-I and HbbTV
DVB-I extends the traditional linear TV model to IP networks, providing a seamless, high-quality viewing experience across a wide range of devices. Unlike conventional broadcast systems, it relies on streaming (e.g. DVB-DASH) for content delivery.
HbbTV, has emerged as a critical component for enhancing the functionality and user experience of digital TV. It acts as an application layer, bridging between broadcast and broadband content, enabling features like interactive advertising, on-demand streaming, and advanced user interfaces.
As broadcasters and service providers launch DVB-I based streaming services, HbbTV plays as vital a role in extending the capabilities of those DVB-I-based services as it does today for traditional broadcast services.
The Complementary Relationship
The relationship between HbbTV and DVB-I has become increasingly intertwined. DVB-I has the concept of “Linked Applications,” allowing broadcasters to associate HTML5-based applications (including HbbTV) directly with TV channels and services. This integration enables applications to enhance live and on-demand content with interactive elements, personalized recommendations, and addressable advertising.
In the DVB-I specification clauses “5.1.6” “5.2.3” provide mechanisms to associate an application (e.g. HbbTV) to DVB-I ecosystem. There are a number of different application types as detailed in the table below.
| Type | Application type | When started | Note |
|---|---|---|---|
| 1.1 | App. with media in parallel | When service instance is selected | The application runs “on top” of the contentIt corresponds to the usual “red button” application |
| 1.2 | App. controlling media presentation | When service instance is selected | The application manages the content play.It can rely on HbbTV player (e.g. HTML5) or integrated library (e.g. dash.js) |
| 1.3 | App. in series with media | When service instance is selected unless a previous execution of the application returned the persistent key. | The application is not intended for playing video but for more platform-specific topics (e.g. GDPR consent, single sign-on and some variants of DRM license acquisition). It can be used in combination with a type 1.1 or a type 1.2 app to keep the two sets of functionality in separate apps or developed by separate teams |
| 2 | Outside of availability window | 1) When service is selected and all instances are outside their availability window.2) When all service instances of currently selected service become outside their availability window(s). | The application provide User a better UEX than a «black screen» or a «fixed info screen» |
| 3 | Service provider home page | User selection from DVB-I player UI. | The application is launched from native UI, e.g. EPG or Info-banner |
| 4.1 | Service list installation | During service list installation process. | The application could manage regulated access to particular ServiceList — agreement or consent, user authentication including single sign-on |
| 4.2 | Withdrawal of agreement | User selection from DVB-I player UI. | Used in combination with service list installation app. It enables user to withdraw agreement or consent given when that app was run |
| 4.3 | Renew Agreement | Started by DVB-I player based on information provided when service list installation app exits. | Used in combination with service list installation appIt enables service list provider to require users renew agreement or consent |
With the release of HbbTV Core Specification 2.0.4, “Annex O” extends HbbTV’s functionality to hybrid scenarios (e.g. DVB-I). This annex provides the mechanisms for:
- HbbTV application lifecycle
- An application, if correctly signaled, can be kept running on services from different mediums (e.g. broadcast and broadband)
- Hybrid channel List management
- An application is able to access to the hybrid channel list created during installation process, allowing the user to select services from different mediums (e.g. broadcast and broadband) and broadcasters to implement smart fallback management to IP delivered content
- DASH management
- Reinforced requirements for playing live content and in-band events, which have the same functionality provided by DSMCC stream event on broadcast
The specification permits creation of a single HbbTV Application capable of running on both broadcast and broadband environments.
Where HbbTV is needed
In DVB-I ecosystem, it is important to manage as much functionalities as possible at the ‘native’ level within the consumer device. However, there are functionalities that devices are not in the position to manage at native level and require an application level implementation (e.g. HbbTV), these include:
- Standardized technologies but with un-unique implementation
- E.g. mABR: mABR client implementations are dependent on the network provider’s implementation.
- Service-provider customizations
- E.g. QoS Monitoring: There are different monitoring systems available which may require user agreement for GDPR compliance for tracking.
- Technology provider customizations
- E.g. DRM system: Different DRM systems provide different mechanisms, for instance there are different mechanism for license acquisition and authentication.
- Client side ad insertion/substitution (CSAI/S)
- This requires an application running on the device to perform the insertion or substitution.
There are functionalities which can only be basically managed by the device at native level and can be enhanced at the application level, e.g. accessibility features.
Use Case Examples
Example use cases for HbbTV in an DVB-I environment include:
- DRM Management: HbbTV applications can handle complex Digital Rights Management (DRM) systems, supporting different license acquisition methods based on service provider policies.
- mABR (Multicast ABR): In collaboration with network providers (e.g. TIM in Italy), HbbTV can integrate third-party libraries to optimize ABR delivery, enhancing quality of service (QoS) over varying network conditions.
- Hybrid Applications: interactive “red button” applications running in across both broadcast and broadband services.
- CSAI/S (Client-Side Ad Insertion/Substiution): HbbTV applications can provide targeted, personalized ad experiences, leveraging real-time user data to enhance monetization.
Challenges and Considerations
While HbbTV offers extensive capabilities, it is not a complete substitute for native terminal functions. Key features like channel list creation, parental controls, and basic accessibility features are better handled at the native level for consistency and performance. Additionally, varying implementations of technologies like mABR and DRM across different service providers can still present interoperability challenges even when using HbbTV.
Conclusion
The collaboration between HbbTV and DVB-I is a critical step toward a fully hybrid TV ecosystem, blending the best of broadcast and broadband worlds. As standards continue to evolve, this synergy will likely play a pivotal role in shaping the future of television, enabling richer, more interactive viewing experiences. For broadcasters and service providers, investing in this integration means future-proofing their platforms to meet the diverse demands of consumers.
With ongoing advancements in HbbTV and DVB-I, the future of television promises to be more connected, interactive, and immersive than ever before.
Author:
Stefano Braghieri
Mediaset
Based on a presentation available here.


