Frequently Asked Questions
If you have a question about DVB-I and you don’t find the answer here, send it to us using the form on the front page.
DVB-I supports various options for the provision of service lists, which enables the support of many different deployment scenarios and business models. Exactly what kinds of lists appear is up to those who implement the specification.
There are still many reasons for users to connect their TV set to an antenna. For example, some services may only be available over broadcast for operational reasons, or may be available in better or more appropriate quality via broadcast. DVB-I enables hybrid offerings combining both broadcast and broadband services.
DVB-I can deliver on-demand content.
Catalogues of on-demand content can be provided using DVB-I metadata that links either to an on-demand stream itself or to an application that would present the selected piece of content. DVB-I service lists can also include services that are themselves apps delivering on-demand content.
The DVB-I client on a mobile device may be provided by the network operator, the device manufacturer, a third-party app developer, or even natively by the device OS, depending on commercial considerations around leveraging linear television service delivery to those devices.
Switching between delivery methods would typically be on an “event” basis. The DVB-I service discovery specification permits “availability windows” to be specified per delivery mechanism and priorities to be assigned to each, allowing selection by the DVB-I client.
The provision of programme guide data for a DVB-I service (channel) is optional but it certainly helps to enrich the user experience.
DVB-I enables the use of authentication and supports the delivery of personalized services. The use of location or accessibility information may not necessarily require knowledge of the actual user, as these can be derived from information configured in the terminal.
Content protection for broadband-delivered services is fully supported.
Various DRM systems can be used, with the content itself protected with the MPEG DASH Common Encryption format. For broadcast services, the usual DVB Conditional Access mechanisms are supported. Authentication and the collection of other user-specific information can be handled by a service-related application, for example using HbbTV.
HbbTV and DVB-I are both ‘service layer’ specifications, but they have different functions and are complementary solutions.
DVB-I covers the signalling of services available over the internet – possibly combined with terrestrial, cable and/or satellite services – and the delivery of those services, while HbbTV rather enables applications to be provided to the user, via broadcast and/or IP as part of a television service.
DVB-I and HbbTV can work together in various ways. A DVB-I service list can include both broadcast and DVB-DASH broadband services that have an associated HbbTV ‘red button’ application. Furthermore, a DVB-I service list can include services that are themselves an HbbTV app, where the app takes the responsibility for presenting the video and audio.
It is also possible to implement a DVB-I receiver as an HbbTV application. And since HbbTV is already widely used in the market, and it can be an enabler for DVB-I deployments.
DVB-I uses generic web-based protocols and does not rely on any specific characteristics of 5G. It could serve as a network-agnostic specification for service discovery, installation and delivery of television services, including as a service layer on top of 5G.