Vimeo Pro

What it means (definitions and thresholds)

Start with clear definitions so the rest of this document is actionable.

• Glass-to-glass latency: time from camera capture to final render on viewer device. We target this metric for all budgets.
• Latency classes (glass-to-glass):
  • Ultra-low: < 1 second — typically requires WebRTC or tightly coupled media paths.
  • Low: 1–5 seconds — achievable with SRT contribution + LL-CMAF/LL-HLS or optimized HLS setups.
  • Near real-time: 5–15 seconds — common for RTMP->HLS flows with reduced segment lengths.
  • Classic VOD/Broadcast: > 15 seconds — standard HLS/DASH segment sizes and CDN caching.
• SRT (Secure Reliable Transport): a UDP-based contribution protocol designed for lossy networks. It uses retransmission (ARQ) to recover lost packets and exposes a configurable latency/jitter buffer measured in milliseconds.
• Key packaging concepts:
  • GOP (group of pictures): interval between keyframes. Measured in seconds or frames; affects seekability and manifest refresh alignment.
  • Part (CMAF/LL-HLS part): small partial segments—typical targets 200–500 ms for low-latency deployments.
  • Player buffer: the client-side buffer that trades latency for smooth playback — typically 200 ms to several seconds.

Decision guide

Choose a path based on your latency target, viewer scale, interactivity needs, and whether you must stream through Vimeo Pro as the canonical public stream.

• If your primary goal is sub-1s interactive (two-way): choose WebRTC for viewer-facing streams. Use SRT for contribution from field to cloud only if you need reliable long-haul transport into your WebRTC gateway.
• If you need 1–5 s glass-to-glass and must scale to thousands: use SRT for contribution to cloud transcoders + LL-CMAF/LL-HLS for distribution. This balances scale and latency.
• If you must publish to Vimeo Pro (which generally accepts RTMP/RTMPS): use SRT-to-RTMP gateway in the cloud. Maintain a parallel low-latency distribution path (LL-HLS/WebRTC) for interactive viewers while Vimeo hosts the canonical public stream, recording, or VOD.
  • Why parallel? Vimeo Pro is excellent for hosting and discovery, but many host services either do not accept SRT directly or do not provide sub-5s playback for end-users. A gateway preserves the SRT reliability benefits and still delivers to Vimeo when needed.
• If you have fewer than ~100 concurrent interactive viewers and primarily use bespoke players: WebRTC-only can be simplest; use SRT for remote production links into the WebRTC infrastructure.
• For very large audiences (100k+): architect for CDN-capable packaging (LL-CMAF/LL-HLS) with origin autoscaling. Use SRT for contribution and origin ingestion, not distribution to clients.

Latency budget / architecture budget

Construct a latency budget and allocate headroom for jitter, retransmits, and spikes. Below are sample component budgets (ms) you can tune to meet target glass-to-glass latency.

Example total budgets for three targets:

• Target = 1.0 s (ultra-low, aggressive)
  • Capture + encode: 80–150 ms
  • SRT transport buffer/latency: 200–300 ms (requires very stable networks)
  • Transcode/packaging (cloud): 200–250 ms
  • CDN transport & edge: 100–150 ms
  • Player buffer & decode: 150–200 ms
  • Total: ~730–1,050 ms
• Target = 3.0 s (practical low-latency)
  • Capture + encode: 100–200 ms
  • SRT transport buffer/latency: 500–1,000 ms (typical internet)
  • Transcode/packaging: 300–600 ms
  • CDN transport & edge: 200–500 ms
  • Player buffer & decode: 200–600 ms
  • Total: ~1.3–2.9 s
• Target = 10 s (large-scale broadcast)
  • Capture + encode: 150–300 ms
  • SRT transport buffer/latency: 1–3 s to survive poor networks
  • Transcode/packaging: 500–1,000 ms
  • CDN transport & caching: 3–5 s
  • Player buffer & decode: 500–1,200 ms
  • Total: ~5.2–10.5 s

Notes:

• Adjust the SRT latency parameter (ms) to move budget between transport reliability and final latency.
• Lower GOP and smaller parts reduce packaging latency but increase encoder and CDN overhead.

Practical recipes

Below are field-proven, actionable recipes. Each recipe lists required components, configuration highlights, and the trade-offs.

Recipe A — SRT contribution + SRT-to-RTMP gateway to Vimeo Pro + low-latency mirror

Use when you must publish the official stream to Vimeo Pro but need a low-latency experience for interactive audiences.

• Components:
  • On-site encoder (OBS, hardware encoder) sends SRT to cloud gateway.
  • Cloud gateway receives SRT, decodes, and simultaneously:
  • a) republishes to Vimeo Pro using RTMPS for recording/distribution; b) sends output to a low-latency packager (LL-CMAF) and CDN for the interactive audience.
• Key settings:
  • SRT latency on encoder: 500–1200 ms (start at 800 ms); use ARQ (retransmit) enabled.
  • GOP: 1.0 s recommended (e.g., keyframe every 30 frames at 30 fps).
  • Republished RTMP to Vimeo: maintain the same keyframe alignment as the input (keyframes every 1 s).
• Trade-offs: Vimeo viewers will see Vimeo's native latency (often higher). Interactive viewers get the low-latency path. Slightly higher cloud CPU due to dual outputs.

Recipe B — SRT to cloud transcoder -> LL-CMAF/LL-HLS to CDN

Use when you control the distribution and want 1–5 s latency at scale.

• Components:
  • SRT contribution from field to cloud ingest cluster.
  • Transcoder: decode SRT, transcode to ABR ladder, produce CMAF fragments and HLS parts.
  • Origin with CDN-enabled LL-HLS (or LL-CMAF) distribution.
• Key settings:
  • Encoder GOP: 1 s
  • CMAF fragment/part: 200–400 ms
  • Segment target: 2.0–3.0 s (made of several parts)
  • Player target buffer: 500–1500 ms
• Trade-offs: requires CDN and player support for LL-HLS/LL-CMAF. Good for large audiences; packaging complexity increases.

Recipe C — SRT contribution + WebRTC gateway for ultra-low latency viewers

Use when a subset of your viewers need sub-second latency (e.g., remote judge panels, auctions) and you can support a smaller scaling tier for interactive users.

• Components:
  • Contribution: SRT from field -> cloud ingest.
  • Realtime gateway: transmux SRT input into WebRTC streams (one or more peer connections) for interactive participants; optionally transcode for compatibility.
  • Parallel LL-CMAF for large-scale passive viewers.
• Key settings:
  • SRT latency: 200–500 ms if network conditions allow.
  • Transcode latency budget: keep p pipelines hot to avoid cold-start delays.
• Trade-offs: higher operational complexity and compute cost per interactive viewer, but glass-to-glass latency can be < 1 s.

Practical configuration targets

Below are numeric targets you can use as starting points in production. Tune them during network tests.

• Encoder
  • Codec: H.264 (baseline/main/profile) for widest compatibility; HEVC only where supported.
  • GOP / keyframe interval: 1.0 s (i-frame every 1 second). Equivalent: keyint = frame_rate * 1.
  • Profile & level: [email protected] or Level 3.1 for 720p; [email protected] for 1080p. Ensure device compatibility.
  • Bitrate targets (single-bitrate contribution):
    • 1080p30: 6–8 Mbps VBR
    • 720p30: 3–5 Mbps
    • 480p30: 1–2.5 Mbps
  • Rate control: CBR or constrained VBR for predictable CDN and CDN-edge bandwidth usage.
• SRT contribution parameters
  • latency: 300–1200 ms for stable internet links; 1500–3000 ms for poor cellular networks. Start at 800 ms for general internet.
  • use-arq: true (SRT built-in retransmission). Note that ARQ can increase effective latency under heavy loss.
  • mtu: 1200–1400 bytes to avoid fragmentation on wide-area networks (smaller MTU for mobile networks).
  • tx/recv buffer: tune to ~2–4x latency parameter if your encoder exposes send/recv buffer sizes.
• Packaging & CDN
  • CMAF fragment / part size: 200–400 ms part sizes for LL-CMAF/LL-HLS.
  • HLS segment target: 2.0–3.0 s (constructed of multiple parts).
  • Manifest TTL / update frequency: push updates immediately on new part availability; reduce playlist hold-back to ~250–500 ms above expected network jitter.
• Player & client
  • Default player buffer: 500–1000 ms for LL (tune per network); 2–6 s for classic HLS.
  • ABR ladder: ensure multiple renditions with overlapping bitrates (e.g., [email protected] Mbps, 720p@4 Mbps, 480p@2 Mbps, 360p@1 Mbps).

Limitations and trade-offs

Engineering low-latency at scale requires acknowledging trade-offs and limitations.

• Reliability vs latency: reducing SRT buffer lowers latency but increases the probability of visible artifacts on lossy networks. Increase latency to improve packet recovery.
• CDN compatibility: not all CDNs or player clients fully support LL-HLS/LL-CMAF. Validate player stack (e.g., HLS.js, native players) before committing.
• Cost: smaller parts and low-latency packaging increase origin CPU and request rates at the CDN, raising cost compared with standard HLS.
• DRM and ad insertion: both can increase latency because of extra handshake or ad stitching steps.
• Vimeo Pro constraints: if Vimeo Pro is your canonical public stream endpoint and does not accept SRT, you must convert to RTMP—this adds an extra hop and may increase viewer latency on Vimeo ingest side.

Common mistakes and fixes

These are frequent configuration errors and how to fix them quickly.

• Symptom: frequent rebuffering on low-latency client.
  • Cause: SRT latency too low for current packet loss/jitter.
  • Fix: increase SRT latency to 800–1500 ms, enable ARQ, and test again.
• Symptom: long delays on manifest updates, even though parts are small.
  • Cause: origin packaging is not flushing parts immediately or playlist hold-back is too large.
  • Fix: ensure packager writes part files immediately; reduce playlist hold-back to ~250–500 ms above network jitter.
• Symptom: Vimeo shows a delayed stream relative to your low-latency CDN.
  • Cause: Vimeo ingestion is via RTMP and uses larger buffers on ingest or has additional encoding pipelines.
  • Fix: do not assume identical latency; route a parallel low-latency distribution path for critical viewers while keeping Vimeo for recording/VOD.
• Symptom: occasional frame drops and decoder stalls on Android devices.
  • Cause: bitrate spikes from unconstrained VBR or unsupported profile/level.
  • Fix: use constrained VBR or CBR; limit profile to Main and use conservative level targets.
• Symptom: SRT connection failing intermittently behind NAT.
  • Cause: blocked UDP or missing NAT bindings on intermediate firewalls.
  • Fix: ensure UDP outbound allowed; open required ports; enable SRT listener mode on cloud gateway when appropriate; consider fallback to RTMPS for worst-case networks.

Rollout checklist

Follow these steps to move from POC to production safely.

1. Requirement alignment
   1. Define glass-to-glass target latency and acceptable jitter/loss thresholds.
   2. Determine required viewer scale and CDN constraints.
2. Lab testing
   1. Establish a controlled SRT link with representative packet loss/jitter (e.g., 0–5% random loss, 20–200 ms jitter).
   2. Adjust SRT latency and encoder settings until both stability and latency targets are met.
3. Integration with Vimeo Pro (if required)
   1. Validate RTMP ingest behavior; test edge-case timings for keyframe alignment.
   2. Run side-by-side streams: one to Vimeo (RTMP) and one to low-latency CDN for interactive users.
4. Scale testing
   1. Load test CDNs and origins at expected concurrency levels and monitor origin CPU, memory, and request rates.
   2. Perform network emulation tests across geographic regions.
5. Monitoring
   1. Instrument SRT stats (packet loss, retransmits, RTT, jitter), encoder CPU, packaging latency, CDN delivery times, and client-side startup/rebuffer counts.
6. Fallbacks
   1. Implement RTMP/RTMPS fallback for contribution where UDP is blocked.
   2. Enable automatic stream failover between encoders when possible.

Example architectures

Concrete architectures illustrate how to map SRT into production systems.

Small event (single-site, 100s viewers)

• On-site: single encoder (SRT output) -> Cloud SRT ingest (single instance) -> Transcoder -> CDN (LL-HLS) -> Client players.
  • Expected glass-to-glass: ~2–4 s with SRT latency 800 ms.
  • Use cases: corporate webinars, small concerts.

Medium event (multi-remote contributors + Vimeo as canonical record)

• Remote encoders (multiple SRT callers) -> Cloud aggregator/orchestrator -> Mixer/transcoder ->
  • Path A: RTMPS -> Vimeo Pro (for public archive/recording)
  • Path B: LL-CMAF -> CDN -> interactive viewers
  • Expected glass-to-glass on Path B: ~1.5–3 s.

Large-scale broadcast (100k+ viewers)

• On-site SRT contribution -> Edge SRT collectors -> Autoscaling transcoding pool -> Origin + multi-CDN LL-HLS distribution -> Client players.
  • Implement multi-CDN and origin redundancy, keep SRT latency at 800–1500 ms to survive long haul jitter.
  • Expected glass-to-glass: 3–10 s depending on CDN and segment configuration.

Troubleshooting quick wins

If you're in the middle of a show and need fast fixes, try these steps in this order.

1. Increase SRT latency by +200–500 ms and observe whether retransmission recovers artifacts.
2. Check encoder CPU and lower resolution/bitrate if CPU > 80% to avoid encoding stalls.
3. Validate keyframe alignment: make sure downstream packager expects the same GOP/keyframe interval.
4. Reduce MTU to 1200 bytes if you see fragmented UDP packets or excessive retransmits.
5. Enable RTMP fallback for critical viewers if UDP is blocked in a client environment.

Next step

If you want to pilot or productionize any of the recipes above, start with these practical actions:

• Run a controlled test: set up a single SRT contribution into a cloud collector and measure packet loss, RTT, and effective glass-to-glass time. Use the values above as targets.
• Map your requirements to a simple product stack:
  • Ingest & orchestration: see our platform overview at /platform.
  • Transcoding & packaging: evaluate options at /products.
  • Pricing and capacity planning: review /pricing for production scale.
• Read the implementation docs and examples:
  • SRT contribution patterns: /docs/srt
  • Low-latency packaging guides (LL-HLS/LL-CMAF): /docs/low-latency
  • Operational runbooks and troubleshooting: /docs/guides
• Contact engineering to set up a workshop or pilot (link to contact): /contact.

If you use Vimeo Pro as your canonical endpoint, adopt a two-path architecture during rollout: keep Vimeo for recording and public hosting, and expose a parallel low-latency path (LL-CMAF or WebRTC) for interactive users. That approach gives you the reliability and brand benefits of Vimeo Pro while delivering a predictable low-latency experience to your audience.