Compare roles and player requirements
The service supports discussion of HLS, HTTP-FLV, RTMP and WebRTC delivery. Actual formats, codecs, authentication and operating limits must match the agreed project. The comparison below describes common protocol characteristics, not a service-level guarantee.
| Protocol | Typical role | Check before integration |
|---|---|---|
| HLS | HTTP-based viewer playback and CDN distribution | Native support or a compatible player, codecs, segments, signed URLs and cache behaviour |
| HTTP-FLV | HTTP delivery to compatible playback stacks | A suitable player/transmuxer, browser media support, codecs and cross-origin policy |
| RTMP | Pushing a feed into an ingest server | Ingest credentials and downstream conversion; not direct modern browser playback |
| WebRTC | Interactive or low-latency playback paths | Signalling, ICE connectivity, STUN/TURN requirements and fan-out capacity |
Measure latency, do not infer it from a name
End-to-end delay includes capture, encoding, packaging, network delivery and player buffering. HLS segment duration and low-latency extensions affect one part of that path. WebRTC can reduce delay in suitable conditions, but its name does not prove a particular result.
Use a known source time reference and observe the displayed picture on the target device. Record network, region, device, player version, observation duration and typical and high-percentile delay. Agree a measurable acceptance target instead of promising zero latency.
Start with target devices and codecs
List the browsers, mobile operating systems, embedded webviews and native apps you actually support. Container support is not the same as codec support. Test audio as well as video and include expiry, reconnects and background/foreground transitions.
Do not paste an RTMP address into an HTML video element and expect it to work. Likewise, an HTTP-FLV URL usually needs a compatible playback implementation. Choose and validate a maintained player before committing to an integration path.
Separate contribution from audience distribution
An ingest feed may arrive once at your server while your CDN serves many viewers. Agree who performs packaging, origin hosting, transcoding and delivery, and who pays for egress. Estimate simultaneous feeds and viewers independently.
Check failure paths as well as normal playback: an unavailable ingest endpoint, blocked segment request, failed WebRTC connection or expired URL. Confirm the fallback method, whether it preserves the same event and how the player obtains replacement credentials.