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
testing
or
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.