Jitter Buffer Integration in NanoPing Transport
Most video players use a jitter buffer to smooth out network delays and avoid stuttering. It holds incoming frames and delivers them to the decoder at a fixed interval (e.g. every 30 ms), which under normal conditions yields a smooth experience.
Why Move the Jitter Buffer into the Transport?
For real-time or low-latency scenarios (e.g. teleoperation, safety-critical systems), a standalone jitter buffer can actually waste precious milliseconds that would be better spent on packet repair. NanoPing’s solution is to integrate the jitter buffer logic directly into the transport protocol. This lets us:
-
Maintain smooth playout (same as a traditional jitter buffer)
-
Simultaneously repair lost packets before delivery
-
Honor a strict latency budget by discarding frames older than the deadline
NanoPing's Transport Raft
NanoPing's transport protocol Raft allows the in-transport jitter buffer via
the specifying the delivery_policy:
| Policy | Description |
|---|---|
| ON_TIMEOUT | Wait until timeout ms have elapsed, then deliver all received packets in order. Ensures playout sync even if some packets are missing. |
| ON_ORDERED | Deliver each packet immediately once any lower-sequence packets have arrived. Minimizes latency but may stall if packets are delayed. |
See also Raft Stream Configuration
Delivery Policy applies only to the stream where you set it—i.e. it controls how that endpoint emits or holds packets.
It does not propagate to the peer automatically; you must configure a policy on each side.
- Configure sender and receiver independently
- Mix-and-match policies (e.g.
ON_ORDEREDupstream,ON_TIMEOUTdownstream) - Full per-endpoint control over latency vs. in-order delivery
Example: H.264 Streaming over a Lossy Link
In this example we stream H.264 video via GStreamer over a network with:
-
Link latency: 50 ms
-
Packet-loss rate: ~5%
-
Latency budget: 300 ms (frames delayed beyond this are dropped)
| Clip | Behavior |
|---|---|
| Raw UDP | Choppy playback, no reordering or loss recovery |
| NanoPing (no jitter buffer) | Better loss recovery, but uneven playout |
| NanoPing (integrated jitter buffer) | Smooth, in-order playback and on-the-fly packet repair within the 300 ms deadline |