Live-Stream Uplink Bandwidth — Methodology
· bundle 05
What this measures
Live-stream wire bytes consumed by a viewing process for the same 2688×1520 camera scene, delivered two ways:
- Path A — direct RTSP-TCP from camera:
ffmpeg -rtsp_transport tcp -allowed_media_types video -c copyagainst the camera's native RTSP endpoint. H.264 High Profile, ~10 fps declared. - Path B — FDC live via NVR: a live-stream client requests the same camera through the S-VIDIA NVR at the camera's native resolution and frame rate. The NVR delivers VComp packets — per-frame block-delta payloads of changed 8×8-pixel blocks.
The wire-byte counter is identical in both paths: per-process TCP bytes_in via macOS nettop -P -m tcp, snapshotted ~1 s before the consumer process exits while its sockets are still open. Both consumers start fresh per sample, so the snapshot equals the bytes consumed during the window.
Alternation and noise control
Two 120-second samples per path interleaved A-B-A-B (four samples total). With n=2 per path, the report shows mean and range; if the range exceeded 25% of the mean, the alternation would have detected scene drift and the result would be re-run rather than averaged blindly.
Results
| Path | N | Mean kbps | Range (min – max) | Range % | GB / cam / 24h |
|---|---|---|---|---|---|
| A · direct RTSP H.264 | 2 | 2,626 | 2,620 – 2,632 | 0.4% | 28.36 |
| B · FDC live via NVR | 2 | 1,425 | 1,288 – 1,561 | 19.2% | 15.39 |
FDC delivery used 45.7% less wire bandwidth than direct RTSP for this scene. Both range figures fall within the 25% scene-drift threshold; means are fair.
Caveats — do not bury
- Motion-% used in the bundle is from archive-frame-presence (a gap-scan of recorded archive frames), which is not the same as live-stream block churn. A static scene with imperceptible micro-motion can produce zero archive frames yet still churn enough 8×8 blocks on the live wire to register.
- Single-camera / single-window sample. A multi-camera multi-window follow-up is implied future work to capture day/night and seasonal variation.
- The S-VIDIA platform-wide 60% claim is for storage; the ~46% figure here is for live uplink. They are related (same codec block-delta property) but they are not the same number — do not present them as interchangeable.
- Capture path used a transcontinental VPN between the operator and the trailer's network. Sequential A-B-A-B captures avoid VPN-bottleneck contention;
nettopon the operator host measures user-space bytes consumed by the consumer process — independent of the VPN's encrypted-payload overhead, this is the inner flow's wire size that the trailer's LTE/5G uplink would carry.
Per-sample motion vs bandwidth
At n=2 per path, the sample-level numbers do not show the "more motion → more Path B bandwidth" pattern one would naively expect from FDC's block-delta property. The most plausible explanations are (in order): n=2 is too small to establish a trend; archive-frame-presence is not block churn; first-frame sync overhead in the live consumer dominates at 120 s windows. A publishable bandwidth-vs-motion scatter requires n≥4 per path across quiet and active windows.