A JSON schedule can tell a scheduler you operate which video to play next on each of your YouTube 24/7 channels. It is not a YouTube feature: your scheduler reads the configuration, selects a source, and an encoder sends the resulting audio-video feed to YouTube.
Keep three jobs distinct. Your schedule describes content and timing; the encoder transmits media; YouTube's Live Streaming API manages the live event and the stream it uses. Each channel needs its own liveStream resource, even when one system coordinates several channels.
What the JSON schedule controls
Think of JSON as a set of instructions for your own playback system, not as a playlist that YouTube reads. A scheduler can use it to decide which file is due, which channel should receive it, and what to do if the file is missing. YouTube's API can create and manage broadcast and stream resources, but the official documentation does not define a standard JSON rotation format or document a built-in prerecorded-video rotation engine.
That distinction matters when you are planning a channel for devotional songs, a study loop, or a local news recap. Putting file paths and times into a JSON document does not itself play anything. Something must read those entries, open the selected media, and deliver continuous audio and video to an encoder. The encoder, in turn, must transmit the feed using settings associated with the YouTube stream resource.
A useful mental model has three layers:
| Layer | What it decides or does | What it does not do by itself |
|---|---|---|
| JSON configuration and scheduler | Which source to select, in what order, and under which timing rules | Transmit video to YouTube |
| Encoder | Sends the selected audio-video feed | Decide your editorial rotation unless you build that behaviour into the playback system |
| YouTube broadcast and stream resources | Represent the live event and transmission settings, and manage their lifecycle | Read your local JSON file and pick a prerecorded video |
You can run a separate scheduler and encoder for each channel, or have an orchestrator coordinate them. Either way, keep each channel's content queue, credentials, stream resource and running process identifiable. If the scheduler mistakenly hands a devotional video to the news channel's encoder, a syntactically valid schedule will not prevent the wrong output.
If you are deciding between an OBS setup and a command-line encoder, the practical trade-offs are covered in OBS or FFmpeg for an ambient 24/7 stream. Whichever you choose, confirm that it can perform the hand-off behaviour you need; the JSON format does not supply that capability.
Define a schedule format for your system
There is no YouTube-prescribed schedule schema to copy. Define a small format that your own scheduler can validate and explain to another person. Start with the information it actually needs: a channel identifier, an ordered list of video sources, timing or recurrence rules, and a policy for an unavailable source. You can add fields later when there is a clear operational reason.
For example, a schedule might identify a bhajan channel and list three source paths in the order they should play. Another entry might identify a study channel and specify a recurring sequence of lecture files. Those labels and fields are choices for your software, not names required by YouTube. A simplified shape could look like this:
{
"channels": [
{
"id": "bhajan",
"videos": [
"media/morning-aarti.mp4",
"media/evening-bhajans.mp4"
],
"rotation": "in_order",
"missing_file": "skip_and_log"
}
]
}
Treat the example as a design sketch, not a ready-to-run contract. Your scheduler must know what in_order means, how it advances, and whether it repeats the sequence at the end. It must also decide whether paths are relative to a known media directory, whether a source can be used by more than one channel, and how it reports an invalid entry. If you choose to represent a time zone or a daily start time, document the interpretation so a system does not silently use the machine's local time instead.
Validate the file before the channel starts. Check that the JSON parses, that each channel identifier maps to a configured channel, that every listed source exists and is readable, and that the scheduler understands every rotation value. A typo such as inorder may be valid text but invalid for your scheduler. Rejecting an unknown value early is usually easier to diagnose than discovering at night that the queue has stopped.
Set an explicit fallback for missing or damaged media. Skipping and logging the entry is different from holding the last frame, stopping playback, or selecting a known standby file. None is universally correct. For a news loop, an outdated item may be worse than a brief slate; for a sleep-sounds channel, silence may be more disruptive than repeating a safe ambient file. Test the chosen behaviour rather than assuming the encoder will infer it.
Keep credentials out of the schedule. A content manifest is easier to review and back up when it contains media references and playback rules, not secrets. Store each channel's access details in the appropriate protected configuration for your own system. The API's authentication and project setup are separate from your rotation logic; check the current YouTube Live Streaming API getting-started guide for the official requirements before implementation.
Separate broadcasts from streams
The terms sound interchangeable in everyday conversation, but the API distinguishes them. A liveBroadcast represents the live event: the thing viewers encounter as a scheduled or active broadcast. A liveStream represents the audio-video content and transmission settings that an encoder uses. A broadcast is bound to a stream so YouTube knows which incoming feed serves that event.
This is not merely a naming detail. Your schedule can rotate files while the event remains the same, provided your playback and encoding setup keeps a suitable feed going. Conversely, creating a broadcast resource does not select a video or make an encoder send one. Creating a stream resource does not create an event page for your audience. The pieces have to be configured and connected.
Google for Developers explains the relationship in its guide to understanding broadcasts and streams. Read that alongside the Live Streaming API resource documentation when designing a system, particularly if your scheduler will create resources through API calls rather than using resources you prepared manually.
For a planned broadcast, an insert request needs a title, scheduled start time and privacy status. The scheduled start must be in the future and sufficiently near the current time to be reliably scheduled, so do not treat a far-future calendar entry as a substitute for checking the API's current behaviour. If you omit a scheduled end time, the broadcast is scheduled to continue indefinitely. These are event-resource details, not fields that magically control how your local files rotate.
The API also supports broadcast lifecycle operations. That gives your software a way to manage the event's state, but it does not establish a recovery policy for your encoder or prove that a custom process will restart after a failure. Check the current liveBroadcasts documentation before automating state changes, and keep monitoring the actual transmission separately.
Create a liveStream for each channel
For more than one YouTube channel, create or select a distinct liveStream resource for each channel. Google for Developers states: “Note that, if you have multiple channels, you must create a different stream for each channel.” The stream resource carries the transmission settings relevant to the encoder, and the channel boundary must remain clear in your configuration.
This does not mean you must create a brand-new stream resource for every event. The API documentation describes reusing one stream on a channel for recurring broadcasts, as well as using different stream resources for different broadcasts. The choice depends on whether events share transmission settings and how much configuration you want to maintain. Reuse can reduce repeated setup; separate resources can be useful when distinct events need distinct settings or operational separation.
| Pattern | Where it fits | Operational trade-off |
|---|---|---|
| Reuse a stream for recurring broadcasts on one channel | A recurring channel with the same transmission setup | Less repeated configuration, but you must manage which event is bound to the shared stream |
| Use a separate stream for each broadcast on one channel | Events that need distinct transmission settings or separation | More resources and settings to track, but the event-to-stream relationship is explicit |
| Use one stream resource across multiple channels | Not appropriate for a multi-channel design | Each channel requires its own stream resource |
The last row is the point to preserve when you build a multi-channel orchestrator. A single operator can manage several channels, but the software should not treat a stream resource as a global feed that can be bound indiscriminately. Keep a channel-to-stream mapping and verify it before creating or binding a broadcast.
For example, a small business might operate a product loop and a separate local information channel. The scheduler can share application code and a media catalogue, but it needs separate channel configuration, separate stream resources, and distinct transmission state. Do not assume that because both channels use the same encoder software they can share the same YouTube stream resource.
Before automating resource creation, verify account eligibility, channel-specific streaming permissions and API quota in the current official account and API materials. Those details can depend on the account and are not established by the schedule design itself. The official API guide is a starting point, not a substitute for checking the permissions on the channel you intend to use.
Bind broadcasts to the right streams
Binding associates a broadcast with the liveStream that supplies its content. In a multi-channel system, make that association from your explicit channel mapping rather than guessing based on a display name or the order resources were created. Resource identifiers are the reliable references for your own program logic.
A careful setup sequence is easier to reason about when each channel has a small record containing its channel identifier, stream resource identifier, broadcast resource identifier, and current process state. Your scheduler can use that record to check that the broadcast it is about to operate belongs to the expected channel and that the encoder is configured for that channel's stream. The record is your own operational model; do not present it as a YouTube-defined JSON schema.
Before relying on the binding, test with an unlisted or private event where appropriate for your workflow. Confirm that the event uses the intended stream and that the encoder's feed arrives on it. Check the current privacy options and the account's permissions before choosing them. A correct API call can still be attached to the wrong resource if your local mapping is stale, so log the resource identifiers and the channel label together.
If you have one recurring broadcast per channel, it may be tempting to create and bind everything once and forget it. That reduces routine work, but it does not eliminate the need to observe the event and transmission state. A changed stream setting, an expired permission, or a stopped encoder can interrupt the outcome even though the JSON file remains valid. Keep the API resource lifecycle and the media process visible as separate status checks.
Have a scheduler select the next video
The scheduler is the part that turns entries into a sequence. It reads the channel's ordered sources, determines which item is next under your timing rules, and hands that source to the playback process. You need to decide what “next” means: play entries in order and repeat, move to a new daily block at a set time, or use a queue that an operator can update. The chosen rule should be simple enough to inspect when something unexpected happens.
Do not assume that changing the source is a seamless operation. The transition depends on the playback system, the media files, and how the encoder receives them. One file may have a different frame rate, resolution, audio channel layout or codec from the previous one. Test representative transitions, including the last item back to the first, on the exact system you will use. The API documentation does not specify playlist hand-off behaviour or guarantee uninterrupted transitions.
Build state into the scheduler so it can explain its choice. A useful log entry might record the channel, selected source, time of selection and result of opening the file. If a file fails to open, record whether the configured fallback was applied. A log turns “it showed the wrong video overnight” into a question you can investigate: did the scheduler choose the wrong entry, did the path fail, or did the encoder continue sending an earlier source?
For an OBS-based workflow, test the media source and playlist behaviour instead of assuming YouTube will advance files. The common failure where a source repeats rather than following the intended sequence is discussed in why OBS replays the same video instead of the playlist. If your setup depends on a playlist hand-off, verify it with a long enough test to cover the transitions you expect, not only the first file opening.
Keep the content queue separate from broadcast metadata. A video rotation does not necessarily require a new broadcast for every file, and a new broadcast does not itself choose the next file. If you are also changing titles or thumbnails between events, manage those as a separate publishing decision; the process is not the same as rotating the media feed.
Send the feed through an encoder
After the scheduler selects a source, an encoder program must send the audio-video feed to YouTube. Google's live-streaming overview gives FFmpeg as an example of an encoder program. The specific command, playlist mechanism and transition behaviour depend on the encoder and scheduler you choose; the API resource documentation does not define those details for you.
Configure the encoder with the transmission settings associated with that channel's liveStream, and keep the stream key or equivalent sensitive setting protected. Do not paste one channel's credentials into another channel's process just because both pipelines are running on the same computer. Make the relationship between the selected source, encoder process and stream resource explicit in your configuration and logs.
Then test the complete path: scheduler reads the JSON, chooses a real file, the playback process opens it, the encoder sends audio and video, and the intended YouTube broadcast receives the feed. Confirm that audio is present and at a useful level, that the picture is the expected one, and that a transition behaves acceptably. A local preview alone does not prove that the YouTube event is receiving the correct stream.
Your upload connection and playback machine also matter. If the encoder depends on a home connection, a brief network interruption can affect the outgoing feed; if you use a spare PC, it remains part of the operating plan. Our guide to streaming devotional songs from a spare PC covers practical considerations for that kind of setup. For a system that must run while your own computer is off, StreamNeo removes the specific burden of keeping a local playback machine switched on by turning an uploaded video into a YouTube live stream; it is YouTube-only, so it does not replace a custom multi-channel scheduler when that is what your workflow requires.
Monitor the encoder and the broadcast independently. A broadcast's API state can indicate lifecycle progress, while process monitoring can tell you whether your encoder is still running; neither alone confirms every viewer-facing detail. Decide who or what checks for a stopped process, a missing source, or a feed that is no longer arriving. Test how your chosen system behaves after a restart and do not assume that recovery is automatic unless you have verified it.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does YouTube have a JSON schedule format for rotating prerecorded videos?
The official YouTube Live Streaming API documentation describes broadcast and stream resources, their binding, and lifecycle management; it does not define a standard JSON schedule format for rotating local files. You define a format that your own scheduler can read, then test that scheduler's selection and hand-off behaviour.
Can one liveStream resource serve all my YouTube channels?
No. Google for Developers says that accounts with multiple channels must create a different stream for each channel. Your software can coordinate all the channels, but maintain a distinct stream resource and clear configuration for each one.
Is a liveBroadcast the same thing as a liveStream?
No. The broadcast represents the live event, while the stream represents the incoming audio-video content and transmission settings. Bind the event to the appropriate stream, then have an encoder transmit the selected media feed.
Will changing the JSON entry guarantee a seamless video transition?
No. The schedule can tell your system what source to select, but the result depends on the scheduler, playback software, files and encoder. Test actual transitions and define a fallback for missing or incompatible media.