This guide provides a brief overview of broadcasts and streams. It also discusses use cases that show how broadcasters use the YouTube Live Streaming API to create and manage those resources.
A broadcast represents an event that can be watched on YouTube as it happens. Each broadcast is a distinct YouTube video. A broadcast can be and needs to be bound to exactly one stream.
A stream enables you to transmit audio-video content to YouTube, and it defines the settings for how you stream your content to YouTube. The same stream can be bound to up to three live broadcasts. It is also common for broadcasters to reuse the same stream for many different broadcasts if those broadcasts occur at different times.
The remaining sections present three use cases that explain how API users typically use broadcasts and streams.
Configure a single encoder
In the most common API use case, your YouTube channel has a series of scheduled or recurring live events. As the channel owner, you have a single encoder and only want to configure the encoder one time. So, you create one
liveStream resource in the API and then use the content delivery settings from that resource to configure the encoder for the channel. (Note that, if you have multiple channels, you must create a different stream for each channel.)
You then create
liveBroadcast resources in the API and bind all of those resources to the
liveStream resource. In this scenario, every live event that you schedule for your channel uses the same streaming settings. However, only one event is live at any given time, and the video content for each broadcast is unique.
Any time an event occurs, you update the broadcast's status to either
live and proceed to broadcast that event on YouTube.
Create one stream per broadcast
Another common approach is to create a separate stream for each broadcast. In this scenario, you would create a distinct
liveStream resource for each
liveBroadcast resource and then configure your streaming encoder to use the appropriate settings for each broadcast.
This approach might make sense if your channel has multiple recurring broadcasts such that two broadcasts might occur simultaneously, making it infeasible for both broadcasts to use the same streaming settings. In fact, your channel might treat each recurring broadcast as a show and just create one
liveStream resource per show. Then, each episode of the same show would represent a broadcast, and all broadcasts of the same show could be bound to the same stream.
Use one stream to create simultaneous broadcasts
In this scenario, you want to split a live stream into multiple, simultaneous broadcasts. As such, you have one
liveStream resource that is bound to two (or more)
liveBroadcast resources that have a
live status at the same time.
For example, suppose your channel broadcasts a 24/7 live feed, but you also want to create a separate video for an interview that occurs during that broadcast. In this case, the interview content is a subset of the 24/7 broadcast's content.
To handle this case, you create two
liveBroadcast resources and bind both broadcasts to the same stream. The 24/7 broadcast is ongoing and its resource has a
live status long before the interview begins. When the interview begins, you update the status of the resource associated with the interview to
live without changing the 24/7 broadcast's resource. Thus, you are streaming the same content to two separate videos at the same time.
When the interview ends, you update the interview broadcast's resource again, this time setting its status to
complete. However, you don't stop streaming video since the 24/7 broadcast continues.