Understand where delay comes from
End-to-end delay includes camera capture, decoding, scaling, encoding, network transport and receiving/playback. A single low CPU reading or a low ping is not a complete latency measurement.
When delay grows as a stream runs, something is falling behind or buffering too much. A smaller fixed delay and a delay that keeps increasing are different problems; report which one you observe.
Tune in a useful order
- Establish a local baseline. Test one camera over the local network with the intended receiver.
- Choose a sustainable resolution. Avoid an encoding load that cannot keep up with the camera, especially for software H.265 on Pi 5.
- Set a bitrate with network headroom. Mobile uplink varies; the selected video rate is only part of the total traffic.
- Test the remote path. Compare direct and relayed VPN connections where available, and observe real playback rather than relying only on signal bars.
- Adjust receiver buffering deliberately. A larger jitter buffer can absorb variation but adds delay. A smaller one may expose more interruptions on an unstable link.
H.264 or H.265?
H.264 is a practical choice for broad receiver compatibility. H.265 can retain more detail at a constrained bitrate, depending on the content and encoder, but needs a compatible receiver. On Radxa, both codecs use the hardware encoding path. On Pi 5, Pocket H.265 is software and has a lower configured resolution limit.
The bitrate controls in this release are manual. Do not expect automatic adaptive bitrate to follow LTE signal changes; that is not an enabled feature of the current program.
Interpret traffic correctly
Video bitrate is expressed in bits per second. One megabit per second is not one megabyte per second. Interface traffic can include video transport, VPN traffic, telemetry, other connections and packet retransmissions, so it need not equal the encoder target.
Browser playback
Watch the supported selected source in Cockpit while operating it from Cockpit or its matching dedicated camera tab. Pocket provides its own live-view panel. When you compare latency, keep the same camera, codec and receiving path so that a destination change is not mistaken for a change in encoding performance.
Use a current browser with decoding support for the selected codec. H.265 support depends on browser, operating system and available decoding components. H.264 is the first compatibility test if H.265 does not display.
Picture-in-Picture and fullscreen behaviour are controlled partly by the browser and desktop compositor. They change the viewing layout; they do not select a different physical camera or stop its stream.
Mobile uplink and data usage
Practical UAS test
Measure upload and latency with the actual cameras streaming, in the intended area and at busy times. Keep the combined stream rates comfortably below the stable available uplink, leaving room for telemetry, VPN/protocol overhead and retransmissions.
Two 2 Mbps streams already need about 4 Mbps of video payload, before overhead. A modem advertised as “150 Mbps” is normally quoting a theoretical download peak, not guaranteed upload at your location.
Signal and continuity
Use the modem's available RSRP, RSRQ and SINR readings together with measured performance. More bars alone do not prove less congestion or lower latency. Low bands can help coverage; a less-loaded mid-band cell may perform better. GSMA coverage/capacity analysis ↗.
If delay grows while sending video, reduce the total bitrate and retest. Automatic band selection is the sensible starting point; do not lock one band solely because its signal is stronger.
Data-plan estimate, video only:
- 1 Mbps ≈ 0.45 GB/hour
- 2 Mbps ≈ 0.90 GB/hour
- 3 Mbps ≈ 1.35 GB/hour
Real usage is higher with overhead or multiple streams. These are decimal-GB calculations, not a modem performance promise.