Live, On-Demand, or Both? The Streaming Decisions That Actually Matter

"Should we stream it live or just record it?" is usually the first question asked and the least useful one, because it bundles four separate decisions into a single word.

Those decisions are timing, access, where production happens, and what stays recoverable afterwards — and "recorded" usually means video on demand, which is a delivery model with its own requirements rather than a leftover file. They have different costs, they fail in different ways, and one of them can quietly change your legal obligations. Untangling them before anyone quotes you for equipment is worth more than any amount of platform comparison.

Decision one: does the live moment actually do anything?

Live has a cost, and the cost is latency — which is not a setting somebody forgot to switch on.

Standard HTTP Live Streaming is built around segmented delivery. RFC 8216 notes a typical target segment duration of ten seconds, and requires that a live playlist retain at least three target durations' worth of segments. Compliant players therefore sit back from the live edge by roughly three segments before anything else is counted. The DASH-IF and DVB low-latency report puts it bluntly: ten-second segments with two to three buffered at the client "immediately results beyond 30 seconds end-to-end latency."

Low-latency variants attack exactly that mechanism. Apple's Low-Latency HLS documentation describes standard HLS as having historically favoured "stream reliability over latency," and its own worked example publishes partial segments of roughly 333 milliseconds inside four-second parent segments — about a twelfth the length — so playback can start much closer to the live edge. Worth knowing that the formal syntax for those extensions still lives in an IETF draft rather than a ratified RFC.

Two things follow that are easy to miss.

Broadcast is not zero-latency either. The same DASH-IF report quotes the BBC measuring conventional broadcast delivery — encoder input to television display — at roughly three seconds minimum and a little under six at maximum. "As fast as TV" is a real target, not an aspiration to instantaneous.

And the delay only matters if something depends on it. A one-way town hall where questions arrive by text is completely unbothered by twenty seconds. A live Q&A where remote attendees have to find a gap and take it is not. If nothing in your run of show depends on the audience reacting in real time, you are paying for low latency you will never notice.

One caution, because it turns up constantly in streaming advice: ITU-T G.114 is not the standard for this. Its 150ms and 400ms bands are filed under international telephone connections and circuits — it is a telephony one-way-delay standard for conversational voice, not a measure of glass-to-glass video latency. We went through the same misapplication in more detail when writing about hybrid event streaming, where the consequences are sharper because the audience is expected to talk back.

Decision two: who is allowed to watch

"Private" covers several mechanisms that protect against genuinely different things, and they get conflated.

• An unlisted URL is not access control. It is obscurity. Anyone who has the link has the stream, and links get forwarded.
• Signed or tokenised URLs (JWT, RFC 7519) tie access to something time-limited and verifiable. This is real access control, and it is usually the right tool for a corporate audience.
• SSO ties viewing to your existing identity provider, which also tells you who actually attended.
• Geo or IP restriction is a rights and compliance tool, not a security control. A moderately motivated viewer routes around it.
• DRM protects the content itself rather than the door. Note that W3C Encrypted Media Extensions explicitly does not define a DRM system — it defines how a browser talks to one. "We use EME" is not a statement about how well-protected anything is.

Most enterprise streaming solutions offer several of these together, and the label on the tier tells you less than the mechanism does. Worth asking which one is actually enforcing access before assuming the answer.

The instinct that corporate webcasting should be gated by default is also worth examining, because there is at least one important category where regulation pushes the other way.

For investor and earnings webcasts, the SEC's Regulation FD release accepts a webcast as satisfying public-disclosure obligations only when it is "reasonably designed to provide broad, non-exclusionary distribution of the information to the public," with adequate advance notice and open access. Selective access to a known audience is close to the thing the rule exists to prevent.

That is United States securities regulation and does not directly govern a Canadian issuer's obligations, which sit under National Instrument 51-201 and provincial securities law — we have not verified those here and are not going to claim they are identical. The transferable point is narrower and still useful: for some categories of event, gating the stream is a liability rather than a precaution, and that is worth checking before it is treated as the safe default.

Decision three: where production happens

The choice between crewing on site and running a remote production changes what can go wrong, more than it changes what the audience sees.

A remote broadcast — the REMI model — keeps cameras and contribution encoders at the venue and moves switching, graphics and output elsewhere. Less equipment and fewer people travel. In exchange, the venue's upload path becomes a single point of failure — and venue internet is almost always specified around download, because that is what guests use. Asking a venue for "good Wi-Fi" and getting a confident yes tells you nothing about the number that matters here.

This is also why contribution protocols designed for unreliable networks exist. SRT is built specifically to carry a stream reliably over the public internet rather than a managed link, which is precisely the situation a remote production is in.

Onsite streaming inverts the trade: more kit and more crew in the building, less exposure to the venue's connectivity, and problems that can be solved by someone standing next to the equipment. Neither is more professional than the other. They fail differently, and the right question is which failure you can better tolerate on the day.

Decision four: what is still recoverable afterwards — and the obligation it creates

This is the decision most often made by accident, and the one with a consequence nobody expects.

Under Ontario's Integrated Accessibility Standards Regulation, O. Reg. 191/11 s.14(4), designated public sector organisations and large organisations — 50 or more employees in Ontario — must meet WCAG 2.0 Level AA, with exactly two named exemptions: success criterion 1.2.4, Captions (Live), and 1.2.5, Audio Descriptions (Pre-recorded).

Prerecorded captions — success criterion 1.2.2 — are not exempt.

So: stream an event live without captions, and under this regulation a large organisation is within its obligations. Publish the recording afterwards, and that content is no longer live. It is prerecorded web content, and the exemption that covered the broadcast does not cover the file.

The decision to "just post the recording" is therefore not a distribution choice. It can create a captioning obligation the live event never had. We set out the rest of what the AODA actually requires, including who the exemption covers and who it does not, because the answer depends on which organisation is asking.

The good news is that post-event is the easier place to caption well. Live captioning has to be produced in real time; a recording can be captioned against a fixed file and corrected. W3C's own rationale for treating 1.2.4 differently rests on exactly that distinction.

On accuracy, we will be careful. The pattern across captioning-service sources is that real-time ASR sits somewhere in the 80s to low 90s on clean audio, professional live stenography in the high 90s, and post-production transcription higher again. Those are industry-typical figures repeated across vendor sources rather than findings from a controlled study, and we would not present them as measurement. The directional point is safe and is the one that matters: captioning a recording is more accurate than captioning the same content live, because errors can be fixed. If accuracy is the requirement, that is an argument for doing it afterwards — or for using a human captioner rather than ASR if it has to happen live.

What we are not going to tell you

A great deal of streaming advice rests on engagement statistics. We went looking for the common ones.

On-demand viewing exceeding live viewing is widely asserted at ratios from 2× to 2.4×, depending on who is selling. Every figure we found traces to platform or webinar-vendor benchmark reports with inconsistent methodology, and no independent research confirmed any of them. The direction is plausible and matches most people's experience. The multiplier is not something we can stand behind, so we are not repeating one.

The "eight-second attention span, shorter than a goldfish" claim is worse than unverified — it is debunked. It traces to a 2015 Microsoft Canada report citing an aggregator whose underlying research a 2017 BBC investigation could not locate, and the academic work sometimes cited alongside it does not contain the figure. If a production recommendation is justified to you on that basis, the recommendation may still be fine, but the justification is not.

Working it through

Four questions, in the order that saves the most money:

1. Does anything in the run of show depend on real-time reaction? If not, you do not need low latency, and you should not pay for it.
2. Who must be able to watch, and who must not? Then pick the mechanism that actually enforces that — and check whether your category is one where broad access is the requirement rather than the risk.
3. Can the venue reliably push a contribution feed out? Ask about upload, not "the Wi-Fi." The answer decides whether remote production is available to you.
4. Are you publishing the recording? If so, budget for captioning it properly, and know that for a large Ontario organisation this is where the obligation attaches.

Most events answer "no, known audience, yes, and yes" — which points at a gated stream at ordinary latency, produced remotely, with the recording captioned properly afterwards. That configuration is unglamorous and usually correct.

If you are planning something and want a second opinion before committing, our streaming solutions cover the broadcast side and our rental and event services cover the room and crew. Tell us what you are planning.