Published by DTVKit | Last updated: 2026
DVB-I is one of the most significant standards to emerge from the DVB Project in the last decade. It provides the framework that allows a connected device to discover, present, and switch between broadcast and internet-delivered television services within a single unified channel list, without the viewer needing to know or care which delivery network is in use.
For device manufacturers, chipset vendors, middleware developers, and platform operators, DVB-I represents both an engineering challenge and a commercial opportunity. This article explains what DVB-I is, how it works at a technical level, what a compliant receiver implementation requires, and why it matters for the next generation of hybrid TV products.
The Problem DVB-I Solves
Traditional broadcast television relies on DVB Service Information (DVB-SI) , metadata carried inside the MPEG transport stream that tells a receiver what services exist on a given multiplex: their names, logical channel numbers (LCNs), language tracks, and access parameters. This works well for antenna, cable, and satellite delivery, but it is fundamentally tied to the broadcast infrastructure.
At the same time, streaming platforms have proliferated while each operating within their own discovery and metadata silos. OTT services typically require dedicated client apps, each with its own specific user experience. There is no shared, interoperable mechanism by which a receiver can query a standardised source, retrieve a structured list of linear TV services delivered over IP, and render them alongside broadcast channels in a familiar numbered channel grid.
DVB-I solves precisely this. As the DVB Project defines it, DVB-I is an internet-centric way to signal and discover television services, whether they are delivered over broadband or broadcast, enabling those services to be presented in a unified manner on any connected device, from TV sets to smartphones and tablets. Conceptually, DVB-I is to IP-delivered television what DVB-SI is to broadcast: the authoritative source of truth about what services exist and how to access them.
The Core DVB-I Architecture
This covers Services, Lists, Registries, and Clients.
DVB-I is formally standardised as ETSI TS 103 770, with implementation guidance in DVB BlueBook A184. The architecture is built around several interconnected components, each precisely defined in the specification.
DVB-I Services and Service Instances
A DVB-I service is any service discoverable using the mechanisms defined in the specification, available via one or more delivery systems including DVB-DASH for online delivery and traditional DVB cable, satellite, or terrestrial transmission. A service may only be accessible under certain conditions such as location, content rating, conditional access, or subscription package. It may be linear or on-demand, and may include audio, video, subtitle, or accessibility components, and may have linked applications.
A DVB-I service instance refers to the delivery of a DVB-I service via a single delivery mechanism. The same service can have multiple instances. For example, one delivered over DVB-T and another over DVB-DASH, potentially differing in video resolution, encoding quality, language, or regional content. A hybrid DVB-I client can match and merge these instances, presenting a single entry in the channel list regardless of which delivery path the device ultimately uses.
DVB-I Service Lists
A DVB-I service list may list services from one or more content providers. A service list provider manages the list and provides service ordering and numbering information. A service list may be targeted at a particular platform brand, geographic region, language, or genre. Clients marketed under a platform brand may use a single service list for that brand. Clients may offer a selection of service lists and present the user with a view of services from only one at any time, or they may combine several service lists, presenting them with or without filtering options.
The service list is delivered as an XML document. Each entry contains everything a receiver needs to present and tune to that service: name, logo URL, LCN, content guide source, delivery parameters (for IP streams this is typically a DVB-DASH MPD manifest URL), accessibility attributes, regional targeting information, and any linked interactive application. One or more service list servers may deliver a service list to a DVB-I client, and a service list server may itself aggregate service list fragments from multiple content or service providers.
The Service List Registry
This is the area most commonly misunderstood in DVB-I implementations, and it is worth being precise about what the specification actually says.
A DVB-I service list registry provides a DVB-I client with a list of one or more service list servers in response to a request that may include query parameters. It provides an HTTP endpoint at a known URL and, in response to a query, returns a list of service list entry points. The registry is a directory of directories: it does not itself contain channel data, but points clients to the service list servers where that data lives.
Critically, the DVB-I specification does not mandate a single, global service list registry. A service list registry may be operated by or on behalf of a wide range of organisations, including:
- Device manufacturers — providing a curated default registry pre-configured in their devices
- National or regional regulators — providing a registry of trusted, authorised services for a given territory
- Operators or platform brands — providing a registry tailored to their subscriber base or platform
- Third-party service list aggregators — providing a multi-provider registry across a market or region
- Central registries — providing information on a wide set of service lists to any compatible client
This means the DVB-I ecosystem is inherently federated. Multiple registries can co-exist in a single market. A device may be configured to query one or more registries, a national regulator’s registry for authorised PSB services, an operator’s registry for subscription services, and a manufacturer’s registry for a curated default experience could all apply simultaneously. A client may also be pre-configured with service lists that are not advertised by any registry.
Deployments illustrate this flexibility well. In Iran’s IRIB pilot, the broadcaster created its own service list registry containing 60 service instances mixing DVB-T and DVB-DASH delivery. In Germany, the DVB-I Round Table has established the organisational framework for a joint national service list. Eutelsat’s Sat.tv Connect service uses DVB-I to manage multiple service lists per satellite position with up to 33 different lists with sub-filtering by region, country, or language.
The DVB-I Client
The DVB-I client is the receiver-side software stack that implements the full workflow: querying registries, fetching and parsing service list XML, managing regional filtering, resolving LCNs, handling parental controls, exposing EPG data, and responding to updates. A DVB-I client may be integrated into the UI of a device such as a television or set-top box, or may be part of an application on a mobile phone or tablet.
In a hybrid device , one with both a broadband connection and a broadcast tuner, the client is also responsible for rationalising services that appear in both the DVB-I service list and the broadcast multiplex, presenting a clean combined channel list without duplicates. The process for resolving dupilcate channel instances can be based on several factors including locality, user preferences, quality of available services and accessibility requirements.
How the Discovery Flow Works (Step by Step)
Here is the sequence of operations a DVB-I client performs during setup and ongoing operation:
Registry query
The client sends an HTTPS GET to the configured service list registry endpoint (or multiple endpoints). The response is an XML document listing available service list entry points, optionally filtered by query parameters such as country or region.
Service list fetch
The client retrieves one or more service list XML documents from the indicated service list servers. Each contains a full description of available services including delivery parameters, LCNs, logos, content ratings, and accessibility metadata.
Region and SRS filtering
The client applies Target Region filtering to select the correct service instances for the user’s location, using a region/SRS (Service Representation Selector) state machine to evaluate regionally targeted entries.
LCN assignment and duplicate channel rationalisation
The client assigns logical channel numbers per the specification rules, resolving conflicts where multiple service lists are merged. For hybrid devices, broadcast and IP instances of the same service are matched and collapsed into single channel list entries. Broadcast services not referenced in any service list may be allocated an LCN in the overflow range.
EPG population
Content guide sources referenced in the service list are fetched and cached, populating the electronic programme guide. The content guide server or servers for each individual service are referenced in that service’s service list entry.
Auto-refresh
The client periodically checks for service list updates, using cache control headers and update signalling defined in the specification to maintain an accurate and current channel lineup without user intervention.
Parental control enforcement
Content ratings are evaluated against the user’s configured policy, with country-scoped rating filtering, PIN flows, and retry timers applied as needed.
DVB-I and HbbTV: Complementary Standards
DVB-I and HbbTV work together rather than competing. HbbTV is an application delivery framework defining how interactive applications such as catch-up players, red-button services, EPG overlays, etc., are launched and rendered on a receiver, using broadcast signalling via the AIT (Application Information Table) to associate applications with broadcast services.
DVB-I extends this into the domain of IP delivered channels. A DVB-I service list entry can reference an HbbTV application via an AIT entry in the service list XML, allowing the receiver to launch the appropriate broadcaster application when the user tunes to an IP-delivered service, mirroring exactly the behaviour of broadcast-delivered HbbTV. The HbbTV standard has been formally extended to provide full support for DVB-I.
This integration means DVB-I is not simply a channel discovery mechanism. It is the foundation for a fully interactive hybrid TV experience in which broadcast reliability, IP flexibility, and HbbTV interactivity are presented to the user as a seamless whole.
What a Production DVB-I Client Must Implement
For engineers building a compliant product, the implementation scope is substantial. A production-grade client must handle:
- Registry and service list discovery — HTTPS transport, XML parsing of the registry response, and retrieval of one or more service lists from referenced servers
- Full service list parsing — schema validation and complete handling of all defined element types, extension points, and service instance variants
- Region and SRS state machine — target region evaluation, location resolution, and correct service instance selection
- LCN management — assignment, conflict resolution between merged service lists, overflow range handling, and update propagation
- Parental control — country-scoped rating systems, PIN enforcement, hidden channel handling, and retry timers
- Accessibility metadata — parsing and surfacing of audio description, subtitle, dialogue enhancement, spoken subtitle, and sign-language track descriptors
- Content guide integration — fetching, caching, and refreshing EPG data from service-list-referenced content guide servers
- Service list auto-refresh — background refresh with correct cache invalidation and transparent channel list updates
- AIT and HbbTV integration — parsing linked application descriptors and signalling them to an HbbTV engine
- Box set and on-demand support — series and episode grouping metadata for on-demand content integrated into the channel list
DVB BlueBook A177r7, published in July 2025 as an interim draft of the forthcoming ETSI TS 103 770 V1.3.1, further extends DVB-I with GDPR-compliant consent management signalling, a new “Application in Series” type enabling applications to run before media presentation begins, and versioning signals in the service list registry to support stable market rollouts as the standard evolves.
DVB-I in the Real World: Growing Deployments
DVB-I is no longer a future standard , it is in active deployment across multiple markets globally. Freeview New Zealand announced Freeview NextGen in May 2026 as the world’s first nationwide free-to-air platform built on DVB-I, targeting a Q3 2026 launch with Hisense and TCL. Italy has had a live market trial since Q4 2023, with certified DVB-I TVs commercially available. Germany’s DVB-I Round Table approved the “DVB-I Book Germany” in May 2026 for a September 2026 commercial launch. Eutelsat’s Sat.tv Connect, live since September 2024, uses DVB-I to manage 33 service lists across multiple satellite positions. Trials and pilots are underway in Spain, Ireland, Australia, France, China, and Iran.
This breadth of activity across terrestrial, satellite, cable, and IP-only scenarios demonstrates that DVB-I is genuinely network-agnostic and adaptable to diverse industry structures.
DTVKit’s Reference DVB-I Client
DTVKit provides a production-ready, fully standards-compliant DVB-I client that addresses the complete implementation scope above. Written in native C++17, the client has a small RAM and ROM footprint and is portable across Android, Linux, and RDK platforms. It can also be deployed in a Docker container for cloud-based development and testing workflows.
The client is structured around three clean, layered APIs:
- libdvbi — the core parsing and data-handling layer, covering HTTP transport, XML processing, and all DVB-I data structures
- libdvbi-manager — a high-level API with integrated caching, background refresh, region/SRS state machine, parental policy handling, and a notification centre for surfacing updates to the application layer
- libdvbi-jsonrpc — a WebSocket JSON-RPC 2.0 server exposing the manager API to external processes, enabling integration with HbbTV applications, native EPGs, companion devices, and cloud diagnostics tools
The implementation is backed by over 27,000 lines of test code including more than 530 Catch2 unit tests and live-server integration tests against real DVB-I deployments. DTVKit also provides a reference Android integration via the Android TV Input Framework (TIF), validated on the DTVKit reference hardware platform, giving manufacturers a proven starting point for Android and Google TV products.
DTVKit membership provides full C++ source code access on a royalty-free basis with no per-unit fees, no runtime charges, enabling rapid customisation and complete control over the stack.
Why DVB-I Matters for the Industry
Terrestrial and satellite delivery remain dominant in many markets, but broadband-only households are growing, and regulators across multiple countries are actively exploring DVB-I as the mechanism for ensuring public service broadcaster visibility on connected devices regardless of whether those devices carry a physical tuner.
DVB-I provides the open, standards-based answer to the smart TV channel list problem the industry has attempted to solve with proprietary platform arrangements for over a decade. Being an open standard, DVB-I can be freely implemented in any application, device, or display, enabling a competitive consumer market. It does not impose any form of presentation on how the information it provides is rendered, the client decides that. This flexibility is precisely why it is being adopted across such diverse deployment contexts: free-to-air DTT in New Zealand, satellite in Europe, cable, IPTV, and 5G media streaming trials globally.
For device manufacturers and OEMs, DVB-I compliance is increasingly becoming a market entry requirement. For middleware and platform engineers, building a correct, robust, and maintainable DVB-I client that correctly handles multiple registries, multiple merged service lists, regional filtering, and live update cycles, is the core implementation challenge, and the quality of that implementation directly determines the quality of the experience that broadcasters and operators can deliver. This is where DTVkit can help OEMs bring to market robust DVB-I enabled products in an efficient and cost effective manner.
Further Resources
- DTVKit DVB-I Client — dtvkit.org/solutions/dvb-i
- DVB-I Technical Overview — dvb-i.tv/about
- DVB-I Deployments — dvb-i.tv/deployments
- DVB-I Specification (ETSI TS 103 770) — dvb.org
- DVB-I Implementation Guidelines (BlueBook A184r2) — dvb.org
- DTVKit Membership — dtvkit.org/pricing
DTVKit is a UK-based not-for-profit organisation delivering royalty-free, shared-source middleware for the global digital TV industry. Our DVB-I client is in active development and production deployment across Android, Linux, and RDK platforms. For membership and technical enquiries, visit dtvkit.org.
