Skip to content

Digital TV broadcasting

Digital television developed alongside the Internet, replacing the analog signal. Digital TV supported features that are unusual for a conventional Internet connection. That's why DVB (Digital Video Broadcasting) systems developed necessary solutions at the time and remain relevant but are useless for the Internet.

This article describes the features of DVB, including distribution over IP networks (IPTV), regards to how it differs from OTT delivery and UGC services, such as YouTube or Twitch.

There are several competivive standards of digital television: DVB, ATSC, ISDB-T. They are rather similar to each other, differ in details a bit.

All of them are describing how to use MPEG-TS to transfer TV channel with strict compliance to TR 101 290

  1. DVB application
  2. DVB in IP
  3. Noninteractive DVB
  4. Engineer aspects of DVB

  5. MPEG-TS

    1. PID and CC
    2. PAT, PMT, and other tables
    3. EIT
    4. CBR encoding
    5. PCR

DVB application areas

The following areas require DVB:

  • satellite TV (DVB-S)
  • cable TV (DVB-C)
  • terrestrial TV (DVB-T)
  • cable TV over IP (IPTV). IPTV often stands apart from DVB, but technical and frame organization relates IPTV to DVB.

The broadcasting in these environments is unidirectional. It means that a source prepares the same set of data for each subscriber and broadcasts it. The number of subscribers doesn't affect the source. The source doesn't know the number of subscribers it has. Unlike the Internet, where the number of clients creates a non-linear load on a server.

DVB in IP

IPTV relates to DVB because the concept of IPTV service is the same as in other DVB environments: unidirectional low-interactive distribution of TV channels over a pre-designed proprietary delivery network. IPTV has the same set of services and user devices, such as set-top boxes and TV sets as DVB-C.

The difference between IPTV and DVB is the HbbTV (Hybrid Broadcast Broadband Television). It's a technology that provides interactive services to IPTV.

Interactivity of DVB

Due to unidirectional distribution, DVB lacks interactive services. It means that if consumers of satellite TV services switch off the set-top box for a long time, the set-top box will miss the session of receiving keys to decode the signal. To activate a new set-top box, the technician of such a service contacts the office and asks them to send keys to the satellite. Using UGC and OTT services, viewers can activate their desired service in just a second.

Without interactive services, you risk losing revenue as subscribers can't immediately access a sports package of TV channels to watch events like the World Cup final with friends. To avoid losing revenue and provide interactive services, traditional DVB services transitioned to IP networks and implemented middleware. Middleware is a website with an embedded player.

Engineer aspects of DVB

Unidirectional DVB delivery systems such as satellite, cable, and terrestrial have the following technical features:

  • Constant bitrate.

    For example, a satellite transmitter on the right frequency transmits precisely 48 MB of data per second. If the transmitter software stops responding for a couple of seconds, subscribers will lose the signal. For engineers, this means creating soft real-time systems with strict bitrate stability requirements.

  • Push model of services.

    In DVB services, to deliver a set of content or TV schedules, data has to be prepared in a certain way. The data is often sent to consumers, even if they don't need this data. Since the data channel dedicated to services is limited, it's challenging to add new services.

  • Regulated protocols and services.

    Committees and government regulators control DVB at the protocol level. It means that any TV works with DVB services, but the list of all possible services is limited and hasn't changed for years. DVB has a set of content as a list of TV channels and a schedule of TV programs on those TV channels in a limited form. The later implementation of HbbTV allowed to provide interactive services and diversity to outdated specifications.

MPEG-TS

DVB uses the MPEG-TS packaging format to deliver television. MPEG-TS isn't a protocol because there is no description of client-server interaction in the standard. Often such interaction doesn't exist.

MPEG-TS is suitable for DVB tasks because it's designed for beyond IP networks. It's when there are no boundaries on the number of packets, addresses, or ports, and a stream of bytes, in which you need to somehow find the boundaries of packets and quickly start showing video.

In practice, MPEG-TS shows that the picture appears on the screen within a couple of seconds.

In the context of DVB, you need to know the following about MPEG-TS:

PID и CC

MPEG-TS was designed to pack several parallel data streams into a single physical channel.

In IP networks, parallel data streams are separated by IP addresses and ports at both ends of the connection. In MPEG-TS, this separation is made by specifying a 13-bit channel number within the shared stream at the beginning of each packet. All packets have the same size: 188 bytes with four-byte headers. In these four bytes, the first byte is reserved for a fixed number 0x47 used to find packet boundaries in the byte stream (three 0x47 bytes running through 187 bytes are sufficient for synchronization). The remaining 3 bytes are reserved for PID (Programme Identifier), CC (Continuity Counter), and other flags.

CC (Continuity Counter) is a 4-bit counter indicating that packets aren't missed. Unlike RTP, DVB doesn't involve packet rearrangement, so you can tell if a pair of packets got lost by using CC. It's more complex to distinguish the loss of one packet and 17 packets.

Under normal conditions, there are no CC errors in the output from the Flussonic Media Server because the server doesn't lose anything anywhere. CC errors can arise due to a restart of the stream or packet loss further downstream.

PAT, PMT, and other tables

PAT, PMT, and other tables establish the transmission format of the list of TV channels available on the current and neighboring frequencies. DVB standard is under government committees control. It means that all set-top boxes and TV sets can read it. For decades, DVB hasn't experienced any development or change.

The standards of the committees don't keep up with the market needs. The situation with LCN (Logical Channel Number) proves the point.

To establish the order of TV channels for consumers, providers use different solutions and none of them has become a standard. It means that for different TV sets, the order is different.

The allocated PIDs transfer records of TV channels in bits. Such design isn't scalable, but vendors and operators come up with their solutions to overcome this complication. Their solutions work and even support adding new codecs.

Flussonic generates all the tables from scratch rather than passes them through from input to output. This way, you get the correct output stream.

EIT

EIT (Event Information Table) transmits the EPG (Electronic Programme Guide) TV schedule in a separate PID.

The metadata channel is constrained, as evidenced by the design of this feature. The TV schedule for the current day is sent much more often than for future days. There's no rush to receive the schedule if the program is scheduled many hours away, but the set-top box still needs to quickly access the current schedule.

The algorithm for preparing EPG schedules can be complex, often requiring dedicated programs. Flussonic has a built-in EIT generator that uses XMLTV to prepare the EPG. For details on how to add the EPG in Flussonic, see Adding the EPG to MPTS.

CBR encoding

Only audio can achieve true constant bitrate (CBR) as each frame of MPEG-2 audio is encoded using the same number of bytes. CBR video is possible when transferring between 300 and 3000 Mb per stream with raw codec or separate frame compression. While the H.264 codec typically operates in variable bitrate (VBR), you can try to achieve CBR by compressing each frame to the required size.

When analyzing one-hour files of a variable bitrate (VBR) stream, you'll notice that they have consistent sizes. It makes them constant bit rate (CBR) streams but with a larger window. In DVB, this window equals one second. It means that the total number of bytes for every consecutive number of frames (typically 25 FPS) remains within the specified limit.

No encoder achieves the specified bitrate. When examining a stream in a DVB analyzer, you'll see graphs displaying even bitrates, thanks to bit stuffing. MPEG-TS maintains the required traffic by inserting Null packets into the stream. Transmitted over a dedicated port, Null packets don't provide any valid information. H.264 uses NAL units (Network Abstraction Layer Units) for stuffing, which are not displayed by analyzers.

DVB encoders are expected to approach the specified minimum bitrate without exceeding it. However, ensuring such precise guarantees for encoders is often excessive, and few transcoders are designed with such strict requirements in mind.

PCR

PCR (Programme Clock Reference)—time stamps showing the timing embedded into the stream. A media player should use it as a reference.
Suppose the player received a frame that has a PTS (Presentation TimeStamp). The player will show the frame when the required PCR arrives in the stream.

PCR doesn't require real-time systems and can be set on an ordinary server, achieving 100% PCR accuracy and zero jitter in the output. PCR accuracy tells you how much the linearity of packet number growth and PCR growth don't match. To create a stream that maintains consistent bitrates for separate PIDs even when certain PIDs are skipped, you need a software that meets several requirements from the DVB standard.

Flussonic drops all incoming PCR marks and often ignores them because they aren't required. Then Flussonic inserts the PCR marks in the output stream with zero jitter value.