RTMP vs. SRT vs. WebRTC: Choosing the Right First-Mile Ingest for Live Camera Feeds

Every live broadcast begins with a single critical decision: how does the camera’s encoded video reach the transcoding infrastructure? This “first mile” of the streaming pipeline is where most quality is lost or preserved. Pick the wrong ingest protocol and no amount of downstream CDN optimization can recover from packet loss, jitter-induced frame drops, or accumulated latency.

After benchmarking all three major ingest paths across hotel Wi-Fi, 4G/5G cellular bonding, and wired gigabit uplinks, here’s what actually matters in production.

Protocol Benchmarks Under Real Network Conditions

Protocol	Avg. Latency (Glass-to-Glass)	Packet Loss Tolerance	Firewall Traversal	Hardware Encoder Support
RTMP (TCP)	2 – 5 s	Poor (head-of-line blocking)	Moderate	Universal — every encoder ships it
RTMPS (TCP+TLS)	2 – 5 s	Poor	Excellent (port 443)	Universal
SRT (UDP+ARQ)	0.5 – 1.5 s	Excellent (selective retransmit)	Good	Growing — OBS, vMix, hardware encoders
WebRTC (UDP+SRTP)	< 300 ms	Good (FEC + NACK)	Excellent	Browser-native, WHIP/WHEP endpoints

RTMP: The Legacy Workhorse

RTMP remains the default because every encoder from a $40 capture dongle to a broadcast-grade hardware appliance supports it. But its TCP foundation is its weakness: a single lost packet stalls the entire stream until retransmission arrives. On congested Wi-Fi with just 1–2% packet loss, RTMP streams develop visible artifacting and keyframe corruption.

“On any uplink with more than 0.5% packet loss, RTMP is no longer a viable professional ingest — SRT’s ARQ window absorbs the loss invisibly.”

SRT: Broadcast-Grade Contribution

Secure Reliable Transport retransmits only lost packets over UDP with a configurable latency window. At a 300ms latency budget, SRT sustains clean video over uplinks where RTMP completely falls apart. This is why SRT has become the de-facto standard for remote contribution — news crews, sports wire feeds, and bonded cellular backpacks all run it.

WebRTC/WHIP: Sub-Second Interactivity

WebRTC ingest via the WHIP standard gives browser-based broadcasters and mobile encoders glass-to-glass times under 300ms — essential for interactive formats like live auctions, co-streaming, and remote production with real-time direction.

// WHIP ingest negotiation — browser to edge media server
async function startWHIPIngest(endpoint: string, stream: MediaStream) {
  const pc = new RTCPeerConnection({ iceServers: [] });
  stream.getTracks().forEach(t => pc.addTrack(t, stream));

  const offer = await pc.createOffer();
  await pc.setLocalDescription(offer);

  const res = await fetch(endpoint, {
    method: 'POST',
    headers: { 'Content-Type': 'application/sdp' },
    body: offer.sdp,
  });
  await pc.setRemoteDescription({ type: 'answer', sdp: await res.text() });
}

Practical Recommendation

Run SRT or WHIP for ingest, then transcode at the edge into LL-HLS or DASH for scale-out delivery. Our full test matrix with packet-loss injection curves is published in the live camera ingest protocol benchmarks section — including the crossover point where SRT’s latency overhead actually beats RTMP’s stall behavior.