DVB-T2 terrestrial television

DVB-T2 defines a second-generation terrestrial transmission arrangement with its own coding, framing and physical-layer-pipe configuration requirements.

DVB-T2 is a second-generation terrestrial transmission system with a different reception/framing/coding arrangement from DVB-T. Its receiver requirements cannot be reduced to “the channel uses a newer video codec.”

A frontend must support the applicable physical configuration before the service’s media reaches Emby.

A physical-layer pipe is not a TV channel number

A physical-layer pipe, or PLP, carries data through a defined physical-layer arrangement. Different pipes can use appropriate coding/modulation relationships within the transmission.

The programme service selected by the viewer is another identity. A PLP identifier is neither the service identifier nor the viewer-facing channel number.

Use this original readable configuration:

{
  "deliverySystem": "DVB-T2",
  "plps": [
    {"id": 0, "serviceLabels": ["Harbour News"]},
    {"id": 1, "serviceLabels": ["Harbour Cinema", "Harbour Weather"]}
  ],
  "selectedPlpId": 0
}

The model selects the pipe containing News. It does not establish acquisition of Cinema merely because both pipes belong to the same broadcast arrangement.

The original pipe/service model distinguishes physical selection from programmes carried by that selection.

This is a teaching object, not native DVB signaling, a receiver query or a real broadcaster lineup.

Reception and selection have separate prerequisites

A receiver can establish a relevant RF state while still lacking the requested pipe/configuration. Conversely, recovering the selected pipe does not by itself identify which programme and component streams the application needs.

The complete route relates:

Compatible RF configuration
-> selected physical-layer data path
-> recovered service transport
-> intended programme/components
-> media decoding and presentation

Linux’s frontend interface illustrates that delivery-system and substream-related parameters have defined scopes. Hardware/driver support determines which selections are exposed through that particular implementation.

An Emby backend supplies the recovered service through its own supported interface; it does not automatically eliminate a missing physical selection capability.

Profiles and document editions need their scope

DVB’s published specification page explains the evolution of EN 302 755, including T2-Base/T2-Lite terminology and the accompanying TS 102 755 work.

Those document/profile relationships should accompany claims about features. A broad DVB-T2 label does not prove that an installed receiver supports every option or profile combination.

The separate implementation guidelines explain system choices and receiver context. They are useful alongside the normative framing/coding specification.

The media format remains another condition

A recovered service can carry video/audio with its own codec and profile requirements. Supporting the DVB-T2 waveform does not supply every required media decoder.

If a receiver exposes the wanted service but Emby’s selected client cannot consume its audio unchanged, that is a later compatibility problem. If the source never recovers the wanted data path, an audio conversion cannot fix the earlier acquisition.

See Also

References