Analyser

The built-in analyser continuously checks and measures the active input of every stream. The results are used by several node subsystems: the validity verdict drives input switchover (Source redundancy), the metrics and charts are shown in the stream statistics window (Stream statistics) and the summary badges in the stream list, and violations raise alerts (Alerts (alerter)). The mosaic, EPG import and the subtitle decoder use the data of the analyser decoder (Processing pipeline).

The basic checks and measurements are always on. The in-depth analyses are enabled by separate settings on the “Analyze” tab of the stream editor. Each of these settings adds CPU load, so they are enabled only when needed. The cumulative counters are cleared with the “Reset statistics” button in the statistics window.

Validity check

The input stream is checked in stages: TS synchronisation lock, reception of the PAT and PMT tables, presence of PCR stamps, and parsing of the audio and video tracks down to decoding a key frame. The result is shown in the statistics window, in the “MPEG-TS check” section, as the individual TS, PAT, PMT, PCR, Audio, Audio ES, Video, Video ES attributes. The check repeats at the stream check interval; an input is declared failed if the stream fails the check or if no data arrives for longer than the stream timeout. The stream then switches to the backup input (Source redundancy).

A scrambled transport is considered valid (SPTS streams): the transport and PSI layers are still checked, and once clear data appears the full analysis resumes automatically.

Continuous measurements

With no additional settings the analyser measures:

  • Bitrate — the rate of the input stream (for SPTS, from the PCR stamps; for MPTS, against real time) and the output rate after the synchroniser; the “Bitrate” chart in the statistics window.

  • Bitrate per PID — the current rate and the number of packets per second for every PID of the active input; the table in the “Analyzer” block of the statistics window. The PID type comes from parsing the stream tables (PAT, PMT, video, aac and the like); the PID of the NULL packets (8191) is marked NULL, and a stream whose type could not be determined is marked with a dash. The measurement is for SPTS only: an MPTS stream has no such table with any multiplex source, and the multiplex table shows the programmes and their rates (Per-programme analysis).

  • Continuity and transport — continuity counter (CC) errors (windowed and cumulative), transport errors (TEI), scrambled packet counters; the “Continuity and scrambling” chart.

  • PCR interval — the average and maximum interval between PCR stamps. With the TR 101 290 monitor enabled, the strict limit of 40 ms applies; without it, the ISO/IEC 13818-1 limit of 100 ms.

  • PCR jitter — the lag of the output scheduler behind the PCR pace; the “PCR jitter” chart. This is an internal output metric of the streamer, not an indicator of the input stream: what external analysers and TR 101 290 call PCR jitter or PCR accuracy corresponds here to the “PCR accuracy” metric (below).

  • PCR drift — the systematic deviation of the source clock frequency from real time, in ppm. Unlike jitter, drift reflects the stability of the encoder’s crystal and builds up over minutes; a reliable verdict needs a window of 300 seconds or longer. The ISO/IEC 13818-1 tolerance is ±30 ppm; a sustained excess is highlighted in the statistics window (“PCR drift”), separately from the TR 101 290 verdict, because crystal drift is a fault of the encoder on the source side, not of transport integrity.

  • PCR accuracy — the error of PCR stamp insertion relative to the actual moment of transmission; the TR 101 290 tolerance is ±500 ns. The metric is meaningful only for streams with a constant bitrate (see the mode detector below).

Multiplex mode detector. The analyser automatically classifies the source as CBR or VBR from the regularity of the PCR relative to the packet position; the verdict is latched with hysteresis to rule out frequent switching. A confident verdict is shown as a CBR or VBR badge in the stream list; while there is not enough data, there is no badge. VBR is not a defect but a normal mode: in it, the checks that are meaningful only for CBR (PCR accuracy, the T-STD video buffer) are automatically not evaluated.

In-depth analyses

Three independent analyses are enabled on the “Analyze” tab of the stream editor (all are off by default):

“Deep analysis”

Switches the analyser to the continuous stream parsing mode (noticeable CPU load) and adds:

  • the intervals of the PAT and PMT tables (recommended: no more than 500 ms);

  • the intervals of key frames (GOP) and of IDR frames. For players that connect at an arbitrary moment, a GOP of no more than 1 second is recommended. If the IDR interval roughly matches the key frame interval, the stream has a closed-GOP structure (every GOP opens with a complete entry point); if the IDR metric is absent, the stream has an open-GOP structure;

  • the interval from PAT to a key frame — it determines how fast playback starts when a player connects at an arbitrary moment;

  • the video codec data sheet (stream type, profile and level, resolution, scan type, VBV parameters) and the parameters of the audio tracks;

  • ad insertion readiness data: GOP structure, random access indicators (RAI), SCTE-35 events and splice points. The advance notification threshold for a splice point is set by the advanced setting “Notify of splice point in advance (frames)”;

  • presence checks of the SI tables (SDT, EIT, NIT, TDT) and elementary stream structure errors.

“Analyze PCR/PTS gap”

The spread between the PCR and the PTS/DTS stamps of each elementary stream. Too large a spread causes problems for players with a small synchronisation buffer. The repetition interval of the video PTS stamps is also measured (indicator 2.5 of the TR 101 290 report, limit 700 ms).

“Analyze T-STD video buffer”

The T-STD reference decoder buffer model (ISO/IEC 13818-1): a check that the video buffer neither overflows nor underflows. MPEG-2, H.264/AVC and HEVC are supported; the leak rate adapts to the actual video bitrate. It is evaluated only on streams with a constant bitrate.

The results are shown in the statistics window in the “Deep analysis” and “Analyzer” sections. The “Trace” and “MPEG-TS trace” settings enable verbose logging of the stream check. These settings are for diagnostics only; do not leave them permanently enabled.

TR 101 290 monitor

The “TR 101 290 monitor” setting (“Analyze” tab) enables a continuous check that the stream conforms to the ETSI TR 101 290 standard. The monitor is lightweight (it does not enable heavy elementary stream parsing) and works independently of the in-depth analyses.

The monitor gives a single verdict for the stream: “OK”, “Problem” or “Checking…” while data is being accumulated. The verdict is shown as a coloured TR-290 badge in the stream list and in the statistics window; clicking it opens the “TR 101 290” report, a table of indicators grouped by the priorities of the standard (priority 1 is required for decoding, priority 2 is recommended for monitoring, priority 3 depends on the application), with the measured values and the limits.

How the monitor evaluates:

  • A violation enters the verdict only when it is persistent (observed for at least 30 of the last 60 seconds), so short bursts do not light the indicator. The acceptance level is tracked separately: a violation lasting continuously for 300 seconds is the criterion for the technical acceptance of a channel.

  • Some indicators require additional analyses. Rows that depend on the “Analyze PCR/PTS gap” and “Analyze T-STD video buffer” settings are marked as disabled in the report when the setting is off and do not affect the verdict. The numeric PAT/PMT intervals and the SI table presence checks are measured only with the “Deep analysis” setting enabled; without it, the corresponding rows have no measured values.

  • PCR accuracy and the T-STD video buffer are evaluated only after the mode detector has confirmed a constant bitrate of the source, and they continue to be evaluated until the statistics are reset or the bitrate shaping settings are changed, even if the detector verdict changes later. On streams that have never been confirmed as CBR these rows are not evaluated.

  • With bitrate shaping active, the monitor measures the emitted, shaped stream (Bitrate control).

  • For an MPTS stream, a single verdict is issued for the whole multiplex (Per-programme analysis).

Persistent violations also raise alerts with analyser codes; the full list is given in Alert code catalogue. The “Reset statistics” button resets the monitor counters and the accumulated statistics.

Complaint assistant

While an SPTS stream has an active TR 101 290 violation or PCR drift, the web interface offers a ready-made prompt for an AI chat. From this prompt the AI chat writes a formal letter of complaint to the stream provider, in English. The node sends nothing: the operator sends the letter to the provider themselves.

Where it appears. The “AI letter” icon with an envelope is shown in the stream row on the “Streams” screen and in the summary of the stream statistics window, right after the TR 101 290 icon (Streams). The icon is there only while all of these conditions are met:

  • the stream is SPTS and its active input is running;

  • the active input has a persistent violation: PCR interval, accuracy or discontinuity, PAT, PMT and PTS intervals, CRC errors of the PSI tables, transport errors, intervals of the SDT, EIT, TDT and NIT tables (only those present in the stream), PCR drift. CC errors alone do not produce a letter, even though they turn the TR 101 290 verdict bad;

  • TR 101 290 violations count only with the TR 101 290 monitor enabled (TR 101 290 monitor); PCR drift always counts;

  • an account with the Admin role (Access and roles). The icon is not shown to the Restricted admin and Viewer roles, and the node also refuses them the prompt.

The demo edition does not include the assistant.

How to get the letter.

  1. Click the “AI letter” icon. The “AI complaint letter” window opens with the stream name in its title; the “Prompt for an AI chat” field holds the text prepared by the node.

  2. Click “Copy prompt”: the whole prompt is copied to the clipboard.

  3. Paste the prompt into any AI chat. It will compose the letter from the measured violations.

  4. Add the stream designation to the letter and send it to the provider.

What goes into the prompt. For each violation: the clause of the standard, the measured value, the threshold and the impact on the receiving decoder; in addition, the observation window and the multiplex mode (CBR, VBR or undetermined). About the source, the prompt gets only the address of the active input, sanitised by the node:

  • without the login and password in the address;

  • without query parameters that look like a password, key, token or signature;

  • without the RTMP stream name.

For a source that does not arrive over the network (a file, another stream of the node, a transcoder, DVB), <not available> appears instead of the address. The stream name, its identifier and its note do not go into the prompt.

If the violation has already cleared. When the violation clears between the click on the icon and the node’s response (or the statistics have just been reset), the window stays open and shows this response as it is, and the “Copy prompt” button is unavailable. The node’s responses:

  • no active violation: nothing to send — there is no active violation;

  • AI complaint prompt is available only for SPTS streams — the stream is not SPTS;

  • no active input — the stream has no running active input;

  • AI complaint prompt requires the Admin role — the account does not have the Admin role.

The same prompt can be obtained over the node HTTP API (Managing the node over the HTTP API); the response is plain text, and a refusal is an error description in JSON:

GET /data/stream/<id>/ai-complaint-prompt