Transport counters (TR 101 290)¶

ETSI TR 101 290 is the industry list of transport stream checks: what must be true for a stream to count as fit, and in what order those violations matter. Mcaster keeps such counters per PID, both on the input and over the parsed stream, so the question "has the signal degraded" stops being a matter of opinion.

This differs from input errors: there it is the reason a source died or spoiled, here it is a measurement of the transport itself.

What is counted per PID¶

Counter	What it means	What to do
`errors_ts_cc`	a continuity counter violation — a portion of the transport was lost or repeated	the main indicator of loss; look for it in the network or at the source
`errors_ts_tei`	the transport error indicator flag is set: a previous node marked the error	the trouble arrived before us — look upstream
`errors_ts_scrambled`	the packets stayed scrambled	the encryption was not removed: CAM, keys, descrambler configuration
`errors_ts_psi_checksum`	a service table's checksum did not match	the table arrived broken; if this keeps growing, receivers lose the service
`errors_ts_pmt`, `errors_ts_pat`	trouble with the program tables	the service does not assemble; the announced program may not be in the trunk
`errors_pid_lost`	the PID disappeared from the stream	a track is gone — on the output that is silence or a black screen
`broken_pes_count`	broken PES packets	damaged payload
`empty_packets`	empty packets on the PID	usually normal, but together with a bitrate dip it is a sign of starvation

Stream-wide errors — errors_ts_pat (a missing or broken PAT) and errors_ts_service_lost (an announced service disappeared) — are counted apart from the PIDs: they mean that what fell apart is not the data but its description.

PCR: accuracy and jitter¶

The PCR is the receiver's clock. If it trembles, the decoder cannot hold its buffer and the picture breaks up even though the stream is intact.

Jitter is counted in buckets, with the standard's PCR_AC = ±500 ns as the boundary:

exactly zero and up to 500 ns — within tolerance;
from 500 ns to 500 µs — an accuracy violation;
over 500 µs — a gross violation;
pcr_resync — the clock had to be re-anchored: a break in the scale rather than trembling.

There is deliberately no single summing field: an "average jitter" hides exactly what the measurement exists for. What to look at is the distribution — a growing share of the fail buckets at an unchanged bitrate means the source or the transport stopped holding the pace.

The decoder buffer (HRD)¶

hrd_buffer_min, hrd_buffer_max and hrd_buffer_underrun describe the hypothetical decoder's buffer model: does the stream reach the receiver in a way that leaves the buffer neither empty nor overflowing.

This answers a question that watching on a computer cannot: will the stream survive a hardware decoder. A software player forgives what a set-top box or a modulator will not.

The timeline: jumps and non-monotonicity¶

A separate group of counters is about time: dts_goes_backwards, dts_jump_forward, too_large_dts_jump, time_corrections, corrected_backward_pts.

For a headend this is an early signal of a bad source: a stream whose scale jumps will reach the receiver, but splicing, recording and multiplexing will suffer from it constantly.

How to use this¶

An alert on rate(errors_ts_cc) > 0 per PID catches transport degradation before a viewer sees it.
Scrambled packets are a binary sign: either there are none, or the configuration is wrong.
PCR jitter and HRD are the acceptance criteria for the output before it is handed to a modulator.
The CC counter on the input can drive the air: the cc_errors_limit threshold marks a source as degraded and the station moves to the backup — see Input redundancy.

The per-PID depth is opened by the extended counters licence option; the error aggregate is always available. Where the counters go and what to look at them with is on the Monitoring page.

Boundaries¶

Mcaster measures what is visible from parsing the transport. The checks that require the radio frequency side — signal level, MER, BER before and after correction — belong to the receiving hardware rather than to the station and are not counted here.