Why This Matters

Streaming feels like one technology and is actually two technologies stitched together at the cloud, and a founder, product manager, or operations lead who does not see the seam will be confused by every protocol decision that follows. The single most common scoping mistake is to assume that one protocol — usually whichever one the encoder vendor ships by default — handles both ends of the pipeline. Once you understand that contribution and distribution solve different problems, the rest of the streaming protocol zoo stops looking arbitrary: each protocol has a side it lives on and a reason it lives there. By the end of this article you will be able to read any streaming architecture diagram and instantly tell which protocols are doing the contribution leg, which are doing the distribution leg, and why the workflow chose that pairing.

The seam that splits the pipeline in two

A camera in a studio, a stadium, or a living room produces one feed. A viewer at home, on a phone, or on a smart TV consumes that feed alongside hundreds or thousands or millions of other viewers. Between those two endpoints sits the cloud, and the cloud is the seam that splits the pipeline into two halves with completely different requirements.

On the contribution side, the cloud is the destination. There is exactly one connection — from the encoder at the venue to the first server in the cloud — and the engineer's whole job is to keep that one connection alive on a network they do not control. On the distribution side, the cloud is the source. There are millions of connections from the cloud to every viewer's device, and the engineer's whole job is to scale that fan-out without the cost or the latency blowing up.

These two problems pull protocol design in opposite directions. A protocol that is great at keeping one fragile connection alive — heavy retransmission buffers, dedicated ports, custom congestion control — is terrible at being cached by 600 edge points of presence across the world. A protocol that is great at being cached — short HTTP segments, plain-text manifests, vanilla TCP — is terrible at recovering from a 4G hotspot dropping for 800 ms. So the industry built two protocol families, one per side of the seam, and the standard architecture for any non-trivial streaming product runs one protocol from each family in the same workflow.

Diagram showing the streaming pipeline split into two halves by a central cloud, with one source camera on the left connected to the cloud via push contribution protocols (RTMP, SRT, RIST, WHIP) and many viewers on the right connected to the cloud via pull distribution protocols (HLS, DASH, LL-HLS, WHEP, MoQ) Figure 1. The seam that splits every streaming pipeline. One source on the left, many viewers on the right, the cloud in the middle. Contribution protocols live on the left half; distribution protocols live on the right half. Almost every real workflow uses one protocol from each family.

What "push" and "pull" actually mean

The words "push" and "pull" describe who initiates the connection that carries the media. The distinction sounds academic and turns out to control almost every interesting property of the protocol.

A push protocol is one where the source — the encoder at the venue — opens a connection to the cloud and starts sending packets as they are produced. The encoder is in charge of the cadence. If the encoder produces a packet, the packet goes on the wire whether the cloud asked for it or not. RTMP, SRT, RIST, and WHIP are all push protocols. The encoder pushes the stream toward the cloud.

A pull protocol is one where the consumer — the viewer's player — opens a connection to a server and asks for content one piece at a time. The player is in charge of the cadence. The server has the entire stream sitting on disk or in cache, and it sends only what the player explicitly requests. HLS, DASH, LL-HLS, LL-DASH, CMAF, WHEP, HESP, and Media over QUIC are all pull protocols. The player pulls the stream from the cloud.

A useful analogy: a push protocol is like a delivery truck that drives the package from the warehouse to the customer's door whether the customer is home or not. A pull protocol is like a customer walking into the warehouse and asking for the package at the counter — nothing leaves the warehouse until the customer asks for it.

Two architectural consequences fall out of that one difference. First, push protocols cannot be cached by anyone but the recipient — there is nothing to cache, because the bytes only exist on the wire while they are being pushed. Pull protocols cache trivially, because the segments sit on disk waiting for any player to ask for them, and a content delivery network can store a copy of each segment at every edge. Second, push protocols can shape themselves to the live source — they push exactly what the encoder produced, in real time. Pull protocols need a buffer of segments already published before the player can start, which is where the multi-second latency floor of HTTP-based streaming comes from.

The whole industry vocabulary maps onto this split. "Contribution" and "ingest" are synonyms for the push half of the pipeline. "Distribution", "delivery", and "egress" are synonyms for the pull half. When a Mux or Cloudflare or AWS document says "ingest endpoint", they mean a push endpoint that receives RTMP, SRT, or WHIP. When the same document says "delivery endpoint" or "playback URL", they mean a pull endpoint that serves HLS, DASH, or WHEP.

The contribution family: protocols that push

The contribution leg is the riskiest hop in a streaming pipeline because the network between a venue and the cloud is almost always the worst-conditioned link in the chain. A single home broadband uplink, a 4G hotspot, a stadium's overloaded Wi-Fi, a remote satellite uplink — the contribution path is one cable, one radio, one peering link, and any of them can degrade or fail at any moment. Whatever protocol carries the encoded stream over this hop has to defend itself against jitter, packet loss, and the occasional total link drop, with a latency budget measured in hundreds of milliseconds to a few seconds.

Four protocols dominate the 2026 contribution landscape:

RTMP (Real-Time Messaging Protocol). The legacy default. Adobe-defined in the late 1990s, TCP-based, runs on port 1935, ships in every encoder ever shipped from OBS Studio to broadcast-grade Elemental hardware. Adobe formally deprecated it years ago, and Adobe Flash itself died in 2020, but every encoder and every ingest server still speaks RTMP because everyone speaks RTMP. It works, but it has weaknesses that the next two protocols were designed to fix: no real congestion control beyond what TCP gives it, no native UDP path, head-of-line blocking on every lost segment of TCP, and a codec straitjacket that only formally supports H.264 and AAC (vendors have layered H.265 and AV1 on top with non-standard extensions, but interoperability is rough). The full RTMP-in-2026 story lives in our RTMP status article.

SRT (Secure Reliable Transport). The professional contribution standard for the public internet. Originated at Haivision, opened in 2017, now formally standardised through the IETF as draft-sharabayko-srt-01 (the active Internet-Draft as of January 2026, with the formal RFC expected to follow). UDP-based with tunable forward error correction and a configurable retransmission buffer (typically 4× the round-trip time), supports any codec, runs through firewalls more reliably than RTMP, and is what most broadcast remotes use today. SRT adds a configurable latency buffer — 1 to 4 seconds is typical — as the price for surviving aggressive packet loss on the contribution link. Our SRT deep dive covers the full configuration surface.

RIST (Reliable Internet Stream Transport). The broadcast-grade alternative to SRT, defined by SMPTE in three Technical Recommendations: TR-06-1 (2020), TR-06-2 (2022), and TR-06-3 (2024). RIST has three "profile" versions — Simple, Main, and Advanced — with progressively more features (encryption, authentication, multiplexing, GRE tunnelling). RIST is the choice when a broadcaster needs SMPTE-standard interoperability with existing studio infrastructure. We cover it in RIST: the broadcast-grade alternative.

WHIP (WebRTC-HTTP Ingestion Protocol). The modern standard. IETF RFC 9725, published March 2025. WHIP is a thin HTTP signalling layer on top of WebRTC for ingest: a POST from the encoder containing an SDP offer, a 201 Created response from the server containing the SDP answer, and then the encoder pushes RTP/SRTP media directly over the negotiated WebRTC peer connection. Sub-second latency end-to-end, native firewall traversal via ICE/STUN/TURN, supports H.264, H.265, VP8, VP9, and AV1, and ships in every modern encoder from OBS 30 onward. The right default for any new pipeline starting in 2026 unless you have a specific reason not to. See WHIP webrtc ingest (RFC 9725) for the standards walkthrough.

Two niche standards round out the picture. Zixi is a proprietary, broadcast-grade alternative that bundles transport with content management and is licensed per stream. NDI (Network Device Interface) and SMPTE ST 2110 live inside the studio: NDI for IP video on a controlled gigabit LAN, ST 2110 for the rigorously timed studio-internal IP transport that has replaced SDI in most modern broadcast facilities. Neither leaves the building. Our Zixi, NDI, ST 2110 article covers when each one applies.

What every contribution protocol shares: one source, one connection, push-initiated. The technical decisions vary — TCP vs UDP, codec list, congestion control, buffer depth — but the role in the pipeline is the same. They all answer the same question: how do we move one fragile feed across one bad network into the cloud without losing more than is acceptable for the use case?

The distribution family: protocols that pull

The distribution leg is the opposite problem. The feed is already in the cloud. The cloud has effectively unlimited storage, predictable bandwidth, and a CDN with hundreds of edge POPs ready to serve cached copies. The challenge is not reliability over a hostile link — it is fan-out: serving the same stream to a million viewers without overloading the cloud and without sending a billion redundant bytes across the internet.

The protocols that solve this problem all share two traits. First, they run over HTTP (or in the case of WebRTC egress, over a WebRTC peer connection that is far easier to scale than the conferencing case it was originally designed for). Second, they break the stream into small, self-contained pieces — segments, chunks, parts, frames — that can be cached, fetched, and discarded independently. Both traits are about making the stream look, as much as possible, like ordinary web traffic, because ordinary web traffic is the thing the internet has spent thirty years learning to deliver at scale.

The 2026 distribution landscape:

HLS (HTTP Live Streaming). The dominant protocol. Originated at Apple in 2009, standardised as RFC 8216 in 2017, currently being updated as draft-pantos-hls-rfc8216bis at the IETF. HLS publishes a plain-text manifest (.m3u8) that lists media segments (.ts or .m4s, 2 to 6 seconds each); the player fetches the manifest, then fetches each segment in turn over HTTPS. Cache-friendly, runs in every browser, plays natively on iOS, Safari, and every smart TV. Our HLS deep dive walks the full spec.

LL-HLS (Low-Latency HLS). Apple's extension to HLS for sub-5-second latency, defined in the Apple HLS Authoring Specification (revision 2025-09 is the current version as of this writing). LL-HLS splits each segment into 200-millisecond "parts" that the player can fetch as soon as they are available, drops the player buffer from 3 segments to roughly 1.5 segments, and uses HTTP/2 blocking playlist requests so the player learns about new parts the instant they are published. The full mechanics are in LL-HLS in depth.

MPEG-DASH (Dynamic Adaptive Streaming over HTTP). The ISO/IEC alternative to HLS, defined in ISO/IEC 23009-1:2022. DASH publishes an XML manifest called a Media Presentation Description (.mpd) and is otherwise structurally similar to HLS: segments fetched over HTTP, adaptive bitrate selection at the player. DASH is the dominant protocol for OTT on Android, smart TVs, and any pipeline that needs flexible DRM (PlayReady, Widevine) more than it needs native iOS playback. Our DASH deep dive covers the manifest model in detail.

LL-DASH (Low-Latency DASH) and CMAF chunked encoding. The DASH-IF answer to LL-HLS. Uses CMAF (ISO/IEC 23000-19:2024) chunks of 100 to 500 milliseconds inside 2-second segments, delivered via HTTP/1.1 chunked transfer encoding so the player receives chunks as they are produced. Target latency: 2 to 5 seconds glass-to-glass. Walk-through in LL-DASH and low-latency CMAF.

CMAF (Common Media Application Format). Strictly speaking, CMAF is a packaging format, not a delivery protocol — it is the fragmented MP4 (fMP4) container defined in ISO/IEC 23000-19 that the same physical segment can be served by both HLS and DASH. CMAF is what makes the unified low-latency story work. The CMAF deep dive shows how the brands and profiles line up.

WHEP (WebRTC-HTTP Egress Protocol). The egress mirror of WHIP, currently draft-ietf-wish-whep-03 as of January 2026. WHEP gives a player an HTTP endpoint to which it sends an SDP offer; the server responds with an SDP answer, and the server pushes media into a WebRTC peer connection that the player consumes. Sub-500-millisecond latency for a small to medium audience size, with the trade-off that WebRTC scales differently from HTTP — see WebRTC delivery scaled for the architecture.

HESP (High-Efficiency Streaming Protocol). A 400-millisecond HTTP-based delivery protocol from THEO Technologies, currently draft-theo-hesp-04. Splits the stream into a continuation playlist plus an initialisation playlist, allowing immediate join from any point with no segment-boundary wait. Niche but interesting — see HESP explained.

Media over QUIC (MoQ). The newest entry, currently draft-ietf-moq-transport-17 (January 2026, subject to revision before publication as an RFC). MoQ is a publish/subscribe model on top of QUIC that promises both low latency and cache friendliness in the same protocol — bridging the historical push-vs-pull split. MoQ Transport defines the wire format; companion drafts define application profiles for streaming, conferencing, and chat. The big bet for the second half of the decade. Deep dive in Media over QUIC.

The pattern across the whole distribution family: one source in the cloud, many viewers, pull-initiated. Every distribution protocol is engineered for the same constraint — a CDN must be able to cache and replicate the bytes without understanding what they mean — and the protocols compete on how well they hide the latency cost of that constraint.

Pairings: which contribution protocol talks to which distribution protocol

Every real streaming workflow uses at least one protocol from each side. The pairing is rarely arbitrary: each pair is chosen so the operations join cleanly at the cloud, the latency budget composes correctly, and the codecs on each side actually match.

The five common pairings in 2026:

ContributionDistributionTypical useLatencyNotes
RTMPHLS (or HLS + DASH)OTT VOD-like live, news, talk shows18–30 sThe legacy default. Wide compatibility, high latency.
SRTHLS / LL-HLS / DASHPro broadcast, live sports, news remotes4–8 sIndustry-standard for serious live work on public internet.
WHIPLL-HLS / LL-DASHModern OTT, live shopping, interactive live2–5 sThe 2026 default for any new pipeline.
WHIPWHEPAuctions, interactive Q&A, telehealth-style 1-to-many0.2–0.5 sPure WebRTC end-to-end. No HTTP cache, pays in SFU compute.
RISTHLS / DASHBroadcast contribution into OTT distribution4–10 sWhen SMPTE interoperability matters at ingest.
Two patterns deserve calling out. The first is that the most aggressive low-latency pairing (WHIP → WHEP) gives up the HTTP cache hierarchy entirely. The whole point of a CDN — one origin fetch per region serving thousands of edge cache hits — does not apply when every viewer holds an open WebRTC peer connection. Scaling WHEP past a few hundred viewers per stream requires a mesh of selective forwarding units (SFUs) that cascade the connection, which is a completely different architecture from a CDN. We cover that in WebRTC at scale.

The second is that hybrid stacks are normal, not exceptional. A big OTT product typically ingests with RTMP for legacy partners, SRT for premium broadcast partners, and WHIP for everyone signing up in 2026; on the distribution side, the same product publishes HLS for Apple and smart TVs, DASH for Android and PlayReady-DRM markets, and increasingly LL-HLS or LL-DASH for the latency-sensitive parts of the catalogue. Inside the cloud, the transcoder produces one set of CMAF media files that feeds both HLS and DASH manifests, so the storage cost is paid once. We walk through the architecture in Hybrid protocol stacks.

The math: why the contribution link needs more headroom

A concrete number worth carrying around: budget at least 1.5× the encoded bitrate of your top rendition as sustained uplink bandwidth on the contribution link.

For a 1080p stream encoded at 5 Mbps, that is:

  • 5 Mbps × 1.5 = 7.5 Mbps of sustained uplink required.
  • Out of which roughly 0.5 Mbps absorbs protocol overhead (headers, ACKs, FEC).
  • Roughly 1.0 Mbps absorbs the periodic keyframe spike of a 2-second GOP — keyframes are 5 to 10× the size of average predicted frames, so a 5 Mbps average bitrate produces 10 to 25 Mbps peak bursts every 2 seconds.
  • Roughly 1.0 Mbps absorbs retransmission and FEC overhead for SRT or WHIP on a real-world loss-prone link.

The same 5 Mbps stream on the distribution side, by contrast, needs almost no headroom at the origin — the CDN absorbs the burstiness, and any individual viewer pulls only what their last-mile connection sustains. Headroom on the distribution side is paid for once at the CDN edge and amortised across every viewer.

This asymmetry is the single most useful design insight for sizing a new streaming product. Contribution links are about one source, billed by bandwidth on a fragile uplink, sized for the worst minute of the broadcast. Distribution is about aggregate egress, billed by terabytes across a CDN, sized for the worst day. Mixing the two budgets up is how cost models go wrong.

Stacked horizontal bar showing how the 7.5 Mbps contribution budget for a 5 Mbps stream breaks down into media bytes, protocol overhead, keyframe spike headroom, and retransmission and FEC headroom, with the contribution side annotated as one source with a fragile uplink and the distribution side annotated as fan-out with no per-viewer headroom needed at origin Figure 2. Where the contribution headroom goes. A 5 Mbps stream needs 7.5 Mbps of sustained uplink — half a megabit for protocol overhead, a megabit for the keyframe spike, a megabit for retransmission. The same 5 Mbps stream on the distribution side needs effectively no per-viewer headroom; the CDN absorbs the burstiness.

How the two sides actually join inside the cloud

The cloud is not magic, and the seam between contribution and distribution is a specific server cluster — usually called the "transcoder" or "media processor" — that consumes the contribution stream, rebuilds it into the distribution-ready form, and hands it to the origin. The five jobs that happen at this seam:

The first job is demuxing the contribution feed. If the encoder sent RTMP carrying H.264 + AAC, the transcoder unpacks the RTMP container, extracts the video and audio elementary streams, and forwards them to the next step. If the encoder sent WHIP, the WHIP server terminates the WebRTC peer connection, extracts the RTP packets, and reconstructs the original frames.

The second job is transcoding to the bitrate ladder. A single contribution feed at 5 Mbps becomes a ladder of five renditions — 1080p, 720p, 480p, 360p, 240p — at progressively lower bitrates. Each rendition is encoded by the transcoder in real time, on GPU or specialised ASIC. The ladder shape is what makes adaptive bitrate streaming work on the distribution side. We cover ladder design in Building a bitrate ladder.

The third job is packaging. The transcoded renditions are wrapped into CMAF (ISO/IEC 23000-19) segments, typically 2 to 6 seconds long, with 200-millisecond chunks inside each segment for low-latency profiles. A manifest — .m3u8 for HLS, .mpd for DASH — lists the segments and the renditions. CMAF lets one set of media files serve both HLS and DASH players. Full mechanics in CMAF: the packaging format that unified HLS and DASH.

The fourth job is publishing to the origin. The packaged manifest and segments land on an HTTP origin server — typically AWS S3, Google Cloud Storage, or a self-hosted Nginx — that holds a rolling window of the live stream and serves the manifest and segments to whatever asks for them.

The fifth job is CDN propagation. The CDN's origin-shield layer fetches the manifest and segments from the origin, mid-tier caches in each region fetch from the shield, and edge POPs in each city fetch from the mid-tier. By the time the first viewer in a region requests playback, the segments are sitting on a nearby edge ready to be served. We cover the cache hierarchy in Origin shielding and tiered caching.

All five jobs happen continuously, in real time, with end-to-end latency from "encoder produces frame" to "first viewer's segment is cached at edge" running anywhere from one to ten seconds depending on the configuration. The seam between push and pull is conceptually clean — push protocols stop here, pull protocols start here — but the implementation is the most operationally complex part of a streaming product.

Why Media over QUIC matters: a protocol that bridges the seam

The cleanest signal that the industry knows the push/pull split is a 2010s artefact, not a permanent law of streaming, is the explicit push to design a protocol that does both well. Media over QUIC (MoQ) is that protocol.

MoQ Transport (draft-ietf-moq-transport-17, January 2026) defines a publish/subscribe model on top of QUIC. A publisher — which can be the encoder at the venue or a relay inside the cloud — announces named tracks of media objects. A subscriber — which can be a relay or a player — subscribes to a track and receives objects as they are published, with QUIC's per-stream reliability and no head-of-line blocking. The model is push from the publisher's perspective and pull from the subscriber's perspective, with relays in between that can cache objects, dedupe subscriptions, and fan out to many subscribers.

What that buys streaming products: contribution-grade latency (sub-second, comparable to WHIP) with distribution-grade fan-out (caches at every relay, no per-viewer compute at the cloud). The first commercial deployments shipped in 2025; the IETF MoQ working group is iterating on the transport draft and several application profile drafts. By the late 2020s, MoQ is the most credible candidate to replace the HLS/DASH plus WHIP/WHEP split with a single protocol that does both jobs.

This is forward-looking work, not yet a production default — draft-ietf-moq-transport-17 is still subject to revision before publication as an RFC, and the deployed implementations (Meta's MoQ proof of concept, Cloudflare's Twitch demos) are early. Our Media over QUIC deep dive covers what's standardised, what's still in flux, and what to monitor.

Common mistakes and pitfalls

A few errors recur across streaming projects that confuse the contribution and distribution halves.

The first is picking one protocol for both sides. RTMP is the classic case: a team picks RTMP because the encoder supports it, runs RTMP all the way to the player via some custom WebSocket bridge, discovers that there is no cache hierarchy, and ends up paying CDN-class egress bills for what should have been one set of CDN segments. Similarly, a team that picks WebRTC end-to-end for an OTT live audience pays SFU compute for every viewer when an HLS pipeline would have paid CDN egress only.

The second is picking incompatible codecs. RTMP formally supports only H.264 and AAC; if the distribution side runs HEVC or AV1 to save bandwidth, the contribution side has to be re-encoded or shipped over a different ingest protocol. WHIP and SRT both support the modern codecs, which is one of the practical reasons to retire RTMP for new projects.

The third is sizing the contribution link for average bandwidth. The contribution side has a peak-vs-average problem from keyframes that distribution does not have, because every keyframe is 5 to 10× the size of an average predicted frame. A 5 Mbps stream produces 25 Mbps bursts every 2 seconds at the encoder output. Size the contribution uplink for the peak, not the average.

The fourth is assuming the CDN works for everything. The CDN sits between origin and viewer on the distribution side; it does nothing on the contribution side. A contribution-side latency problem cannot be solved by buying more CDN capacity. Diagnose the seam side correctly before reaching for tools.

The fifth is forgetting that hybrid is normal. Most non-trivial streaming products run multiple contribution protocols (RTMP for legacy partners, SRT or WHIP for new ones) and multiple distribution protocols (HLS for Apple, DASH for Android and DRM, LL-HLS for premium live). Designing for one-protocol-each-side and then bolting on the second one in year two is the wrong order.

Where Fora Soft Fits In

We have shipped contribution-side and distribution-side stacks since 2005 across video conferencing, OTT and Internet TV, telemedicine, e-learning, video surveillance, and AR/VR. The typical Fora Soft project hits both sides of the seam: a WHIP or SRT ingest from a customer-facing encoder into a cloud cluster we built, plus a CMAF-packaged distribution layer feeding HLS and DASH players across browsers, iOS, Android, and smart TVs. The split between contribution and distribution is the first architectural decision we draw on the whiteboard for any new streaming product, because every later decision — codec choice, CDN sizing, latency budget, player matrix — flows from getting that split right.

What to Read Next

Talk to Us / See Our Work / Download

  • Talk to a streaming engineer — get a 30-minute scoping call on your contribution and distribution architecture, your protocol pairing, and the latency budget that connects them. Contact form.
  • See our case studies — production streaming, conferencing, OTT, and telemedicine work shipped since 2005. Portfolio.
  • Download the contribution vs distribution map — one-page reference of the two protocol families, with the typical pairings and latency contributions for 2026 production workflows: contribution-distribution-map.pdf.

References

  1. Murillo, S., Naranjo, Ch., Tarrías, G., Murillo, J. RFC 9725: WebRTC-HTTP Ingestion Protocol (WHIP). IETF, March 2025. The standards-track specification for WebRTC-based contribution. Cited here as the default modern ingest protocol and for the SDP offer/answer mechanics in the contribution section. https://datatracker.ietf.org/doc/html/rfc9725
  2. Murillo, S., Naranjo, Ch. draft-ietf-wish-whep-03: WebRTC-HTTP Egress Protocol (WHEP). IETF Internet-Draft, January 2026. The egress mirror of WHIP, currently a working-group draft; cited as in-progress with the explicit note that the draft is subject to revision before publication as an RFC. https://datatracker.ietf.org/doc/html/draft-ietf-wish-whep
  3. Pantos, R., May, W. RFC 8216: HTTP Live Streaming. IETF, August 2017. The canonical HLS specification; cited in the distribution section for the manifest and segment structure that defines pull-based delivery. https://datatracker.ietf.org/doc/html/rfc8216
  4. Apple Inc. HTTP Live Streaming (HLS) Authoring Specification for Apple Devices, revision 2025-09. Apple Developer Documentation, September 2025. Source of the LL-HLS part / preload-hint / blocking-reload mechanics cited in the distribution family list. https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices
  5. ISO/IEC 23009-1:2022. Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media presentation description and segment formats. ISO/IEC, 2022 edition. The DASH specification, cited here as the standards basis for the distribution side's MPD manifest model. Catalogue page: https://www.iso.org/standard/83314.html
  6. ISO/IEC 23000-19:2024. Information technology — Multimedia application format (MPEG-A) — Part 19: Common media application format (CMAF) for segmented media. ISO/IEC, 2024 edition. Cited for the CMAF packaging that unifies HLS and DASH at the seam between contribution and distribution.
  7. Sharabayko, M. et al. draft-sharabayko-srt-01: The SRT Protocol. IETF Internet-Draft, January 2026. The current draft for the SRT protocol; cited in the contribution section for the SRT buffer model. Subject to revision before RFC publication. https://datatracker.ietf.org/doc/html/draft-sharabayko-srt
  8. SMPTE. TR-06-1, TR-06-2, TR-06-3: Reliable Internet Stream Transport (RIST) Protocol Specification. SMPTE, 2020 / 2022 / 2024. The three SMPTE Technical Recommendations that define RIST Simple, Main, and Advanced profiles. Cited as the broadcast-grade alternative in the contribution family. https://www.smpte.org/standards
  9. Adobe Systems Inc. Real-Time Messaging Protocol (RTMP) Specification, version 1.0. Adobe, 21 December 2012 (archived). The original RTMP specification, cited in the contribution section for the historical context and the H.264/AAC codec constraint. https://rtmp.veriskope.com/docs/spec/
  10. Iyengar, J., Thomson, M. (eds.) RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport. IETF, May 2021. Cited as the transport layer underlying both HTTP/3 (distribution side) and Media over QUIC. https://datatracker.ietf.org/doc/html/rfc9000
  11. Bishop, M. (ed.) RFC 9114: HTTP/3. IETF, June 2022. Cited in the distribution family discussion as the modern HTTP transport that LL-HLS and LL-DASH are migrating onto. https://datatracker.ietf.org/doc/html/rfc9114
  12. Curtis, V. et al. draft-ietf-moq-transport-17: Media over QUIC Transport. IETF Internet-Draft, January 2026. The current Media over QUIC transport draft; cited as the bridge-the-seam candidate that does both contribution and distribution in one protocol. Subject to revision before RFC publication. https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport
  13. Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V. RFC 3550: RTP: A Transport Protocol for Real-Time Applications. IETF, July 2003. Cited as the wire format that WebRTC, and therefore WHIP and WHEP, use to carry media. https://datatracker.ietf.org/doc/html/rfc3550
  14. DASH Industry Forum. DASH-IF Implementation Guidelines: Low-Latency Live Streaming, revision 4.3. DASH-IF, March 2026. Cited in the distribution section for the LL-DASH and CMAF chunked encoding profile. https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf
  15. THEO Technologies. draft-theo-hesp-04: High Efficiency Streaming Protocol (HESP). IETF Internet-Draft. Cited in the distribution family as the 400 ms HTTP-based alternative; draft status, subject to change. https://datatracker.ietf.org/doc/html/draft-theo-hesp