Use one YAML file as a schedule and content manifest, then have a playout controller read it and choose what each outgoing stream shows. YouTube does not read YAML or provide built-in YAML-based playlist rotation across concurrent live streams; each stream still needs its own channel setup and incoming feed.
This pattern is useful when, for example, you want one channel to move from a morning devotional playlist to evening bhajans while another runs a local information loop. The schedule can keep those plans together, but the controller—not YouTube—must turn each time block into an action and send the resulting audio and video to the right destination.
YAML is the schedule, not the player
YAML is a human-readable way to record structured information. A controller can parse a file containing channel identifiers, time zones, time blocks, and references to scenes or media. The file does not itself play anything, connect to a YouTube channel, or change the content of a live feed.
The distinction matters because YouTube’s live system has separate concepts. A liveBroadcast represents the scheduled or active event viewers watch; a liveStream represents the incoming audio and video feed. Google’s overview of broadcasts and streams explains this relationship. A schedule for when to start an event is not the same thing as a schedule for which local media your encoder sends during that event.
Likewise, YouTube playlist objects are collections of videos on YouTube. The YouTube Data API playlist documentation describes operations on those collections; it does not establish that a playlist object selects the live video feed an encoder sends. If your intended content is a sequence of local files, scenes, or sources, the switching belongs in your playout application or an automation layer connected to it.
Treat any YAML design in this article as an engineering pattern rather than a turnkey YouTube feature. Your controller must validate the schedule and translate its entries into actions. You might use OBS scenes as the targets, another playout application, or a custom service that coordinates more than one encoder output. The right choice depends on how much code and ongoing maintenance you are prepared to own.
Model blocks, outputs, and media references
Start with a small data model that makes the controller’s decisions explicit. Each entry should identify the destination it affects, when it applies, and what content or scene should be selected. It should also tell the controller what to do if the requested media is unavailable or a schedule entry cannot be applied.
For example, a simplified manifest might look like this:
timezone: Asia/Kolkata
outputs:
devotional:
channel: devotional-channel
default_scene: devotional_fallback
blocks:
- start: "05:00"
end: "09:00"
scene: morning_bhajans
- start: "09:00"
end: "12:00"
scene: temple_information
study:
channel: study-channel
default_scene: study_fallback
blocks:
- start: "00:00"
end: "06:00"
scene: quiet_study
This is only an illustrative shape. YAML parsers accept different structures, and no YouTube setting requires these particular field names. A practical controller might use a scene name as the reference, while a custom playout system could use a playlist identifier or media manifest. Keep the meaning of each field documented so that editing the file does not depend on remembering undocumented conventions.
Specify a time zone instead of relying on the computer’s local clock. For an India-based schedule, Asia/Kolkata makes the intended clock explicit; an operator elsewhere can convert or interpret it consistently. Decide whether blocks recur every day, apply on selected days, or use actual dates. If the controller supports recurrence, define how a block crossing midnight works rather than assuming a start time and end time belong to the same day.
Make the schedule unambiguous. Decide whether a block’s end is exclusive, what happens in any uncovered gap, and whether two entries for one output may overlap. Usually it is safer to reject an overlap than to let file order silently decide which scene wins. Include a fallback scene or other clear behaviour for gaps; do not assume a missing entry means the previous media should continue forever.
Use stable references rather than fragile descriptions. “Morning bhajans” can be a human-readable label, but the controller needs a known scene name or media path. Validate that each reference exists before a schedule goes live. If a reference points to a local file, test that the controller can read it under the same account and environment it will use during operation.
Choose the playout controller
A controller is the part that turns a time block into a playout action. It might be an automation plug-in operating inside OBS, a script that talks to an encoder, or a separate orchestration service coordinating outputs. In each case, determine where the schedule is parsed, where decisions are logged, and which component actually changes the scene or source.
OBS can be a useful building block when your content is already organised into scenes. The OBS Project’s Advanced Scene Switcher resource page describes time- and media-related conditions and scene-switch actions. Its listing reports a minimum OBS version of 31.1.1 and support for Windows, macOS, and Linux, as listed on the page in September 2026. Those are compatibility details for that resource, not a promise that it imports arbitrary YAML or will run a particular multi-output workload.
The plug-in’s schedule features and a YAML file are separate pieces unless you implement a bridge between them. The project release notes identify a Macro Schedule tab for actions at a given date and time. That can help with timed actions, but the material reviewed does not establish native YAML ingestion. If YAML is your chosen source of truth, you still need a script or other verified integration to read it, validate it, and trigger the appropriate actions.
Compare approaches by the work they leave with you, not by labels such as “simple” or “professional”:
| Approach | Schedule editing | Timed changes | Independent destinations | Ongoing work |
|---|---|---|---|---|
| OBS automation plug-in | Actions are configured in the application; YAML needs a separate bridge if required | Time-based macros or conditions may be available | Confirm how your chosen OBS setup handles separate outputs | Maintain scenes, actions, media references, and plug-in compatibility |
| Custom YAML controller | One manifest can describe several outputs | Your code must parse and trigger each change | Possible in the design, but you must map and test every output | Maintain code, validation, credentials flow, logging, and recovery |
| Manual scene changes | Schedule can be a written reference | An operator changes content at the planned time | Each output still needs deliberate operation | Requires a person to be present and attentive |
A plug-in may suit a single operator who already works in OBS and needs scheduled scene changes. Custom orchestration may suit someone who needs one version-controlled manifest for multiple outputs and has the capacity to maintain code. If a missed change would create a serious problem, build in a way for a person to see the current and next action, rather than trusting an opaque process.
Map each output to its own channel and feed
Think of each channel as a distinct destination with its own live event and incoming feed arrangement. One schedule file can describe several destinations, but that does not mean one YouTube feed automatically becomes several independently controlled channel streams. Google’s broadcast and stream guidance documents the broadcast/stream distinction and describes creating a different stream for each channel in the common multi-channel pattern.
For every output, record a stable internal name, the intended channel, the scene or media set, and the corresponding live setup. For example, the devotional output might map to the devotional channel’s broadcast and stream, while study maps to the study channel’s own broadcast and stream. The controller needs a reliable mapping between a schedule key and the encoder output that is actually sending to that destination.
Keep the event and feed identifiers distinct in your records. Google’s broadcast implementation guide describes creating and associating broadcasts and streams. At an operational level, verify that the right feed is associated with the right event and channel before starting. Do not assume that naming two scenes differently proves they lead to two separate destinations.
The controller may use one OBS instance with multiple configured outputs, separate OBS instances, or another playout arrangement. The sources do not establish how many concurrent outputs a particular computer can sustain, nor do they guarantee that any specific arrangement will be stable. Check the selected application’s documentation and test your actual scenes, media, resolution, audio, network path, and output configuration together. A useful local reference for preparing a modest machine is this guide to setting up OBS for a continuous stream on a low-end PC in India, but it cannot substitute for testing your own workload.
If each output has different audio or visual needs, keep its scenes and fallbacks separate. A single global “current playlist” variable can cause one destination’s schedule to change another destination by mistake. Make output-specific state explicit and log each change with the destination name so an operator can tell which stream changed.
Authorise each destination deliberately
Authorization is not just another YAML field. YouTube API requests operate with the authority of an account, and Google’s Live Streaming API overview describes account authorization as part of using the API. The account that owns or manages the intended channel must provide the appropriate authorization for the broadcast operations being performed. A YAML row that says channel: devotional-channel does not grant that permission.
Set up each channel under the correct account context, then confirm that the authorized account can see and manage the intended live resources. If the same person manages several channels, verify the active channel identity rather than relying on a familiar account name or browser session. If different people manage different channels, coordinate access and authorization through the supported account permissions rather than copying credentials into a schedule file.
Never put access tokens, passwords, or stream keys in the YAML manifest. The schedule is likely to be copied, backed up, edited, or committed to a repository; credentials need a separate protected handling process. Keep only a non-secret output identifier in the schedule and let the controller obtain the required secret through an appropriate local or managed secret store. Limit access to those credentials and document how to revoke or replace them if they are exposed.
Before relying on the setup, run a small authorization check for each destination. Confirm the channel identity, the broadcast/event, the associated incoming feed, and the encoder configuration. Keep the human-readable names aligned with the channel names in your operating notes. A wrong-channel error is easier to catch before an all-night schedule begins than after an operator finds the devotional programme on the study channel.
Test schedules and transitions concurrently
Test the manifest before connecting it to a real audience. A validator should reject unknown output names, scene names that do not exist, missing media, invalid time zones, malformed times, and overlaps where overlaps are not permitted. It should also show the parsed schedule and the next planned transition in a form a person can check against the intended local clock.
Test one output at a time first. Confirm that its scheduled action reaches the expected scene, its audio is present, and the correct channel receives the feed. Then test the outputs together using the actual arrangement you intend to operate. Concurrent testing matters because separate scene changes can compete for shared media, audio devices, network capacity, or controller attention even when their YAML entries appear independent.
Include transitions that happen at ordinary boundaries, such as one block ending exactly when the next begins, and a change after the controller has been restarted. Check what happens when an output has no block, a scene is renamed, a media file is moved, or a schedule entry is edited while the controller is running. Avoid assuming a transition is gapless: timing, buffering, and the behaviour of the playout application need to be observed in your own setup.
For recorded content, check the source files themselves as well as the schedule. Audio levels can vary noticeably between clips even if the controller switches at the right time; these notes on keeping audio levels even across clips in an ambience playlist cover a separate part of the same operational problem. If you have a schedule that reuses older material, verify that each file is still available and appropriate for the relevant destination.
Do a rehearsal that covers the full hand-off between blocks, not just a manual click on a scene. Compare the controller’s log with what the viewer-facing stream shows. If the schedule says one thing and the outgoing picture or sound shows another, stop and resolve the mapping before adding more outputs. Keep a short record of which schedule version was tested and what changed after the test so that edits do not quietly invalidate a previously checked setup.
Monitor and recover from controller failures
A scheduled system needs an operating plan for missed actions as much as a plan for normal changes. Decide who notices a controller process stopping, a stream disconnecting, an authorization problem, or a media source failing. Decide whether the next block should be skipped, retried, or replaced with a fallback, and whether a human must approve the recovery. The correct choice depends on the content and the consequence of showing the wrong thing.
Log enough to reconstruct events: schedule version, output identifier, expected action time, action result, and any error. A useful status view shows the current scene or playlist reference per output, the next transition, and whether that output is connected as expected. A log that says only “schedule ran” is not enough if two feeds are involved and one failed independently.
Plan for restart behaviour. On launch, the controller should determine the current time in the declared time zone, find the block that should be active, and apply or verify that state rather than blindly replaying actions that were scheduled while it was offline. If there is no valid current block, use the stated fallback or alert an operator. After restart, verify that each output returns to the right channel and content rather than assuming the encoder application restored everything correctly.
A network interruption, lost media file, expired authorization, or application update can each require a different response. Test the recovery path in a controlled rehearsal where possible, and keep a manual procedure available. If a reconnect issue is specific to an encoder command or connection, this guide to fixing FFmpeg reconnect errors on a continuous YouTube stream may help you investigate that class of symptom. It does not replace checking the current logs or the official documentation for your own configuration.
If you would rather not keep a home computer running or maintain a schedule controller for a single-file continuous broadcast, StreamNeo can remove that specific operational burden by taking an uploaded video and running it as a YouTube live stream while your computer is off. That is a different workflow from YAML-driven rotation across several independently scheduled destinations, so decide whether you need a multi-output controller or simply a continuous stream from one prepared file.
When you have a stable content plan, choose the operating approach that fits the people and failure procedures available to you.
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
Can YouTube switch the playlist during a live stream?
YouTube does not read your YAML file as a playout instruction, and the sources here do not document a built-in YAML-based playlist switcher. A controller can change the media or scene that your encoder sends; YouTube receives that outgoing feed. Managing a YouTube playlist collection is a separate API task.
How can one schedule control multiple OBS streams?
Give every destination a distinct output identifier and define separate blocks for it in the manifest. Your automation layer must map each identifier to the correct OBS action and feed, then log changes independently. Test the simultaneous arrangement rather than assuming that a working single output proves multi-output operation.
Does Advanced Scene Switcher import YAML schedules?
The project documentation cited here describes timed and media-based automation features, including scheduled macro actions, but does not establish native YAML import. If you want YAML to be the source of truth, plan to build or verify a separate integration that parses it and triggers those actions. Confirm compatibility against the current project page before changing a production setup.
Can I use one stream setup for several channels?
Do not assume that one feed setup serves every channel. Google documents a different stream for each channel in the common multi-channel API pattern, and each destination must be authorised and associated correctly. Verify the channel, event, feed, and outgoing encoder mapping for every stream before depending on the schedule.