PCR Clock Drift Troubleshooting Guide

what is pcr? pcr (program clock reference) keeps time for broadcast streams, similar to a metronome built into your video stream the encoder taps out a beat as it creates the stream, and every device downstream relies on this timing to stay in sync technically, the pcr is a timestamp embedded inside specific packets in the mpeg ts stream the industry standard (etsi tr 101 290) determines that these timestamps must arrive at least every 100ms (ideally every 40ms or less) why does it matter? if that beat strays off time or out of sync, downstream devices get confused about how fast to play back the stream even if every single packet arrives perfectly with zero data loss, a bad pcr can still cause freeze frames, audio dropouts, macroblocking, or a decoder that gives up and resets what is pcr clock drift? pcr drift is what happens when the metronome is no longer keeping steady time instead of ticking at a stable rate, it speeds up/slows down/hiccups/jumps unpredictably the key measurements to be aware of from tr 101 290 are metric priority level what it means pcr interval p1 timestamps must arrive at least every 100ms pcr accuracy p2 each timestamp must be within ±500ns of when it was actually sent pcr jitter p2 timestamps shouldn't vary wildly from one packet to the next pcr discontinuity p1 sudden jumps in the timestamp must be flagged so decoders know to expect them drift vs discontinuity a discontinuity is a deliberate, flagged jump e g at a splice point drift is a slow, unflagged creep away from the correct clock rate decoders aren't warned about drift, which is what makes it harmful common causes 1 1 the encoder's clock isn't locked to a stable reference this is the most common cause an encoder needs a reliable external time reference such as gps, ptp/ieee 1588, or house sync to keep its internal clock accurate without it, the clock will wander this is especially common with software encoders running on regular computers, where other processes competing for cpu time can throw off timing precision hardware encoders that have lost their external reference signal any encoder that has been running for a long time without a reference even good internal clocks drift over hours 1 2 network jitter being mistaken for clock drift pcr timestamps are written at the encoder, but they have to travel across a network to reach the decoder if the network introduces variable delay (jitter), those timestamp carrying packets arrive at irregular times the decoder sees the timestamps arriving unevenly and registers pcr errors even though the encoder's clock was perfectly fine there is an important distinction with pcr packets network jitter → pcr packets arrive unevenly encoder clock issues → the pcr values themselves are wrong both look identical in a stream analyzer as tr 101 p2 errors, so you need deeper analysis to find which one you're dealing with 1 3 remultiplexing or transcoding without updating the timestamps when a device re multiplexes a stream (changing pids, adding or removing streams, or adjusting the bitrate) it needs to regenerate the pcr timestamps to reflect the new stream timing if it just passes the original timestamps through unchanged, they'll no longer be accurate for the modified stream this is a common problem in multi hop contribution chains 1 4 cbr stuffing done incorrectly when a variable bitrate stream is shaped to a fixed (cbr constant bitrate) output, the device adds null packets to fill the gaps if this process doesn't also correctly pace the pcr timestamps, the output clock will be wrong even if the bitrate looks right 1 5 buffering without restamping any device that buffers the stream (a gateway, a time shift server, a cloud ingest point) delays delivery of the packets if it doesn't update the pcr timestamps on the way out, the downstream device receives timestamps that describe the past rather than the present well implemented gateways (including zixi broadcaster) handle this correctly, but not all devices do 1 6 multi hop encode/decode chains every time a stream is decoded and re encoded, there's a chance timing accuracy is degraded in chains with multiple transcode hops, these small errors can compound the further downstream you go from the original encoder, the more likely pcr accuracy has drifted how it shows up downstream the impact depends on how bad the drift is and how tolerant the receiving device is drift severity what you'll typically see minor (within p2 limits) no visible picture issues; p2 warnings in a stream analyzer only moderate (exceeds p2, within p1) occasional freeze frames, audio glitches, or brief stalls severe (exceeds p1 or large jumps) repeated decode failures; irds reset or re acquire; audio or video drops out entirely unflagged discontinuity decoder locks up or produces garbled output until it re syncs different devices have very different tolerances vlc on a laptop might play back a drifting stream without any visible issues, while a professional ird on the same stream will throw alarms and attempt to relock a stream that looks fine on a preview monitor may still be causing problems further down the chain how to diagnose & troubleshoot pcr clock drift step 1 capture and analyze the stream use a stream analyzer (tsreader, wireshark, elecard streameye, tektronix sentry, pixelmetrix dvstation etc) check for pcr interval violations gaps of more than 100ms between pcr packets (p1 error) pcr accuracy errors timestamp values deviating beyond ±500ns (p2 error) pcr jitter large swings between consecutive timestamps unflagged discontinuities sudden pcr jumps with no discontinuity indicator set step 2 work out where it's coming from capture at two points as close to the encoder as possible , and at the receiving end compare errors at the encoder output → the encoder clock is the problem errors absent at the encoder but present at the receiving end → network jitter, or an intermediate device is introducing drift errors appearing after a specific device → that device is the likely culprit step 3 check the encoder's reference clock on the encoder, check and confirm is it locked to an external reference (gps, ptp, house sync)? what does the reference lock indicator say? has it been running for a long time without a reference? for software encoders was cpu load high around the time errors appeared? step 4 check whether intermediate devices are restamping pcr for each device after the encoder (multiplexers, gateways, transcoders) confirm whether it regenerates pcr timestamps on output any device that is known to pass timestamps through unchanged is a risk point if it modifies the stream in any way step 5 look at the error trend over time a single snapshot of p2 errors can provide misleading information check how error counts change over time errors gradually accumulating over hours → slow oscillator drift; check reference lock errors appearing in bursts at regular intervals → likely a scheduling or processing issue errors correlated with network events → jitter induced pcr arrival problems, not encoder clock issues common fixes root cause fix encoder not locked to a reference lock to gps, ptp (ieee 1588), or house sync software encoder on a busy cpu reduce cpu load; use a dedicated encoding host; consider hardware encoding for critical paths multiplexer not regenerating pcr enable pcr restamping in the mux configuration, or replace it with a device that does network jitter causing timestamp arrival problems apply qos or use a dedicated path; add a jitter buffer or pcr smoother at the receive end transcoder passing through old timestamps enable pcr regeneration on the transcoder output too many encode/decode hops reduce transcode hops; use baseband or lossless contribution for upstream legs where possible unflagged discontinuity from an upstream source fix flagging at the encoder or mux; if the source is out of your control, insert a pcr restamper at ingest pcr drift in zixi workflows zixi broadcaster transports the stream exactly as it receives it, it does not modify pcr values in transit this means zixi is not a source of pcr drift it carries whatever is in the stream, good or bad if errors are present on the input, they will be present on the output for passthrough outputs (udp, zixi push/pull), the stream is delivered as received for hls and adaptive outputs, zixi will regenerate timing if tr 101 pcr errors are showing up on a source in zen master, start your investigation at the encoder feeding that source, not at the broadcaster or zen master itself troubleshooting decision tree pcr errors reported on stream p1 error pcr interval >100ms? → yes → capture at encoder output and check every mux in the chain p2 error pcr accuracy violation? → yes → capture at encoder output to determine encoder side vs network side errors correlated with network events? → yes → pcr arrival jitter — check path quality and jitter metrics errors appearing after a specific device? → yes → that device is not regenerating pcr correctly check pcr restamp settings encoder reference lock indicator showing a fault? → yes → lock encoder to gps, ptp, or house sync errors on a software encoder under load? → yes → reduce cpu load or move to hardware encoding errors accumulating gradually over hours? → yes → oscillator drift check and restore encoder reference lock unflagged pcr discontinuity jumps? → yes → fix at encoder or insert a pcr restamper at ingest no clear cause found → capture ts at encoder output and at receive point and escalate to zixi support escalation checklist when escalating to zixi support, include the following broadcaster version and os stream name and connection type (push/pull, protocol used) tr 101 290 error type (p1/p2) and error counts over time stream analyser output or screenshots showing pcr metrics network path description (public internet, dedicated circuit, cloud region, etc ) encoder make, model, and firmware version encoder reference clock source and current lock status whether errors are present at encoder output or only at receive point any recent changes to encoder, mux, network, or broadcaster configuration ts capture at encoder output and/or broadcaster input (wireshark pcap or tsreader analysis)