TR 101 290¶
The development of digital television (not as an abstract term, but as a specific set of specifications and products collectively referred to as DVB) coincided with an era where governmental regulators were able to keep pace with market developments and establish standards that all players had to follow to operate in the market.
To establish common service provision rules and measurable quality indicators, DVB developed a set of instrumental checks that demonstrate the correctness of byte stream formation in MPEG-TS. This document is known as ETSI TR 101 290.
In TR101290, it is clearly and unambiguously described how to specifically check the byte stream from the recipient to consider the television stream suitable for quality analysis. Picture quality analysis is done using other methods, with key terms being PSNR, SSIM, and VMAF. The document has been adopted by regulators in various countries as mandatory and serves as a good example of how regulatory work can improve the overall market condition by setting clear rules in the form of an unambiguously interpretable document.
The checks themselves are computationally simple enough to allow constant monitoring of hundreds and thousands of channels without difficulty. This differs from quality checks; for example, VMAF is rarely run constantly and is typically tested selectively, for just a few minutes per hour.
An analogous document might be the one used to write Apple's mediastreamvalidator for the HLS protocol or an extended XML+MP4 validator for DASH.
The part of TR101290 that describes the bytes themselves consists of three chapters, sorted by criticality, called priorities. In addition to this part, there are descriptions of checks in various environments, such as DVB-T/T2, DVB-C/S.
Usage of the standard¶
The document itself is important only for digital television (DVB) and primarily for non-IP environments, such as cable, terrestrial, and satellite. In these contexts, it is very meaningful and significant.
However, it is not an integral part of MPEG-TS itself because its requirements are entirely meaningless in the context of HLS, for example. In HLS, PCR is not used at all, which would be considered heresy for a typical television broadcaster.
1 priority¶
Section 5.2.1 First priority: necessary for de-codability (basic monitoring) describes the most critical issues that prevent the transport stream from being unpacked. These issues are:
TS_sync_loss,Sync_byte_error: inability to synchronize with byte 0x47PAT_error,PAT_error_2: the absence of PAT on PID 0 or its regular loss (information containing the list of TV channels in the stream)PMT_error,PMT_error_2: insufficiently frequent repetition of PMT tables on the PIDs listed in the PAT (description of each TV channel)PID_error: some PIDs are declared, but no packets are received on them within the desired time (the standard here is flexible, leaving the choice to the user)Continuity_count_error: CC errors, which actually indicate loss, duplication, or reordering of packets, with loss being the most common.
In practice, the last point often leads to misunderstandings between individuals with television experience and those with programming experience.
For programmers, the phrase "CC error" primarily sounds like "the code generates an invalid byte stream," whereas it could very well mean "packets are lost due to microbursts, resulting in insufficient data on the receiver's end."
2 priority¶
The next section, 5.2.2 Second priority: recommended for continuous or periodic monitoring, describes the correctness of data generation by the program that created the byte stream. In the DVB world, the concept of remultiplexing is often used, where transport streams are not fully unpacked to frames and back, but are partially rewritten, keeping some data unchanged. Errors can occur during these repacking processes, which are also tracked by this part of the document. Additionally, any of the errors listed below (and above) may arise due to bits changing during transmission, causing the receiver to see something different from what the source sent.
Transport_error: an upstream program has set the indicator for a broken stream. This can be used to raise an alert only in monitoring without disrupting playback on televisions.CRC_error: one of the service tables was modified, but the checksum was not recalculated.PCR_error: the interval between consecutive stream time stamps is too large.PCR_repetition_error: time stamps are marked too infrequently and need to be more frequent.PCR_discontinuity_indicator_error: there was a jump in the stream time, but the discontinuity indicator (or source switching indicator) was not set.PCR_accuracy_error: the most mysterious error for those who think PCR is related to real time. It refers to the non-uniformity of stream time stamping.PTS_error: PTS is set too infrequently. This error dates back to when it was possible not to timestamp frames with PTS/DTS in MPEG-TS at all. In HLS, nothing will play without these markers, but PCR can be omitted.CAT_error: a problem with stream decryption.
PCR¶
PCR, also known as stream time, is one of the most persistent myths, especially in light of the intimidating requirement of 500-nanosecond accuracy. It is often mistakenly associated with absolutely precise timing, leading to myths that a computer cannot generate PCR, while a magical hardware multiplexer made on very expensive Israeli (why not?) FPGA cards can, due to the need for precise timing.
PCR is simply a packet number recalculated using a linear formula:
PCR = PCR_initial + (N*188*8) / Bitrate.
That's all the magic; feel free to use it. The trick is that this formula only makes sense when the stream is prepared with CBR (Constant Bit Rate) requirements, meaning the same number of bytes arrives every second. For HLS, these requirements do not exist, so there is no point in talking about PCR in HLS.
Our media server, Flussonic, generates the MPEG-TS stream independently, timestamps everything itself, packs it in CBR, and delivers a zero-jitter PCR.
3 priority¶
NIT_error,NIT_actual_error,NIT_other_error,SI_repetition_error,TDT_error,RST_error,SDT_other_error: These checks pertain to the frequency and correctness of informational packets (tables) that describe the transport stream and its contents.Unreferenced_PID: This indicates that a PID exists but is not listed in any table. This can happen when extraneous PIDs are added and then extracted on the other side, essentially replacing the instrumental stream structure with voice-over.Buffer_error,Empty_buffer_error: Errors related to the HRD buffer, which are classified under the third priority, although they probably belong in the second priority.EIT_error,EIT_actual_error,EIT_other_error,EIT_PF_error: These errors are related to the schedule, ensuring it arrives on time and is up-to-date.
HRD Buffer error¶
Finding details about this simple mechanism isn't easy, so we'll explain it here.
A frame with a specific PTS (indicated in the PES header of the frame) starts being transmitted to the receiver, which accumulates it in a buffer. The buffer grows with each incoming packet. Once the stream time PCR exceeds the specified PTS, the frame is entirely removed from the buffer, reducing its fill level. This results in a sawtooth graph pattern.
The buffer should not exceed the upper limit (predetermined) or empty "below zero," meaning the frame must arrive completely by the time the specified stream time is reached. The transcoder is responsible for compressing the frame sufficiently to meet this requirement.
Buffer depletion is one of the few issues that significantly affect picture quality because the television either has to formally decode a broken frame or wait for the complete frame to arrive, resulting in a jerky picture.