Skip to main content
DVB-I Services over 5G

Implementation Detail

In short
  • What this covers: the DVB-I client (browser and Android), the service list and content guide server (the application provider), the service list registry and the Exo DVB-I Player, judged against the published ETSI standard TS 103 770 V1.2.1 (5 September 2024). The audit was first made against the later draft DVB BlueBook A177r8 (30 June 2026), the draft of V1.3.1, and has been re-based onto V1.2.1: every entry is now judged against the published edition, and the differences of the draft are noted per case. 5G-MAG has not verified that ETSI has published V1.3.1. Statements that exist only in the draft are listed as draft-only and not counted. Judged on the main branch of each repository on 2026-10-22.
  • Source of this page: every requirement is split into the cases its clause defines; each case was read against the code by one reader and then independently by a second, with a third reading where they disagreed. Cases that rest on documents that were not available (ETSI TS 102 796, ETSI TS 102 809) or that only a running system can settle are not shown.
  • DVB-I over 5G: the 5G parts (TS 26.347, ETSI TR 103 972, the MBMS client interface) are outside the scope of this audit. The Android client carries the DVB-I side of an MBMS path, but the only MBMS client behind it is a no-op, so no service is received over 5G Broadcast today.

For what the specifications define, see the Technology page. For how to run the tools, see the Tutorials.

What the Reference Tools implement​

The statements below are read against ETSI TS 103 770 V1.2.1, with the differences of the draft A177r8 noted where they matter (the status table names the edition of each entry). They describe the main branch of each repository on 2026-10-22.

  • Provider (service list and content guide server, with an editor): publishes one DVB-I service list with channel numbers per region, service instances for DASH, multicast, HLS and MBMS delivery, a content guide for schedule and now/next, and a service list editor with history. It does not handle the image_variant parameter of the content guide endpoints (an unlisted value is not rejected with HTTP 400, and an unavailable variant is answered with the one image instead of none). The programme information endpoint named in the list points at the now/next route, which ignores pid, and there is no More Episodes endpoint. List, service and region list versions are raised on every save and history restore, never reused, but not when a logo is uploaded or deleted; V1.2.1 says only that the version shall be incremented for every published change and does not define a published change, so this is judged a difference by the plain reading. The list is served as application/vnd.dvb.dvbisl+xml, the media type V1.2.1 clause 5.1.2 requires (the draft A177r8 names application/xml and allows the former only in some situations). OnDemandProgram lacks @serviceIDRef and its mandatory Genre, and the ContentGuideServiceRef it publishes is not accepted as sid by its own endpoints. Draft-only features are not counted against it: the versioned URL and StandardVersion, the MinimumAge range check, signatures and content digests.
  • Browser client: discovers a service list, presents channels and a content guide, applies the user's region, parental rating and instance priority, and plays through dash.js and hls.js. It has no linked-application engine, so applications that control media presentation are not run. It checks the loaded list every 30 seconds and refreshes it daily at a fixed 03:00 without randomising the time, does not evaluate service hours of a service instance, does not read cache directives, accepts plain http, and enforces parental rating only at service level and only with a PIN.
  • Android client: implements more of the selection rules, including the regulator-list default, instance precedence with service hours, ContentGuideServiceRef precedence, programme requests with pid and RFC 3986 query encoding. It has no background check every 24 hours, has no linked-application engine and no Restart handling, and reads the programme rating once when the player opens.
  • Service list registry: answers client queries with a list of service list entry points and rejects undefined parameters. It writes application/vnd.dvb.dvbisl+xml for every URI, the media type V1.2.1 uses for service lists (the draft A177r8 requires it for URIs up to release 6 and adds image_variant, which the registry answers with HTTP 400 as an unknown parameter; V1.2.1 does not define it for the registry). It drops offerings that carry no TargetCountry, Language or Genre when that parameter is queried, does not validate every value, and writes no @regulatorListFlag, @version or @required. Nothing in the registry enforces that ServiceListName equals the Name in the service list itself, so that requirement is absent.
  • Exo DVB-I Player: the repository holds a WebView around an external front end and a patched ExoPlayer. The DVB-I logic is in the external front end, which is not part of the repository, so the client-side behaviours of the specification are absent here.
  • Across the repositories: none has content digests, signature policies, JWS signatures or signature reports, DNSSEC, mDNS discovery, CMCD in the native clients, or restart signalling. Most of these exist only in the draft A177r8, not in V1.2.1, and the clients' lack of ?querycapabilities, client versioning (User-Agent format) and removal of an installed list is likewise listed as draft-only and not counted.

Implementation status​

Open a feature, then a requirement, to see each case and why. Filter by component and release.

  • DVB-I over 5G Systems.
  • Client (DVB-I Application (browser client)): rt-dvb-i-application, rt-dvb-i-android-application, rt-5gms-application.
  • Provider (DVB-I Application Provider (service list and content guide)): rt-dvb-i-application-provider.
  • Registry (DVB-I Service List Registry): rt-dvb-i-service-list-registry.
  • Exo player (Exo DVB-I Player (Android WebView around an external DVB-I frontend, with ExoPlayer)): rt-dvb-i-application, rt-dvb-i-android-application, rt-5gms-application.
  • Android (DVB-I over 5G Reference App (Android client)): rt-dvb-i-application, rt-dvb-i-android-application, rt-5gms-application.
  • MBMS Client (MBMS Client behind the DVB-I client (none exists; adapter-mbms delegates to a no-op client)): .
  • Playlist Server (Playlist Server of clause 5.2.7 (none exists)): .
  • Application Server (Application Server of clause 4.1 serving linked applications and AIT (none exists)): .
  • Source: code read against every statement of the published edition ETSI TS 103 770 V1.2.1 (2024-09). Every entry is judged against V1.2.1: where a clause reads the same in the draft DVB A177r8 (V1.3.1 draft) the verdict stands, and where the draft differs the difference is noted in the case; statements that exist only in the draft are listed as draft-only and not counted. The client entries (browser client, Exo player and Android client) were judged by each component's own code at rt-dvb-i-application bb15220, rt-dvb-i-android-application 553b4a4 and rt-5gms-application 6536205. Statements a component cannot meet by construction are marked absent by group; entries touched by later fixes were re-read at rt-dvb-i-application-provider e3cfb1e, rt-dvb-i-service-list-registry d0ab0ea and rt-dvb-i-application bb15220, 2026-10-22.
  • Not shown: 16 further cases (it could not be settled by reading the code).
216 of 775 implemented · 73 differ · 486 absent · 388 in the draft only, not countedcases, over 222 requirements

✓ Implemented≠ Differs from the specification– Absent? Specification inconsistent: its text and its OpenAPI or tables disagreei Noted: observed, not a verdict against a clause

How carriage over 5G Broadcast already works2 of 17 implemented · 15 absent · 3 in the draft only, not counted
DVB-I service discovery138 of 464 implemented · 39 differ · 287 absent · 221 in the draft only, not counted
Implementation blueprint76 of 294 implemented · 34 differ · 184 absent · 155 in the draft only, not counted
GeneralDraft only 9 in the draft only, not counted
Full audit for members

The full audit, with the code behind each verdict, is available to 5G-MAG members through Developer Tools.

Become a member · Request access

Used with other projects​