Deciding before the event: recording a live stream and what to do with the replay

Every decision that matters about a live recording is made before anyone is watching. Recording is opt-in for each stream and depends on your plan; if it was not enabled in advance, the broadcast is not recoverable afterwards, because with recording off the output is discarded rather than kept.

So the useful question is not “how do I get the recording later” — there is no later. It is “what do I have to confirm before the event, and what will I actually be holding when it ends”.

The pre-flight decision, in three parts

Treat these as part of the same five minutes that checks the ingest URL and the stream key.

1. Confirm your plan includes recording. Recording is plan-gated. Your account’s entitlement is not only checked when you switch the option on — it is checked again when the recording is uploaded, so a plan change between those two moments matters.
2. Enable recording on that specific stream. It is a per-stream setting, not an account-wide default, and it is made before you go live. A stream left with recording off produces nothing.
3. Nominate the destination video project. The destination is part of the decision to record. You do not pick it afterwards from a list of finished recordings; the destination is part of enabling recording.

If any one of the three is missing, the event runs perfectly and leaves nothing behind.

The destination project has four rules

The project you nominate has to satisfy all four, both when you set it and again immediately before the upload. If it has stopped satisfying them in the meantime, the upload does not proceed.

The “again immediately before the upload” part is the one to plan around. A tidy-up that archives an old project the week of an event is enough to block the upload, and nothing about enabling recording earlier protects you from it.

One thing the destination does not do: it does not pass its own settings, access rules or reporting onto the recording. Choosing a project decides where the video is created. Everything you want applied to that video is configured on the video, exactly as it would be for an upload.

What arrives afterwards

During the broadcast the stream is captured as recording segments. Each completed segment is uploaded into the destination project on its own and becomes one video library item — so a recorded broadcast may create one or more videos there.

Plan for the plural. Do not build a post-event workflow, an email or a course page around the assumption that a single file will appear, and do not assume a given broadcast length produces a given number of videos: segment duration is deployment configuration, not a published figure. The container format is deployment configuration too, so plan around “a video in the library” rather than around a particular file type.

Uploading is a separate step from capture. A segment is uploaded once it has completed, and the last one once the publisher session has closed — which means a recording can start arriving before the broadcast has finished. The place to confirm a recording is the destination project itself.

Nothing is published on your behalf

Arriving in a project is not the same as being announced. What the replay is called, who is allowed to watch it and which page it appears on are decisions you make on the video, exactly as for anything else in your library. That is a feature — an unedited broadcast with a false start at the top is rarely the thing you want auto-published — but it does mean the replay has a second owner-side step that has to be scheduled alongside the event, not discovered afterwards.

A practical sequence: confirm the recording arrived in the destination project, decide whether all segments are wanted, name them for the way people will search your library rather than for the event’s internal codename, set access to match the audience the replay is for, and only then place the embed.

What can and cannot be fixed afterwards

One of these is final. The other two are not necessarily final, but neither is self-healing.

• A broadcast that ran with recording off. There is no capture to recover. This one is final.
• A destination that had become invalid at upload time. If the project no longer satisfies the four rules when the recheck runs, the recording is not uploaded to it. That blocks the upload; it does not by itself mean the recording is gone. Restore the project to a valid state and raise it with support, naming the stream and the destination project, rather than assuming the material is lost.
• An entitlement that lapsed between enabling recording and the upload. The same applies: the upload is blocked, and the position is worth checking with support rather than writing off.

For the second and third cases, treat the outcome as unknown until support confirms it. Do not announce to an audience either that the replay is coming or that it is gone.

If an event genuinely cannot afford a gap, one option is to keep your encoder’s own local recording as well, which does not depend on anything happening on the platform. It also covers the first case, which nothing on the platform side can.

Related decisions

Scheduling and recording are separate choices that are easy to conflate. A scheduled prerecorded broadcast is not recorded because it was scheduled, and a recorded stream is not scheduled because it was recorded. If an event needs both, both have to be set up.

Encrypted HLS is also a separate matter, and a narrow one: it is available only for eligible legacy-engine streams already configured for it, on eligible plans. It cannot be enabled on a new stream created on the current live system, so confirm the specific stream before a sensitive event. Encryption is also not access control — it protects the segment bytes and does not decide who may watch, so viewer authorisation is designed and verified separately.

Frequently asked questions

Does DynTube record every live stream automatically?

No. Recording is opt-in for each stream and depends on your plan. A stream that ran without recording enabled produced no recording, because with recording off the output from that session is discarded.

Can I choose or change the destination project after the stream?

No. The destination is part of enabling recording, so it is set before the broadcast. Once the recording exists as a library video, you manage it like any other video.

Is a recorded broadcast always one video?

Not necessarily. Recording is captured as segments, and each completed segment is uploaded separately and becomes one library video, so a recorded broadcast may create one or more videos that together cover the session.

What happens if the destination project is archived before the stream ends?

The project and your account’s entitlement are rechecked immediately before the upload. If the project is no longer an active, published, video-capable project in the same account and region, the recording is not uploaded to it.

Is the replay published to my audience automatically?

No. The recording arrives as a library video; its title, access rules and placement on your pages are yours to set.

When does the recording start arriving?

Uploading begins once a recording segment or the publisher session has closed, so a recording can start arriving before the broadcast has finished. Check the destination project, and contact support if a recording you enabled is missing.

Where the detail lives

The full lifecycle, the destination rules and the failure-diagnosis path are on the live stream recording page; the wider capability, including how a live stream is created in the first place, is on the live streaming page; which plans include live streaming and recording is on the live streaming pricing page.

Verification boundary

No container format, segment size or duration is stated here, and no completion-time, availability, retention or storage-duration figure is claimed. Your own stream’s settings and your destination project remain the authority for what a specific account, plan and region will accept.