Lab / / benchmark
433 frames versus 51, same seed
The same fifteen seconds over a 5% lossy link, twice, same seed: 433 frames / 29 fps / 0 freezes with RFC 4588 RTX against 51 frames / 15 fps / 5 freezes without.
WebRTC, Controls, CorrectnessKeryx- Machine
- UNKNOWN — the client was headless Chrome 151
- Commit
- `cacb70c`, 2026-08-25
- Frames decoded, with RFC 4588 RTX
- 433
- Rate, with RTX
- 29 fps
- Freezes, with RTX
- 0
- Packets accepted back, with RTX
- 79 of 80 destroyed
- Frames decoded, without
- 51
- Rate, without
- 15 fps
- Freezes, without
- 5
The same fifteen seconds runs twice across a 5% lossy link, at the same seed, with the same content and the same duration. One variable: whether RFC 4588 retransmission is on.
| Arm | Frames decoded | Rate | Freezes | Repairs |
|---|---|---|---|---|
| with RFC 4588 RTX | 433 | 29 fps | 0 | 79 of 80 destroyed packets accepted back |
| without | 51 | 15 fps | 5 | — |
**Environment.** Headless Chrome 151 as the client; Keryx as the server; H.264 at 640×360; a 5% lossy link; same seed, same content, same duration for both arms. Machine: UNKNOWN.
**Methodology.** A second session running the same fifteen seconds twice with one variable changed, which the source calls a properly matched A/B. Higher is better for frames decoded and rate; lower is better for freezes.
The 8.5× on decoded frames is the more striking number, and the freeze count is the more useful one. Frames decoded depends on how fast the link recovers; zero freezes against five is what the viewer sees.
The oracle is a browser
The same harness also has Chrome answer a Keryx offer over HTTP signalling: ICE connects, DTLS completes with Keryx as server using `SRTP_AES128_CM_HMAC_SHA1_80`, and Chrome decodes and renders the H.264 — 60+ frames at 640×360, keyframes counted, the video element playing, both data channels echoing. That is worth more than any test I could write myself, because it is the client that has to work.