NDI · SRT · RTMP Bandwidth
Requirements — Complete Reference 2026
The definitive bandwidth and bitrate reference for IP video professionals. Full NDI, NDI HX3, NDI HX2, NDI HX, SRT (H.264 & H.265), RTMP, HLS and RTSP — every protocol, every resolution, every frame rate. Used by AV integrators, broadcast engineers and system designers worldwide.
01 Protocol Overview #protocols
Each protocol was designed for a different environment and bandwidth constraint. Understanding where each operates correctly prevents the most common bandwidth planning mistakes.
NDI — Network Device Interface
- Developed by NewTek — standard for professional LAN video production
- Full NDI: SpeedHQ intra-frame codec, 75–600 Mbps, lowest latency
- NDI HX3: H.265 up to 62 Mbps — approaches Full NDI quality
- NDI HX2: H.265 8–20 Mbps — monitoring and preview
- NDI HX: H.264 8–18 Mbps — widest device compatibility
- Requires Gigabit managed switch for Full NDI — never use over Wi-Fi
SRT — Secure Reliable Transport
- Open-source protocol by Haivision — designed for unreliable networks
- Built-in ARQ packet retransmission — recovers from 5–10% packet loss
- AES-128/256 encryption — mandatory for public internet delivery
- Caller and Listener modes — handles NAT traversal
- Add 25–30% bandwidth overhead above encoded bitrate
- Ideal for 4G/LTE, satellite, VPN and WAN contribution links
RTMP — Real-Time Messaging Protocol
- Adobe protocol from 2002 — ubiquitous for platform delivery
- No built-in error recovery — packet loss causes visible corruption
- H.264 only on most platforms — H.265 not universally supported
- Each platform sets its own maximum bitrate ceiling
- Use for final delivery to YouTube, Facebook, Twitch, TikTok
- Not recommended for contribution links — use SRT instead
02 NDI Bandwidth Requirements #ndi
Full NDI uses SpeedHQ intra-frame compression — every frame is independently compressed, giving the lowest latency and highest quality but the highest bandwidth requirement. NDI HX variants use inter-frame H.264/H.265 compression, dramatically reducing bandwidth at the cost of slightly higher latency and quality.
| Resolution | Frame rate | Colour space | Full NDI | NDI HX3 (H.265) | NDI HX2 (H.265) | NDI HX (H.264) |
|---|---|---|---|---|---|---|
| 720p | 30 fps | 4:2:2 8-bit | 30–50 Mbps | 6–12 Mbps | 4–8 Mbps | 4–7 Mbps |
| 720p | 60 fps | 4:2:2 8-bit | 40–75 Mbps | 10–20 Mbps | 6–10 Mbps | 5–8 Mbps |
| 1080p | 30 fps | 4:2:2 8-bit | 75–100 Mbps | 15–30 Mbps | 8–15 Mbps | 8–12 Mbps |
| 1080p | 60 fps | 4:2:2 8-bit | 125–200 Mbps | 30–50 Mbps | 12–20 Mbps | 12–18 Mbps |
| 1080p | 60 fps | 4:4:4 10-bit | 200–280 Mbps | 40–60 Mbps | N/A | N/A |
| 4K UHD | 30 fps | 4:2:2 8-bit | 250–400 Mbps | 40–62 Mbps | 20–35 Mbps | Not supported |
| 4K UHD | 60 fps | 4:2:2 8-bit | 400–600 Mbps | 50–62 Mbps | Not supported | Not supported |
| 4K DCI | 30 fps | 4:2:2 10-bit | 500–700 Mbps | 50–62 Mbps | Not supported | Not supported |
03 SRT Bandwidth Requirements #srt
SRT bandwidth is the sum of your encoded video bitrate plus an overhead allowance for packet retransmission. The recommended overhead is 25% for typical internet connections with up to 5% packet loss, and 40% for cellular or satellite links. Always provision your bandwidth for the worst expected network conditions, not the average.
| Resolution | Frame rate | H.264 encoded bitrate | H.265 encoded bitrate | SRT overhead (25%) | Total bandwidth — H.265 | Upload speed needed |
|---|---|---|---|---|---|---|
| 480p | 30 fps | 1.5–2 Mbps | 0.75–1 Mbps | +25% | ~1.3 Mbps | 2+ Mbps upload |
| 720p | 30 fps | 2.5–4 Mbps | 1.5–2.5 Mbps | +25% | ~3 Mbps | 4+ Mbps upload |
| 720p | 60 fps | 3.5–5 Mbps | 2–3 Mbps | +25% | ~3.8 Mbps | 5+ Mbps upload |
| 1080p | 30 fps | 4–6 Mbps | 2–4 Mbps | +25% | ~5 Mbps | 7+ Mbps upload |
| 1080p | 60 fps | 6–9 Mbps | 3–5 Mbps | +25% | ~6.3 Mbps | 9+ Mbps upload |
| 4K UHD | 30 fps | 15–25 Mbps | 8–15 Mbps | +25% | ~19 Mbps | 25+ Mbps upload |
| 4K UHD | 60 fps | 25–40 Mbps | 15–25 Mbps | +25% | ~31 Mbps | 42+ Mbps upload |
| 4G / LTE | Any | Keep encoded bitrate under 2 Mbps | +40% | ~2.8 Mbps | 5+ Mbps cellular | |
Standard internet (≤5% packet loss)
4G / cellular / satellite (≤10% loss)
SRT latency setting (rule of thumb)
Sustained upload available
04 RTMP Platform Bitrate Requirements #rtmp
Each streaming platform sets its own bitrate limits. Exceeding the maximum causes the platform to re-encode your stream, reducing quality. Below the minimum causes heavy compression artefacts. All figures are H.264 — H.265/HEVC is not widely supported for RTMP ingestion on consumer platforms as of 2026.
| Platform | Resolution | FPS | Min bitrate | Recommended | Maximum | Upload speed needed | Audio bitrate |
|---|---|---|---|---|---|---|---|
| YouTube | 4K / 2160p | 60 | 20 Mbps | 30–51 Mbps | 51 Mbps | 65+ Mbps | 128–320 Kbps AAC |
| YouTube | 4K / 2160p | 30 | 10 Mbps | 15–20 Mbps | 51 Mbps | 25+ Mbps | 128–320 Kbps AAC |
| YouTube | 1080p | 60 | 3 Mbps | 4.5–9 Mbps | 9 Mbps | 12+ Mbps | 128 Kbps AAC |
| YouTube | 1080p | 30 | 2 Mbps | 3–4.5 Mbps | 6 Mbps | 8+ Mbps | 128 Kbps AAC |
| YouTube | 720p | 60 | 1.5 Mbps | 2.25–3 Mbps | 4 Mbps | 5+ Mbps | 128 Kbps AAC |
| 1080p | 30 | 1 Mbps | 3–4 Mbps | 4 Mbps | 6+ Mbps | 128 Kbps AAC | |
| 720p | 30 | 0.5 Mbps | 1.5–2.5 Mbps | 4 Mbps | 4+ Mbps | 128 Kbps AAC | |
| Twitch | 1080p | 60 | 3 Mbps | 4.5–6 Mbps | 6 Mbps | 9+ Mbps | 160 Kbps AAC |
| Twitch | 720p | 60 | 2 Mbps | 3–4.5 Mbps | 6 Mbps | 6+ Mbps | 160 Kbps AAC |
| TikTok Live | 1080p | 30 | 2 Mbps | 2–4 Mbps | 4 Mbps | 6+ Mbps | 128 Kbps AAC |
| LinkedIn Live | 1080p | 30 | 0.5 Mbps | 1–3 Mbps | 3.5 Mbps | 5+ Mbps | 96 Kbps AAC |
| Custom RTMP | Any | Any | Varies | Varies | No limit | BW = bitrate × 1.15 | 128–320 Kbps AAC |
05 HLS & RTSP Reference #hls-rtsp
HLS is used for viewer-side delivery via CDN and browsers. RTSP is used for pull-based LAN monitoring, NVR systems and IPTV. Neither is suitable as a contribution protocol — use SRT for contribution and NDI for LAN production.
| Protocol | Use case | Resolution | Bitrate per stream | Viewer-side latency | Key characteristics |
|---|---|---|---|---|---|
| HLS | CDN / web delivery | 1080p 30fps | 3–6 Mbps | 6–30 seconds | Segment-based HTTP. Universal browser support. ABR ladder for adaptive quality. |
| LL-HLS | Low-latency web delivery | 1080p 30fps | 3–6 Mbps | 2–4 seconds | Apple Low-Latency HLS. Reduces segment size. Not all CDNs support it. |
| HLS ABR ladder | Adaptive viewer delivery | 360p–1080p60 | 0.4–9 Mbps per rung | 6–30 seconds | Typical rungs: 400K/360p, 800K/480p, 2M/720p, 4M/1080p, 9M/1080p60 |
| RTSP | LAN monitoring / IPTV | 1080p 30fps | 2–6 Mbps | 1–3 seconds | Pull-based — receiver requests stream. VLC, Plex, NVR systems. Not NAT-friendly. |
| RTSP | IP camera / NVR | 1080p 25fps | 1–4 Mbps | 1–3 seconds | Standard for network cameras, video management and security systems. |
06 Protocol Selection Guide #selection
The correct protocol depends on your network environment, latency requirement, and delivery destination — not personal preference. Use this guide as a starting point for system design decisions.
Full NDI when…
- All devices are on a Gigabit managed LAN
- Lowest possible latency is critical (tally, IEM, intercom)
- Source is a Pro Convert encoder on the same network
- Using vMix, OBS, TriCaster or NDI-native software
NDI HX3 when…
- LAN bandwidth is constrained (Wi-Fi, 100 Mbps switches)
- Multiple simultaneous NDI streams on one switch
- 4K sources over a network not provisioned for Full NDI
- PTZ cameras with NDI HX3 output (most modern PTZ)
SRT when…
- Streaming over the public internet (any distance)
- 4G, LTE, satellite or bonded cellular links
- Encryption is required (AES-256)
- Remote contribution from field locations
- Replacing RTMP for broadcast contribution
RTMP when…
- Final delivery to YouTube, Facebook, Twitch, TikTok
- Stable broadband connection at the delivery point
- Platform requires RTMP ingest specifically
- Using a cloud multistreaming relay service
HLS when…
- Delivering to browser-based viewers via CDN
- Adaptive bitrate for viewers on variable connections
- VOD or time-shifted playback
- IPTV distribution over managed networks
RTSP when…
- Monitoring encoder output on a local LAN
- Integrating with NVR or VMS systems
- IPTV set-top box distribution on a managed LAN
- VLC or media player monitoring at low latency
07 Common Bandwidth Planning Mistakes #mistakes
These are the most frequently encountered bandwidth planning errors in IP video deployments. Each one causes problems that are difficult to diagnose after installation.
Running Full NDI over Wi-Fi
- Full NDI at 1080p60 requires 125–200 Mbps sustained
- Wi-Fi 5 (802.11ac) theoretical max is ~867 Mbps — real-world is 200–400 Mbps shared across all devices
- A single Full NDI stream will saturate most Wi-Fi environments
- Solution: use NDI HX3 (max 62 Mbps) over Wi-Fi, or run Ethernet
Ignoring SRT overhead
- SRT requires 25–40% bandwidth above your encoded bitrate
- A 6 Mbps H.265 stream needs ~7.5–8.5 Mbps of available bandwidth
- Forgetting overhead causes stream drops under load — not at idle
- Always test at sustained load, not during quiet periods
Using headline upload speed as your limit
- ISP headline speeds are burst speeds, not sustained
- Sustained upload is typically 60–70% of headline speed
- Other devices on the same connection reduce this further
- Use fast.com under load conditions to measure real sustained upload
Exceeding RTMP platform maximums
- Bitrate above the platform maximum is silently re-encoded
- You use more upload bandwidth but viewers see no improvement
- Facebook cap is 4 Mbps — sending 8 Mbps wastes half your upload
- Always match your encoder output to the platform's stated maximum
Not accounting for multiple simultaneous streams
- Each simultaneous RTMP destination multiplies bandwidth use
- 3 × 6 Mbps RTMP streams = 18 Mbps upload minimum (×1.5 = 27 Mbps needed)
- Hardware encoders with 6 destinations require significant upload headroom
- Plan total bandwidth for all destinations combined, not per-stream
Underpowered network switches for NDI
- Unmanaged switches have no QoS — NDI traffic competes equally with everything else
- A 100 Mbps switch cannot carry even one Full NDI 1080p60 stream
- Use Gigabit managed switches with IGMP snooping enabled for NDI
- 10GbE core switches recommended for large NDI deployments
08 Cite This Reference #cite
This data is freely available for use in articles, guides, system designs and educational materials. Please attribute iView Data as the source using one of the formats below.
iView Data Ltd. (2026). NDI vs SRT vs RTMP — Complete Bandwidth Requirements Reference. Retrieved from https://iviewdata.com/ndi-srt-rtmp-bandwidth-requirements/
iView Data Ltd. "NDI vs SRT vs RTMP — Complete Bandwidth Requirements Reference." iviewdata.com, June 2026. https://iviewdata.com/ndi-srt-rtmp-bandwidth-requirements/
According to bandwidth reference data published by iView Data (iviewdata.com), Full NDI at 1080p60 requires 125–200 Mbps of sustained LAN bandwidth…
<a href="https://iviewdata.com/ndi-srt-rtmp-bandwidth-requirements/">NDI SRT RTMP Bandwidth Reference — iView Data</a>
Data is reviewed and updated periodically. Platform bitrate figures reflect published guidelines as of June 2026. NDI figures reflect NewTek/Vizrt specification documentation. SRT figures reflect the SRT Alliance specification. Please link to this page rather than copying the data, so your readers always see the most current version.
¹ Full NDI bandwidth varies significantly with scene complexity and motion — high-motion content (sport, concerts) requires the upper end of the stated range. Static content (presentations, talking heads) sits at the lower end.
² SRT overhead of 25% assumes network conditions with up to 5% packet loss. Increase to 40% overhead for 4G/LTE, satellite, or networks with higher observed packet loss.
³ RTMP platform bitrate figures are based on each platform's published streaming guidelines as of June 2026 and are subject to change by the platform operator. Always verify against current platform documentation before a major event.
⁴ Upload speed recommendations assume the stream is the primary consumer of upload capacity on that connection. Reduce available bandwidth by 30% if other upload traffic (video calls, cloud backup, other streams) is running simultaneously.
⁵ NDI is a trademark of NewTek Inc / Vizrt Group. SRT is an open-source protocol maintained by the SRT Alliance. RTMP is a trademark of Adobe Inc. iView Data Ltd has no affiliation with these organisations.
Need Hardware That Supports All These Protocols?
Browse professional encoders, decoders and capture cards supporting Full NDI, NDI HX3, SRT, RTMP and HLS simultaneously — from UK stock with same-day dispatch.