Stream recordings of live streams

When playing back a live stream, Mux offers you two options for historical playback. Both options are available at any time; you can switch between the two at will.

1. Non-DVR mode - keep all users "live". Only a small portion of your live stream (approximately 30 seconds) will be exposed to your viewers through your player.
2. DVR mode - allow your users to scrub back to the beginning of the live stream whenever they want in your player.

The 3 Mux concepts we need to understand here are:

• Live streamsAPI: This is the top level live streaming resource. Your stream key maps back to a single live stream. Live streams are reusable. Each Live stream has one or more playback IDs associated with it.
• AssetsAPI: Assets are videos on demand. In Mux, assets get created by either: direct uploads, creating an asset with an input URL, or from recordings of live streams. Each Asset has one or more playback IDs associated with it.
• Playback IDsAPI: Playback IDs are the resource that controls playback. A playback ID may point to either a live stream OR an asset and it can be either public or signed. More information on signed playback IDs is here. A playback ID is the identifier that you use in a `stream.mux.com` URL of the form:

  https://stream.mux.com/{PLAYBACK_ID}.m3u8

  .

DVR mode vs. non-DVR mode

In non-DVR Mode, all users viewing the live stream will be viewing the most recent content. The player will have access to approximately the most recent 30 seconds of content.

In order to use non-DVR mode, construct your playback URL with the playback ID associated with the live stream.

When using DVR mode, the player will have access to your stream's content going all the way back to the beginning of the live stream.

If you choose to use DVR mode, then you should construct your playback URL using the playback ID associated with the live stream's active_asset_id.

Assets created from live streams

Mux will automatically start creating an asset in the background when you begin broadcasting to your live stream. This asset has two purposes:

• You can use the asset directly in order to enable DVR mode playback.
• When the live stream is over, you can use the asset to play back the recording of the live stream.

Since assets are automatically created from every live stream and live streams can be re-used as many times as you want, Mux creates a new asset every time a live stream begins broadcasting. A single live stream can end up producing an indefinite number of assets.

The lifecycle of events produced by a Mux live stream is as below.

1. Live stream begins in status idle
2. Webhook video.live_stream.connected: The encoder has connected. At this point in time the live stream will have a new active_asset_id. The active_asset_id is the ID that points to a new asset that Mux is creating for this live stream.
3. Webhook video.asset.created: The asset corresponding to the active_asset_id from step 2 gets created. This asset has a live_stream_id that points back to the live stream it was created from. This asset does not have any content yet, it is a placeholder that will be getting content from the ingested live stream.
4. Webhook video.live_stream.recording: Mux has started recording the incoming content. The live stream's status will still be idle at this point.
5. Webhook video.live_stream.active: The live stream's state has transitioned active. When in non-DVR mode, the live stream's playback ID can now be used to build a playback URL on stream.mux.com.
6. Webhook video.asset.ready : The asset (active_asset_id) from step 2 and 3 will be "ready" at around the same time that the live stream is "active". This asset only has about 10 seconds worth of content at this point. The duration on this asset reflects the current playable duration. If you are using DVR mode, it is at this point that you can use the active_asset_id to build a playback URL on stream.mux.com.
7. Webhook video.live_stream.disconnected: The encoder has disconnected, and the live stream status is still active. Please note that live streams that do not use the reduced_latency option will enter a reconnect window (defaulting to a duration of 60 seconds) after disconnecting. The encoder can re-connect within this reconnect window and, in doing so, pick back up where it left off with the same active_asset_id. For more information, please consult handling live stream disconnects.
8. Webhook video.live_stream.idle: After the encoder has stayed disconnected for the duration of the reconnect window, the live stream will transition back to status idle. This live stream will no longer have an active_asset_id associated with it. The next time an encoder connects this lifecycle with start back at step 1 with a new active_asset_id.
9. Webhook video.asset.live_stream_completed: This event fires at the same time as the live stream transitions back to idle. This event tells you that the asset is finalized. The duration of the asset will now be the full, finalized duration; you can use the playback ID in your player to play the recording of the live stream.

Please note that some of these webhook events correspond to the live_stream resource and others correspond to the asset.

More information about configuring and using webhooks can be found in the webhooks guide.