--- title: Streams analysis url: https://doc.pstreamer.tv/en/manual/stream_analyze.html lang: en product: Perfect Streamer version: 1.13.3.445 --- # Streams analysis The streams analyzer measures and analyzes various MPEG-TS stream parameters, which allows you to evaluate the quality. **Input speed** — stream rate (bitrate) in `kbps`. Measured after filtering by PCR marks. Shown as a graph that also displays the output bitrate after the synchroniser. **Raw data speed** — the data reception rate over the chosen protocol. **Overhead** — the percentage added for protocol overhead. **CC errors** — packet drops (CC, discontinuity). Per-interval counters and a cumulative counter over the stream uptime are displayed. A history graph is also shown. **Scrambled** — encoded MPEG-TS ES packets counter. If value is not 0, there are decoding issues in protected channels. **Sync by** — synchronization source — PCR. **PCR interval** — interval between PCR marks. Not more than 50 ms is recommended. **PCR jitter** — accuracy characteristic of output stream syncronization. Measured as the difference between PCR and real time. **Analyze PCR PMT Gap** — enabled by a dedicated setting. The skew between PCR and PTS/DTS is analyzed for each ES. The history is shown as a graph. An excessive skew may cause problems on players with a small synchronization buffer. The analysis is enabled by the **Analyze PAT/PMT/KF** setting. **PAT interval** and **PMT interval** — the interval between PAT (PMT) tables is measured. Recommended value is not more than 500 ms. The analysis is enabled by the **Analyze PAT/PMT/KF** setting. **Key Frame interval** (GOP interval) — the interval between key frames (GOP starts). For players that join the stream at random points, no more than 1 s is recommended. The analysis is enabled by the **Analyze PAT/PMT/KF** setting. **IDR interval** — the interval between IDR frames, which are true random-access points (*SPS / PPS / IDR*). It is shown only if the source broadcasts with IDR. If **IDR interval** roughly matches **Key Frame interval**, the stream has *closed-GOP*: every GOP opens with a full entry point, and the player can start from any segment. If the metric is absent, the stream is *open-GOP* without IDR — there are key frames, but they are not full entry points. This ratio makes the GOP-structure type of the source immediately visible. The analysis is enabled by the **Analyze PAT/PMT/KF** setting. **PAT/KF interval** — measures the mean interval between the start and end of the PAT/PMT/SPS/PPS/KF sequence. This determines the startup time of players that join the stream at random points. The interval is measured from the start of the KF in the stream, so the actual player startup time will be longer. The analysis is enabled by the **Analyze PAT/PMT/KF** setting. Enabling **Analyze PAT/PMT/KF** enables the flow analyzer in permanent mode, which leads to an increase in CPU load. # Jitter control There are several settings in the stream for jitter control: - **Jitter Compensation Delay (ms)** — network Jitter compensation function, buffer size is set. Extended function description: [https://forum.pstreamer.tv/viewtopic.php?t=25](https://forum.pstreamer.tv/viewtopic.php?t=25) - **Jitter Auto sync** — activates the value of 2000 ms for TCP-based protocols (HTTP, HLS), for UDP protocols the value remains the same — 500 ms. - **Limit PCR gap (ms)** — checks how much PCR can jump, if more, then resynchronization will occur. If *PCR Accuracy* errors appear after the transcoder, you need to set an even bitrate using *stuffing* for the encoded stream along the following path: “**input** — **transcoder** — **Align Total Bitrate**”. The speed must be set guaranteed higher than the bitrate of video and audio. # PCR drift The *PCR drift* metric measures the systematic deviation of the source clock frequency relative to real time and is expressed in *ppm* (parts-per-million). Unlike instantaneous *PCR jitter*, which captures the wobble of individual timestamps, *PCR drift* characterizes the long-term drift of the encoder crystal — a steady offset that accumulates over minutes and hours. Measurement is performed by linear regression over pairs (cumulative *PCR* time in seconds, arrival time in seconds). Measurement noise decays as `1/T^1.5` with growing window, so a reliable verdict is only possible over long intervals. The window automatically expands up to 300 *s* (the product’s acceptance window; the **TR 101 290** standard does not fix the observation interval), after which a sliding re-anchoring with a 6 *hours* limit is applied — this eliminates precision loss caused by `float64` mantissa overflow. The stream **XML** statistics export: - `pcr-drift-ppm` — current regression verdict; - `pcr-drift-window-s` — length of the window over which the verdict was computed; - `pcr-drift-samples` — number of points in the regression. The tolerance defined by **ISO/IEC 13818-1** §2.4.2.1 is ±30 *ppm*. On a sustained excess (see the alerts section below) a dedicated `pcr-drift-alert` attribute is set, and after 300 *seconds* of continuous violation — `pcr-drift-alert-acceptance` (acceptance level; the 300-second window is a product value, in the spirit of the long-term measurements of **TR 101 290**). Exposing *PCR drift* as a standalone attribute (rather than folding it into the shared `tr101290-alert`) is intentional: crystal drift is an upstream encoder problem, not a receiver problem, and the operator must see it separately, not mixed with transport-integrity errors. # PCR accuracy The *PCR accuracy* metric (section P2.3 of **TR 101 290**) measures the accuracy of *PCR* timestamp insertion into the transport stream. Per the specification, the value of every *PCR* must match the actual moment it passes through the multiplexer with an error no worse than ±500 *ns*. The measurement is taken as the *residual* of a linear regression over a sliding 30 *s* window. The window size is chosen to capture the full *PCR* repetition cycle (≤40 *ms* per spec) with ample margin, while still reacting quickly to a deterioration of insertion quality. The stream **XML** statistics export `pcr-accuracy-max-ns` — the peak residual value over the window. On excess beyond ±500 *ns* the `pcr-acc` token is added to the shared `tr101290-alert` attribute. The measurement is only meaningful for **CBR** multiplexes: in **VBR** the intervals between *PCR* may diverge from the estimated linear trend without violating the standard. The analyzer automatically disables the `pcr-acc` token for streams classified as *vbr* (see the section on the mode detector). # PCR drift compensator If the source *PCR drift* lies within the **ISO/IEC 13818-1** tolerance but is still non-zero, the output stream slowly “drifts away” relative to the receiver’s network time. On a player with a small buffer this manifests as an accumulating loss of synchronization or periodic playback hiccups. The compensator eliminates drift without a hard resync: outgoing packets are shifted by ~11.1 *µs* (the duration of a single 188-byte *TS* packet at 100 *Mbps*), and the decision of “whether a shift is needed” is taken from the actual difference between network time and the *PCR* pace. Hard resync (`Limit PCR gap`) remains as a fallback for stream breaks — the compensator operates on a finer scale and preserves continuity. Settings under **stream**: - *Sync Drift Compensation* — enables/disables the compensator. Enabled by default. - *Sync Drift Soft Window* — soft window within which corrections are applied one at a time (1–60000 *ms*, default 500). The upper bound is capped by `8 × Sync Disc Window`, beyond which a hard resync is deemed due. The **XML** statistics export `slew-adjust-count` — the count of corrections since `reset-stat`. A sharp increase in this counter means that the source has either exceeded its tolerance or has an unstable crystal. # T-STD video buffer analyzer The **T-STD** (*Target Decoder*) model is defined in **ISO/IEC 13818-1** §2.4.2. It is the reference receiver-buffer model: if it is honored, the stream is guaranteed to play on any compliant hardware decoder. The analyzer models the `MBn` buffer (the multiplex buffer for video) and verifies that: - the buffer does not overflow (overflow → the encoder is required to drop frames); - the buffer does not underflow (underflow → the decoder shows a freeze or artifacts). Enabled by the *Analyze T-STD video* setting (off by default — it adds CPU load in the hot processing path). Supported video ES types (`stream_type`): - `0x01` / `0x02` — MPEG-2 video, capacity 750 *KB*; - `0x10` — MPEG-4 part 2, capacity 750 *KB*; - `0x1B` — H.264 / AVC, capacity 3 *MB*; - `0x24` / `0x25` — HEVC, capacity 3.75 *MB*. The drain rate (*drain rate*) is adaptively tuned to the actual video bitrate: an exponentially weighted moving average (EMA) with `α=0.2` over a 5 *s* window is used. Without adaptation the model quickly produces false underflows on any *VBR* video. The buffer is drained by **PCR** ticks (90 *kHz*) rather than by host system time — this makes the analysis robust against OS pauses and CPU-load fluctuations. The host wallclock is used only to verify the drift compensator, never for T-STD. The **XML** statistics export: - `tstd-video-cap` — model capacity in bytes; - `tstd-video-drain-bps` — current adapted drain rate, *bytes/s*; - `tstd-video-overflows` — overflow counter since `reset-stat`; - `tstd-video-underflows` — underflow counter; - `tstd-video-max-fill` — peak fill in bytes. On any non-zero counter (`overflows > 0` or `underflows > 0`) the `tstd-video` token is added to the shared `tr101290-alert`. As with `pcr-acc`, the token applies only to **CBR** streams — for a **VBR** multiplex transient buffer dips are permissible. # Multiplex bitrate-mode detector A subset of the **TR 101 290** tests only makes sense in **CBR** mode (constant multiplex bitrate). To avoid issuing false alerts on **VBR** channels, the analyzer automatically determines the source mode and exports the verdict to the `bitrate-mode-detected` attribute. Algorithm: comparison of average bitrates over two windows — 5 *s* and 60 *s*. If the divergence exceeds 20 %, the stream is marked `vbr`; if it stays within, `cbr`. Until statistics accumulate (~70 *s* from start or `reset-stat`) the verdict is `unknown` and **CBR**-only tests (`pcr-acc`, `tstd-video`) are temporarily suppressed. Attribute values: - `cbr` — constant bitrate, all tests active; - `vbr` — variable bitrate, `pcr-acc` and `tstd-video` are disabled; - `unknown` — insufficient data, **CBR**-only tests are suspended. # TR 101 290 alerts The aggregate `tr101290-alert` attribute combines several **TR 101 290** compliance detectors. If at least one is firing at the current moment, the attribute carries a space-separated list of tokens; if none is firing, the attribute is absent from the **XML**. Possible tokens and their meaning: - `pcr-int` — exceeded interval between *PCR* (section 5.2.4 of **TR 101 290**, limit 40 *ms*, recommendation ≤25 *ms*); - `pcr-acc` — exceeded *PCR* insertion accuracy (section 5.2.5, ±500 *ns*, **CBR**-only); - `pcr-disc` — a hard resync on *PCR* was detected (section 5.2.4, `PCR_discontinuity_indicator_error`); - `pat-int` — exceeded *PAT* interval (section 5.1.3, limit 500 *ms*, requires *Analyze PAT/PMT/KF*); - `pmt-int` — exceeded *PMT* interval (section 5.1.5, limit 500 *ms*, requires *Analyze PAT/PMT/KF*); - `tstd-video` — an overflow or underflow of the **T-STD** model was detected (section 5.3.16, requires *Analyze T-STD video*, **CBR**-only). To prevent the indicator from flickering on short bursts, debounce logic is applied: a token reaches `tr101290-alert` only if it has been firing for at least 30 of the last 60 seconds. This is applied uniformly to every token. Additionally, `tr101290-alert-acceptance` is exported — a copy of the attribute in which a token only appears after 300 *seconds* of continuous violation (acceptance level; the interval is a product value, the **TR 101 290** standard does not specify it). It is the “final” aggregate metric for technical channel acceptance. The `pcr-drift` indication is intentionally split out into its own `pcr-drift-alert` (+ `pcr-drift-alert-acceptance`). Crystal drift is an upstream encoder problem; it is independent of transport integrity and must be classified separately. # AI complaint helper If a channel is raising *TR 101 290* or *PCR drift* alerts, the operator can obtain in a single request a ready-made English-language AI-chat prompt that will compose a formal complaint letter to the upstream stream provider. Endpoint: `GET /data/stream//ai-complaint-prompt`. Available with the *Viewer* role (as are all GET requests under `/data/*`). Returns `text/plain; charset=utf-8`. For **MPTS** a 404 is returned — *T-STD* / *PCR drift* metrics are only applicable to **SPTS**. The prompt is compatible with any modern AI chat: “ChatGPT”, “Claude”, “DeepSeek”, “Qwen”, “Doubao”. The tone of the letter is businesslike, without accusations; the end of the prompt offers a choice of language for the resulting document: English, Russian, Simplified Chinese, or any other language at the operator’s discretion. Contents of the prompt: - the stream name and its measured parameters; - the list of all active *TR 101 290* and *PCR drift* tokens with the corresponding standard references; - numerical values and thresholds; - the impact of each error on the decoder side. What does **not** go into the prompt: the stream name, ID, and source URI. These fields are replaced by the placeholder `` — the operator fills them in before sending, so that they do not leak to a third-party AI service.