Why this matters

If you build anything that ingests, processes, or plays a transport stream — an OTT backend, an IPTV set-top app, a broadcast contribution link, an ad-insertion server — the PCR is the single value that decides whether playback is smooth or broken. A product manager needs to know the PCR exists so they understand why "just remux it" can silently destroy timing, and why broadcast engineers obsess over a number most file formats never expose. An engineer needs to know exactly how the PCR is encoded, how often it must appear, and how tightly it must hold, so they can read a stream analyzer report and tell a real fault from noise. This article gives both readers one model: the PCR is the heartbeat the whole broadcast clock is built on, and every PTS and DTS is meaningless without it.

The problem PCR solves: timestamps need a clock to be read against

Start with a fact that surprises people who learned timing on MP4 files. In a transport stream, the presentation timestamp (the PTS, the number that says "show this frame now") is not enough on its own. A PTS of 90,000 means "ninety thousand ticks after the clock's zero point" — but the decoder has no clock yet. It just received a packet over a satellite link or a cable feed; it has no idea what "now" is on the sender's timeline. A timestamp is a reading on a clock, and the decoder is missing the clock.

This is the gap the program clock reference fills. The encoder runs a master clock. Every so often it writes down the current reading of that clock and inserts it into the stream as a PCR. The decoder reads those readings, rebuilds a copy of the encoder's clock locally, and only then can it interpret the PTS and DTS values on every frame. The PCR is the shared reference; the PTS and DTS are positions measured against it. We covered how PTS and DTS work in PTS, DTS, and the Elementary Stream Timestamp — this article is the clock those two timestamps are read against.

Think of it like a clock on a factory wall. The workers (the PTS and DTS values) all say things like "ship this order at 3:00" and "start that batch at 3:05." Those instructions are useless to a new worker who has no watch. The wall clock is the PCR: the shared reference everyone sets their own watch to. Without it, every "3:00" is just a number with no meaning.

A diagram showing why a transport stream needs a program clock reference. On the left, a stream of packets carries PTS values like 90000 and 91920 with a question mark, captioned timestamps with no clock to read them against. In the centre, a PCR packet is highlighted carrying the encoder clock reading. On the right, the decoder has rebuilt a local clock and can now place each PTS on a timeline, captioned same timestamps, now meaningful. A label reads the PCR is the shared reference; PTS and DTS are positions measured against it. Figure 1. Why the PCR exists. PTS and DTS values are positions on a clock; the PCR is the clock itself, sent periodically so the decoder can rebuild it and read every other timestamp.

The 27 MHz master clock

Every program in a transport stream is timed by a master clock, and the standard fixes its rate. The clock ticks 27,000,000 times per second — 27 MHz. Every timing value in the stream descends from this one clock. The familiar 90 kHz clock that PTS and DTS use is not a separate clock at all; it is the 27 MHz master divided by exactly 300:

90 kHz clock = 27,000,000 ÷ 300 = 90,000 ticks per second

So why have a 27 MHz clock at all, if PTS and DTS only need 90 kHz? Two reasons. First, the finer resolution lets the decoder lock its clock far more precisely than 90 kHz steps would allow — one 27 MHz tick is about 37 nanoseconds, against 11 microseconds for a 90 kHz tick. Second, 27 MHz was chosen because analog colour television subcarriers can be synthesized cleanly from it, which mattered enormously when MPEG-2 was designed in the early 1990s and every decoder fed an analog display. The number is a bridge between the digital stream and the analog world it was born into.

The clock is not allowed to wander freely. The MPEG-2 systems standard requires the encoder's 27 MHz clock to stay within a narrow band: between 27,000,000 − 810 Hz and 27,000,000 + 810 Hz. That is ±30 parts per million (810 ÷ 27,000,000 = 0.00003). A clock allowed to drift wider than this would push the decoder's recovered clock out of range and cause the decoder's buffers to slowly fill or empty until playback breaks. Thirty parts per million is the budget; everything in the PCR machinery exists to keep the decoder inside it.

How the PCR number is built

The PCR is a single instant of the 27 MHz clock, but it is not stored as one plain number. It is split into two parts so that the coarse part lines up exactly with the 90 kHz PTS/DTS clock and the fine part captures the remainder. The full value is 42 data bits, carried inside a 48-bit field (the extra 6 bits are reserved padding).

The two parts are defined by simple arithmetic on the master clock reading. Let the master clock have counted t ticks at 27 MHz. Then:

PCR_base = (t ÷ 300) rounded down, then taken modulo 2^33
PCR_ext  = t modulo 300
PCR      = PCR_base × 300 + PCR_ext

The base is the reading expressed in 90 kHz units — it is the same clock domain the PTS and DTS live in, which is exactly why they can be compared directly. It is 33 bits wide, the same as a PTS. The extension is the leftover count of 27 MHz ticks since the last 90 kHz step, a number from 0 to 299, stored in 9 bits (9 bits hold 0–511, comfortably covering 0–299). Put the two together and you recover the full 27 MHz reading to single-tick precision.

A worked example makes the split concrete. Suppose the encoder's master clock has ticked exactly 27,000,123 times — just past the one-second mark:

t        = 27,000,123 ticks at 27 MHz

PCR_base = (27,000,123 ÷ 300) rounded down
         = 90,000 (remainder 123)        → the 90 kHz reading: 1.000000 s

PCR_ext  = 27,000,123 modulo 300
         = 123                            → 123 extra 27 MHz ticks

reassembled PCR = 90,000 × 300 + 123 = 27,000,123   ✓ exact

The base says "one second," matching the 90 kHz PTS clock perfectly. The extension adds the 123 fine ticks the base could not express. The decoder needs both halves to lock its clock tightly; a base-only reading would be accurate to only 11 microseconds, and that is not enough to keep a broadcast steady over hours.

A two-panel diagram of how a PCR value is built. The left panel shows the 27 MHz master clock at the top, an arrow splitting downward into two boxes: a 33-bit PCR base labelled divide by 300, equals the 90 kHz clock, same domain as PTS and DTS, and a 9-bit PCR extension labelled remainder modulo 300, range 0 to 299, the fine 27 MHz part. A note reads 42 data bits total, carried in a 48-bit field with 6 reserved bits. The right panel is a worked example: master clock equals 27,000,123 ticks, PCR base equals 90,000 which is 1.000000 seconds, PCR extension equals 123, reassembled equals 90,000 times 300 plus 123 equals 27,000,123 exact. Figure 2. The PCR split into a 33-bit 90 kHz base and a 9-bit 27 MHz extension. The base aligns with PTS/DTS; the extension supplies the fine resolution the decoder needs to lock its clock.

Where the PCR rides, and how often

The PCR does not get its own packet type. It travels in the adaptation field — an optional extra header that a transport stream packet can carry ahead of its payload. A transport stream is a chain of fixed-size 188-byte packets, each tagged with a packet identifier (a PID) that says which stream it belongs to. One PID per program is nominated as the PCR-carrier (it is named in the program map table), and whenever a packet on that PID needs to deliver a clock reading, it sets a flag in its adaptation field and writes the 42-bit PCR there.

How often must this happen? The MPEG-2 systems standard sets the ceiling: successive PCRs for a program must arrive no more than 100 milliseconds apart. That is the loosest the standard allows. In practice the broadcast world tightens it: the DVB measurement guidelines (ETSI TR 101 290) expect PCRs at least every 40 milliseconds, and many encoders insert them more often still. The reason is straightforward — the decoder's clock-recovery loop corrects itself only when a fresh PCR arrives, so more frequent PCRs mean a tighter, more stable recovered clock. Too few PCRs and the decoder's clock drifts between readings; too many and you waste bandwidth on timing overhead. Forty to a hundred milliseconds is the band the industry settled on.

This is the first common mistake worth naming. When a tool re-multiplexes or re-times a transport stream — splicing in an advertisement, changing the bitrate, repackaging for a different distribution path — it must re-stamp the PCRs to match the new packet positions. The PCR's whole job is to say "this is the clock reading at the moment this packet leaves," so if the packet's position in time changes and the PCR does not, the value is now a lie. A surprising share of broadcast playout faults trace to a remux step that moved packets around but copied the old PCR values verbatim.

How the decoder rebuilds the clock

The decoder arrives with a free-running 27 MHz oscillator that is close to 27 MHz but not exact — every crystal is a little fast or a little slow. Its task is to nudge that oscillator until it matches the encoder's clock as closely as the incoming PCRs reveal it. The mechanism is a phase-locked loop, a PLL: a feedback circuit that compares two clocks and steers one toward the other.

The loop runs a simple cycle. When a PCR arrives, the decoder reads the encoder's clock value from it and compares it to its own local clock reading at that instant. If the local clock is ahead, the oscillator is running fast and the loop slows it slightly; if behind, the loop speeds it up. Each PCR is one correction. Over many PCRs the local clock converges on the encoder's clock and then tracks it, staying locked as long as fresh PCRs keep arriving. This recovered clock is the decoder's system time clock, the STC. Every PTS and DTS in the stream is read against this recovered STC: when the STC reaches a frame's PTS, that frame is presented.

The chain is worth stating plainly because it is the heart of the whole system. The encoder's master clock generates the PCRs. The PCRs let the decoder rebuild the same clock as its STC. The STC is what the PTS and DTS are compared against. Break the first link — jittery, late, or wrong PCRs — and every timestamp downstream becomes unreliable, even if the PTS and DTS values themselves are perfect.

A signal-flow diagram of decoder clock recovery. On the left, incoming transport stream packets feed a box labelled extract PCR. The extracted PCR value goes into a comparator alongside the decoder local clock; the difference, labelled phase error, drives a loop filter, which steers a voltage-controlled 27 MHz oscillator. The oscillator output loops back to the local clock and also feeds a box labelled recovered system time clock, STC. From the STC, an arrow points to a final box compare STC to each PTS and DTS, present frame when STC equals PTS. The whole loop is captioned a phase-locked loop steers the local clock onto the encoder clock, one PCR at a time. Figure 3. The decoder's phase-locked loop. Each PCR is one comparison; the loop steers the local 27 MHz oscillator until the recovered system time clock tracks the encoder, and every PTS/DTS is then read against that recovered clock.

PCR jitter, drift, and offset: when the heartbeat goes wrong

Because the decoder trusts the PCR completely, the quality of the PCR signal decides the quality of the recovered clock. Broadcast engineers measure three distinct ways a PCR stream can misbehave, and the DVB measurement guidelines (ETSI TR 101 290) define each one.

PCR accuracy, usually called jitter, is how far each individual PCR reading lands from where a perfectly steady clock would have placed it. The MPEG-2 standard expects the inserted PCR to be accurate to within ±500 nanoseconds. Jitter beyond that confuses the PLL: each correction the loop makes is based on a value that is slightly off, so the recovered clock wobbles instead of holding steady. The usual culprit is the network between encoder and decoder — packets that should arrive evenly spaced get bunched up and stretched out by switches and routers, so the PCR arrives at a different real-world moment than its value claims.

PCR drift rate is how fast the encoder's clock frequency itself is changing. A clock that slowly speeds up or slows down forces the decoder's PLL to chase a moving target. The DVB guidelines cap the rate of frequency change at 75 millihertz per second (about 2.77 parts per billion per second) — a deliberately tiny number, because a clock that drifts faster than this will eventually push the decoder out of its ±30 ppm tolerance band and break playback.

PCR frequency offset is a fixed error: the encoder's clock simply running at, say, 27,000,400 Hz instead of 27,000,000. As long as the offset stays inside the ±810 Hz (±30 ppm) window the standard allows, the decoder can lock to it. Push past that window and the decoder cannot follow, and its buffers begin the slow slide toward overflow or underflow.

The visible symptoms follow directly from the cause. A buffer that slowly fills because the decoder clock runs slower than the stream means the decoder eventually has to drop a frame to catch up — a periodic hitch. A buffer that slowly empties means the decoder runs dry and freezes for a moment. And a clock that is locked but jittery produces the most insidious fault of all: audio that drifts a few milliseconds away from the picture over many minutes, never enough to alarm in a quick check, plainly wrong by the end of a long program. When a viewer reports lip-sync that "gets worse the longer I watch," a PCR problem is the first place an experienced engineer looks. For what counts as perceptible drift, see What "In Sync" Means: ITU-R BT.1359, Lip-Sync Windows, Perceptibility.

Defect What it is Standard limit Typical symptom
PCR accuracy / jitter Each PCR lands off its ideal time ±500 ns (MPEG-2) Wobbly clock; intermittent micro-stutter
PCR drift rate Encoder clock frequency changing over time < 75 mHz/s (DVB TR 101 290) Slow lip-sync drift over a long program
PCR frequency offset Encoder clock at a fixed wrong rate Within ±810 Hz / ±30 ppm Buffer slowly fills or empties; periodic frame drop or freeze
PCR interval too long PCRs arrive too far apart ≤ 100 ms (MPEG-2); ≤ 40 ms (DVB) Loose, drifting recovered clock between readings

Table 1. The four ways a PCR stream goes wrong, the limit each one is held to, and what a viewer sees. A stream analyzer reports all four; the limits come from ISO/IEC 13818-1 and ETSI TR 101 290.

Why MPEG-TS — and therefore PCR — is still everywhere

It is fair to ask why a clock model designed in the early 1990s for satellite and cable still runs so much of the video world in 2026, when newer container and transport designs exist. The answer is that the transport stream was built for hostile, one-way channels, and that design still has no equal where the link is unreliable and there is no back-channel to ask for a retransmission.

A transport stream is a chain of small, fixed 188-byte packets, each independently decodable and each able to carry its own timing. If a satellite hiccup or a noisy cable corrupts one packet, the rest of the stream is unaffected — the decoder resynchronizes on the next packet's sync byte and carries on. Forward error correction is layered on top (DVB adds 16 bytes of correction per packet, ATSC adds 20), so many corrupted packets are repaired before the decoder ever sees them. This resilience is exactly what broadcast and professional contribution links — the feeds that carry live content from a venue back to a studio — need, and it is why MPEG-TS, with the PCR at its core, remains the default there. File formats like MP4 optimize for storage and random access on reliable media; the transport stream optimizes for surviving a bad channel in real time. Different jobs, different designs. The container details across both worlds are covered in Audio in Containers: How MP4, MKV, fMP4, MPEG-TS Carry Audio.

There is one more reason the PCR endures: HLS, the streaming protocol that delivers a large share of internet video, originally chopped its media into short MPEG-TS segments — each one a miniature transport stream with its own PCR. Even as HLS moves toward the fragmented-MP4 packaging shared with DASH, an enormous installed base of TS-segment HLS is still in service, and every one of those segments carries the same 27 MHz clock model this article describes.

A worked example: diagnosing a slow drift

Put the pieces together with a realistic fault. A monitoring station reports that a channel's audio is 40 milliseconds behind the video after two hours, though it started in sync. The PTS and DTS values look clean. Where is the bug?

Symptom    : audio 40 ms late after 2 hours; in sync at the start
Drift rate : 40 ms ÷ 2 hours = 40 ms ÷ 7,200 s ≈ 5.6 microseconds per second

As a clock-frequency error:
   5.6 µs/s ÷ 1 second = 5.6 ppm of clock offset

Within the ±30 ppm allowed? Yes — so the decoder stays locked,
   but a 5.6 ppm offset is enough to accumulate 40 ms over 2 hours.

The drift is small enough that the decoder never loses lock and never drops a frame, which is exactly why it passed a quick check. But a steady offset of a few parts per million, accumulating second after second, is the classic signature of a PCR frequency offset at the encoder — the master clock running slightly off 27 MHz — or of network jitter biasing the recovered clock in one direction. The fix is not in the PTS or DTS, which were never wrong; it is in the encoder's clock source or in a de-jittering buffer ahead of the decoder. The method is the lesson: convert the observed drift into a clock-frequency error, check it against the ±30 ppm budget, and you immediately know whether you are chasing a lock failure or a slow accumulation. That single calculation points to the right half of the pipeline.

Where Fora Soft fits in

We have built ingest, transcoding, recording, and playout features for OTT, IPTV, video surveillance, and broadcast-adjacent products since 2005, and PCR handling is where transport-stream pipelines quietly succeed or fail. The recurring real-world problem is rarely exotic: a service ingests a live MPEG-TS contribution feed, repackages it for delivery, and a remux step moves packets without re-stamping the PCRs — so a stream that was clean on arrival now drifts on the way out. When a client reports that a channel was in sync at the source but loses sync downstream, the PCR re-stamping stage is the first seam we inspect, because that is exactly where the broadcast clock can be silently broken and where a stream analyzer's PCR jitter and drift readings tell the whole story.

What to read next

Call to action

References

  1. ISO/IEC 13818-1:2022, "Information technology — Generic coding of moving pictures and associated audio information — Part 1: Systems" (MPEG-2 Systems). Defines the program clock reference, its 42-bit program_clock_reference_base (33 bits, 90 kHz) and program_clock_reference_extension (9 bits, 27 MHz) encoding, the formula PCR = PCR_base × 300 + PCR_ext, the 27 MHz system clock, the ±810 Hz (±30 ppm) tolerance, the 100 ms maximum PCR interval, and the carriage of PCR in the adaptation field. The controlling standard for all transport-stream timing. https://www.iso.org/standard/83239.html — Tier 1 (official ISO/IEC standard).
  2. ITU-T H.222.0 (2021), "Generic coding of moving pictures and associated audio information: Systems." The ITU-T twin text of ISO/IEC 13818-1; identical normative content for the PCR encoding, the 27 MHz / 90 kHz clock relationship, the system-clock tolerance, and the PCR-in-adaptation-field carriage. Used to confirm the paywalled ISO facts from a free source. https://www.itu.int/rec/T-REC-H.222.0 — Tier 1 (official ITU-T Recommendation; twin text to Ref. 1).
  3. ETSI TR 101 290 V1.4.1 (2020-06), "Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems." Defines the PCR measurement parameters — PCR accuracy (±500 ns), PCR drift rate (< 75 mHz/s = 2.77 ppb/s), PCR frequency offset, and the DVB-tightened PCR repetition interval (≤ 40 ms). The controlling document for how PCR quality is measured in broadcast. https://www.etsi.org/deliver/etsi_tr/101200_101299/101290/01.04.01_60/tr_101290v010401p.pdf — Tier 1 (official ETSI Technical Report).
  4. ITU-T H.262 / ISO/IEC 13818-2, "Generic coding of moving pictures and associated audio information: Video" (MPEG-2 Video). Context for the encoder/decoder buffer model (the T-STD) that PCR-recovered timing feeds; the buffer overflow/underflow failure modes referenced in the symptoms table. https://www.itu.int/rec/T-REC-H.262 — Tier 1 (official ITU-T Recommendation).
  5. ITU-T J.133 (2002), "Measurement methods for digital video signal quality parameters." ITU-T companion on PCR/clock-recovery measurement context, cross-checked against the DVB measurement guidelines for the jitter and drift definitions. https://www.itu.int/rec/T-REC-J.133 — Tier 1 (official ITU-T Recommendation).
  6. Tektronix, "A Guide to MPEG Fundamentals and Protocol Analysis" / PCR measurement primers. Vendor engineering documentation from a maker of broadcast stream analyzers; practitioner-grade explanation of PCR jitter, drift, and frequency-offset measurement and the visible symptoms. Used for the symptom-to-cause mapping, subordinate to Refs. 1 and 3 for any normative limit. https://www.tek.com — Tier 4 (vendor documentation; defers to the standards for normative values).
  7. Telestream, "PCR Measurements" primer. Vendor documentation from a broadcast-monitoring maker; corroborates the ±500 ns accuracy and the network-jitter-as-root-cause framing. Cross-checked against ETSI TR 101 290. https://www.telestream.net — Tier 4 (vendor documentation; subordinate to Ref. 3).
  8. ISO/IEC 14496-12:2022, "ISO base media file format" (ISOBMFF). Used only for the contrast in the "why MPEG-TS endures" section — the file-format timing model (per-track tables, no broadcast clock) that the transport stream's PCR model is compared against. https://www.iso.org/standard/83102.html — Tier 1 (official ISO/IEC standard).

Note on a corrected oversimplification: many online explainers describe the PCR as simply "the timestamp that keeps audio and video in sync," conflating it with the PTS/DTS. This article follows ISO/IEC 13818-1: the PCR is the clock reference, distinct from the presentation and decoding timestamps, which are positions read against the clock the PCR rebuilds. The "PCR keeps A/V in sync" framing is flagged as the most common conceptual error — the PCR keeps the decoder's clock in sync; the PTS/DTS then place frames on that clock.