Live video from a moving car, with 30x fewer breaks
We streamed a live camera from a car over two cellular connections and drove the same 2.2 km loop nine times: three laps with NanoPing, three each with SRT connection bonding at two settings. NanoPing’s picture broke 4 times. SRT’s broke 136 and 126 times.
Three laps each, added up
Every lap counts, with nothing trimmed or left out. On every line, a shorter bar is better.
The same loop, three very different drives
Each drawing is the 2.2 km loop the car drove, traced from its GPS. The colored stretches show where a viewer would have seen a frozen or garbled picture. SRT struggled on the same stretches lap after lap. NanoPing got through almost all of them.
A live picture can’t wait for late frames
To stay live, a video player waits a set time for each frame and then moves on. Here that limit is 300 ms. A frame that arrives later, or never, is a gap in the picture. NanoPing delivered almost every frame at the same steady moment, about 162 ms after the camera took it.
How many frames had arrived, by time after the camera took them
Three laps pooled per setting. A line that jumps up early and stays at the top is what live video needs. NanoPing’s rises straight up at about 162 ms. SRT at 270 ms can’t deliver anything before about 280 ms, right against the limit.
Why SRT can’t be tuned out of it
SRT has one main setting: how long the receiver holds each frame, so that lost pieces can be sent again in time. We tried two values.
- 160 ms, SRT’s own guideline. Less waiting left less time to recover, so 3.0% of frames came too late or not at all.
- 270 ms, the most the limit allows. Frames arrived right at the edge, so any hiccup pushed them over: 18.2% missed it.
SRT’s backup group keeps one connection on standby. NanoPing uses both connections at the same time, and still delivered almost every frame at about 162 ms.
One missing frame can spoil the next ten seconds
Video saves space by sending only what changed since earlier frames, and this stream starts from a fresh picture only every 10 seconds. So when a frame is missing, the picture stays garbled until the next fresh start. We replayed every stream through a strict player and compared each frame on screen with what the car sent.
Share of all frames that were not shown as sent
45 frames frozen and 433 garbled, out of 17,310.
509 frames frozen and 3,735 garbled, out of 16,307.
2,986 frames frozen and 1,804 garbled, out of 16,107.
How the test was run
A car carried a camera, a small computer and two cellular modems on different networks (TDC and Telenor). The computer streamed the camera live to a fixed server through the connection under test. The car drove the same 2.2 km loop for every lap, at about 40 km/h on average. Only the connection changed.
The stream
1080p video at 30 frames per second and 3 Mbit/s. Every frame carries the moment the camera took it, so the server knows exactly how long each one took to arrive. The car kept its own recording of what it sent, so every frame that reached the server could be checked against the original.
SRT connection bonding
srt-xtransmit (libsrt) with the two connections in a backup group: one carries the stream while the other stands by. Three laps with the receive delay at 160 ms, SRT's own guideline of four times the 40 ms round trip, and three at 270 ms, the most the 300 ms limit allows once travel time and a little headroom are set aside.
NanoPing
NanoPing’s bonded tunnel, using both connections at the same time rather than keeping one on standby, with a 160 ms jitter buffer. Three laps.
Keeping it fair
- The same car, camera, modems and road for all nine laps. Only the connection changed.
- Every lap is included. Nothing was trimmed or left out.
- SRT was tested at its own recommended setting and at the most the limit allows, so it is not judged on one setting alone.
- Scored the way a viewer sees it: every stream was replayed through a strict 300 ms player and each frame on screen was compared with what the car sent.
All figures
| NanoPing | SRT 160 ms | SRT 270 ms | |
|---|---|---|---|
| Frames in time | 99.8% | 97.0% | 81.8% |
| Frames in time, worst lap | 99.3% | 95.6% | 72.6% |
| Frames later than 300 ms | 14 | 467 | 2,913 |
| Frames that never arrived | 27 | 21 | 17 |
| Picture lost in total | 1.4 s | 16.3 s | 97.7 s |
| Breaks in the picture | 4 | 136 | 126 |
| Longest single break | 0.87 s | 0.83 s | 22.80 s |
| Frozen frames (replay) | 45 | 509 | 2,986 |
| Garbled frames (replay) | 433 | 3,735 | 1,804 |
| Average latency | 162 ms | 193 ms | 296 ms |
| 99th percentile latency | 165 ms | 350 ms | 354 ms |
| Frame slots (received + lost) | 17,310 | 16,307 | 16,107 |
Three laps pooled per setting. Latency is camera capture to arrival at the receiving application, encoding included. A frame is in time if it arrived within 300 ms. A break is a run of consecutive frames that were late or never arrived. Frozen and garbled counts come from replaying each stream with the 300 ms limit enforced and comparing every shown frame with the car's own recording.
Driven in September 2026. SRT (Secure Reliable Transport) is an open-source protocol originally developed by Haivision. NanoPing is not affiliated with, endorsed by, or sponsored by Haivision or the SRT Alliance. Results reflect the specific implementation (srt-xtransmit / libsrt), configuration and test conditions described on this page and should not be interpreted as representative of all SRT deployments.
Reliable real-time connectivity in just a few steps
Every signup includes 30 days of full Pro access, no credit card. Spin up NanoPing on your device in just two commands and watch your traffic become reliable and stable right away.