Mobile Uplink Packet Flow Lab

Remote phone video from a moving Starlink plus 5G uplink is usually limited by loss, jitter, and short outages before it is limited by raw upload speed. This model separates single-link, unmanaged dual-link, and purpose-built bonded service behavior, then shows why buffered SRT, RTMP, or chunked/WebCodecs modes trade delay for cleaner recovery.

How to use: pick a transport (top row) and a network path (second row), then drag the sliders to see how loss, jitter, and frame size change the picture. The numbers are an illustrative model to show tradeoffs, not measured results.

Plain WebRTC

Live bitrate2.9 Mbps

Glass-to-glass delay0.35 s

Recovery waitkeyframe

Frame damagevisible

Video packet Keyframe Sent via 5G × Dropped packet Recovered packet

Tree cover 35%

Starlink jitter 45 ms

5G strength 65%

Encoder target 3.0 Mbps

Plain WebRTC

WebRTC is best when latency matters. It reacts fast to packet loss, but that means tree-cover dropouts or path jitter can make the encoder slash bitrate even when average bandwidth looks high.

What Is Happening

H.264 frames are split into RTP packets. Missing packets can corrupt part of a frame or force a keyframe request.
Lower bitrate is more loss-tolerant because each compressed frame is smaller. Lost data can be retried faster, and a recovery keyframe is smaller.
&q=0 is 1080p/high quality. That creates larger H.264 frames, so one loss can take longer to repair and may need a new keyframe before the picture is clean again.
WebRTC congestion control treats loss and delay as congestion, so it often reduces bitrate before a user sees the full available upload speed.
Starlink and cellular often have different latency and jitter. Sending packets across both paths without a service that reorders, buffers, and de-duplicates them can make packet timing worse for VDO.Ninja.
Speedify or a Peplink-style bonded service can hide short path failures by spreading or duplicating packets, but it needs to be designed for real-time traffic and cannot remove obstruction gaps from Starlink itself.
More frequent keyframes, requested from the viewer/OBS link with &keyframe=2000, are a recovery option for lingering damage, but they increase bandwidth. With a weak link, that extra bandwidth can make loss worse, so they are not a default setting.
A large WebRTC receive buffer can give a keyframe time to arrive, but WebRTC is not built around large contribution buffers. Chunked mode can use bigger buffers more naturally.
RTMP does not repair frames like chunked mode; it uses reliable ordered delivery, so playback blocks until the missing data arrives.
SRT, RTMP, and VDO.Ninja chunked/WebCodecs improve quality by allowing buffering, retransmission, ordered delivery, or repair. The cost is latency.
VDO.Ninja chunked mode is a JavaScript-powered P2P adaptive path. It is cruder than a dedicated contribution protocol, but it can do custom recovery and buffering behavior that normal browser WebRTC media tracks do not expose.

Options To Test

Lower-bitrate WebRTC option

720p or modest 1080p at 30 fps keeps frames smaller, making packet loss and keyframe recovery less painful than 1080p at 7 Mbps.

Push:
https://vdo.ninja/?push=REMOTE_ID&q=1&codec=h264&h264profile&outboundvideobitrate=3000&maxframerate=30

OBS:
https://vdo.ninja/?view=REMOTE_ID&buffer=3000&bitrate=3000

1080p WebRTC option

&q=0 is 1080p. Use this only when packet loss is low enough that larger H.264 frames and recovery keyframes are not constantly being damaged.

Push test:
https://vdo.ninja/?push=REMOTE_ID&q=0&codec=h264&h264profile&outboundvideobitrate=4500&maxframerate=30&nomobilebitratecap

OBS test:
https://vdo.ninja/?view=REMOTE_ID&buffer=3000&bitrate=4500

Chunked/WebCodecs option

Chunked mode can add FEC/NACK-style recovery and explicit playout buffering in JavaScript. It can tolerate larger buffers than plain WebRTC media, but it is still experimental.

Push:
https://vdo.ninja/?push=REMOTE_ID&q=1&chunked=1800&chunkprofile=balanced&outboundvideobitrate=1800

OBS:
https://vdo.ninja/?view=REMOTE_ID&chunkbuffer=3000

SRT or RTMP relay option

If OBS is only forwarding to multistream and a few seconds of latency is acceptable, app.meshcast.io with SRT or RTMP is the buffered contribution-path option.

SRT target:
720p30 to 1080p30, H.264, 2500-4500 Kbps, 2s keyframes, latency 2000-6000 ms

RTMP target:
H.264 + AAC, CBR-like, 2s keyframes, 3000-5000 Kbps, expect more delay

Keyframe interval option (targeted fix)

WebRTC already requests a keyframe automatically when it detects loss, so do not set this by default. Use it only if damage lingers for seconds after a dropout. &keyframe is a viewer-side option: the OBS/view link asks the remote phone to send keyframes at that interval. A keyframe is the largest frame type, so forcing them often spends bandwidth and can make a weak uplink worse. Start at 2000; drop to 1000 only if 2000 is too slow and the bond has headroom. Under ~1000 ms quality drops steeply.

OBS (keyframe request goes here):
https://vdo.ninja/?view=REMOTE_ID&bitrate=3000&buffer=1000&keyframe=2000

Practical Takeaway

For this specific moving Starlink Roam plus 5G case, do not optimize for maximum advertised upload first. Optimize for fewer visible losses: 30 fps, bitrate headroom, 3 seconds of receive buffer, a real bonded service when using Starlink plus cellular together, and a fallback SRT/RTMP relay path.

Source Notes

Starlink specifications list typical upload and latency ranges; obstruction support docs point users to the app obstruction checker.
Speedify Bonding Mode describes streaming traffic prioritization and switching between bonding and redundancy.
Speedify Enhance Streaming describes automatic audio/video stream detection and priority handling.
AWS IVS encoder guidance documents RTMP/RTMPS/SRT ingest, CBR guidance, 2-second keyframes, and bandwidth headroom.
Local VDO.Ninja source confirms `&q`, `&outboundvideobitrate`, `&buffer`, `&keyframe`, chunked profiles, and `&nomobilebitratecap` handling in `main.js` and `webrtc.js`.