demo · v135

Jitter budget — the use case for capture/receive timestamps

Why the encoded-frame timestamps matter for real apps: an end-to-end media tester needs to know how much of the glass-to-glass latency is in capture, in network transit, in jitter buffer, and in render. Pre-135, all the encoded-transform middleware saw was the RTP timestamp — useless without a wall-clock anchor. The new captureTime and receiveTime properties on RTCEncodedVideoFrame.metadata let you slice the budget. Simulator below feeds synthetic frames through; the chart updates in real time.

RTCEncodedVideoFrame: ?
capture → encode
—
ms
encode → receive
—
ms
receive → render
—
ms

the code

const tr = new RTCRtpScriptTransform(worker, { side: "receiver" });
receiver.transform = tr;

// In the worker:
self.onrtctransform = (e) => {
  const reader = e.transformer.readable.getReader();
  while (true) {
    const { value: frame, done } = await reader.read();
    if (done) break;
    const { captureTime, receiveTime } = frame.metadata; // NEW in 135
    histogram.push(receiveTime - captureTime);
    writer.write(frame);
  }
};

see also