A continuous YouTube playlist from Google Cloud usually needs only a running virtual machine, FFmpeg, your media files, and the YouTube server URL and stream key. You do not need Google Cloud’s Live Stream API simply to loop a playlist and send it to YouTube.
The simpler route is to run FFmpeg on a Google Cloud VM and publish its output directly to YouTube. The Live Stream API is a separate, more involved architecture for managed transcoding, HLS or DASH outputs, Cloud Storage workflows, backup inputs, or distribution to other endpoints.
Choose the simpler cloud architecture first
There are two different ways to involve Google Cloud in a live video workflow. The first treats Google Cloud as the place where your encoder runs. The second uses Google’s managed Live Stream API to ingest, transcode, store, and distribute live video.
For one continuous channel, the first route is easier to understand. Your VM holds the files, FFmpeg reads them in sequence, and FFmpeg sends one encoded output to YouTube’s ingest endpoint. You are responsible for the VM, the media, the process, and recovery.
The Live Stream API does not automatically turn a folder of videos into a YouTube playlist. It is not required for a basic loop, and adding it can introduce extra configuration that does not solve the main problem. Google’s Live Stream API overview describes a service for ingesting live signals, transcoding them into outputs such as HLS and DASH, saving outputs to Cloud Storage, and supporting other managed workflows.
Use the direct FFmpeg path when:
- You have one main YouTube destination.
- Your files can be made compatible for continuous playback.
- You are comfortable managing a long-running process on a VM.
- You do not need separate HLS or DASH outputs for other players.
Consider the API when you need managed transcoding, more than one output format, primary and backup inputs, Cloud Storage output, live-to-VOD handling, or distribution to remote endpoints. Those are different requirements from simply keeping a playlist moving.
| Decision | FFmpeg on a Google Cloud VM | Google Cloud Live Stream API |
|---|---|---|
| Main role | Run the encoder and send video directly to YouTube | Ingest, transcode, store, and distribute a live signal |
| YouTube connection | Put YouTube’s server URL and key in FFmpeg | Configure a distribution path if the API output is relayed to YouTube |
| Playlist handling | Prepare the files and loop them with FFmpeg | Not an automatic playlist-rotation feature |
| Useful when | One channel and a straightforward software encoder are enough | You need managed outputs, backup inputs, or wider distribution |
| Main responsibility | VM sizing, process recovery, media compatibility, and monitoring | API resources, inputs, channels, outputs, and destination configuration |
If you are deciding between desktop software and a command-line encoder, the practical differences are set out in OBS vs FFmpeg for looping videos on YouTube Live. A VM-based FFmpeg setup is usually chosen because the computer at home does not need to remain switched on.
Prepare the media and the continuously running VM
Start with the media rather than the cloud machine. A continuous stream can fail at a transition even when the first file plays correctly. Playlist items should have compatible stream layouts when you use FFmpeg’s concat demuxer. Differences in codecs, stream structure, time bases, resolution, frame rate, or audio arrangement can make concatenation unreliable.
For a devotional channel, for example, do not assume that twenty downloaded bhajan videos form a suitable playlist merely because they all play in a browser. Check whether each file has the expected video and audio streams, whether the dimensions are consistent, and whether the audio behaves correctly at the join. The same applies to ambience loops, local news segments, recorded classes, or business announcements.
If the files are not compatible, normalise or transcode them before creating the long-running stream. That creates another workload and may change the machine size you need. It is better to discover this during a short test than after leaving the channel overnight. The FFmpeg documentation on the concat demuxer explains the compatibility conditions and the relevant input behaviour.
Place the media on the VM or make it reliably accessible to the process. A local directory is easier to reason about than a mount that can disappear during a network interruption. If you use remote storage, test what happens when a file takes longer to open or the connection briefly fails.
Create a Google Cloud project and a Compute Engine VM suitable for the media and encoding workload. There is no honest universal machine size for this job. The requirement depends on whether FFmpeg can copy already suitable streams, whether it must transcode, the resolution and frame rate, the number of outputs, and the region and network path.
Benchmark the actual files on the intended machine. Watch CPU use, memory use, disk reads, and network traffic while the busiest part of the playlist is playing. A file that can be copied without re-encoding may need much less processing than a mixed collection that must be converted as it runs.
Do not treat the VM as a one-off terminal session. Run FFmpeg under a service manager or supervisor so that you can define what should happen after a process exit and make the service start after a machine restart. This does not remove the need for monitoring. It gives you a predictable place to inspect logs and restart behaviour.
Keep the stream key out of public scripts, screenshots, source control, and ordinary log output. Anyone who obtains it may be able to publish to the channel. If you share a configuration file with a colleague, remove the key first and replace it after an accidental disclosure.
Create the YouTube encoder stream
In YouTube Studio, open Live Control Room and create or select the live stream that will receive the playlist. YouTube’s official guide, Create a YouTube live stream with an encoder, explains the encoder workflow and shows where the server URL and stream key come from.
The server URL identifies YouTube’s ingest service. The stream key identifies the stream configuration that should receive your encoder feed. They are not Google Cloud credentials, and creating a VM does not generate them. You copy both values from YouTube and enter them in FFmpeg’s output configuration.
If you have never enabled live streaming on the channel, allow for YouTube’s activation process. YouTube says that first-time live streaming activation may take up to 24 hours. Do this before scheduling a night-time launch or moving a channel from a local computer to the VM.
Use an unlisted test stream first if you need to check media transitions, audio levels, and recovery behaviour without presenting an unfinished broadcast to your normal audience. Confirm the preview in Live Control Room, then check the finished stream settings before switching to the intended visibility.
A stream key should be handled like a password. Do not place it in a public Git repository or paste it into a support forum. If your process manager displays the full command to other users on the machine, consider how the key might be exposed there as well.
Configure FFmpeg for a continuous playlist
There are two common patterns. For one input file that should repeat, FFmpeg supports the -stream_loop -1 option. For a collection of files, you can prepare a compatible concat input and loop that arrangement, or use another playlist method suited to the media and transitions you have tested.
A conceptual command shape for one endlessly repeated input is:
ffmpeg -stream_loop -1 -re -i INPUT \
...encoding-options... \
-f flv "YOUTUBE_RTMP_URL/STREAM_KEY"
This is an outline, not a universal production command. INPUT represents a file or a tested input arrangement. The encoding options must match the media and YouTube’s current ingest requirements. The output format shown here is the shape commonly associated with sending an encoded stream over RTMP, but you should verify the current YouTube guidance and your chosen FFmpeg build before relying on a command.
For a multi-file playlist, create a concat input using paths that the VM can read. The files should be compatible for the method you choose. If they are not, transcode or normalise them first instead of expecting the concat demuxer to repair different stream layouts at every transition.
Test the end of every item. A successful first minute proves little if the process stops at the first audio change or video format change. Let the playlist cross several joins, including the join between the last and first items when using a complete loop.
The -re option is relevant when reading file media for a live-style output because the encoder should feed the destination at the intended playback rate rather than exhausting the file as quickly as the machine can read it. Exact flags and ordering can change with the input, the codecs, and whether FFmpeg is copying or encoding streams.
If your channel contains a still image, music, and occasional announcements, decide how those elements should behave before writing the command. A short silence at a transition may be acceptable for a meditation station but not for a news loop. A black frame may be less disruptive than a failed video stream, but it still needs to be tested in YouTube’s preview.
Save the working configuration somewhere private and record the media preparation steps. When a future file is added, you should know which checks it must pass before it joins the production playlist. If you need to diagnose a process that exits after one cycle, FFmpeg YouTube stream stops after one loop: how to fix it covers the distinction between input looping and a process that terminates normally.
Publish with YouTube’s server URL and stream key
Once the playlist works locally on the VM, replace the output placeholders with the server URL and stream key shown in Live Control Room. The credentials belong in the encoder output, not in a Google Cloud API resource merely because the encoder is running on Google Cloud.
Start FFmpeg and return to YouTube’s preview. Check that the expected video appears, the audio meters move, and the stream does not show a growing connection problem. Then watch at least one complete transition. If the preview is black, silent, delayed, or repeatedly reconnecting, stop and resolve that behaviour before making the stream public.
Treat the first launch as an observation period. Record the command output, the time at which the process began, the input file at each transition, and any reconnect messages. These notes help distinguish a YouTube ingest issue from a local media or process issue.
YouTube’s archive behaviour also affects how you plan a long channel. YouTube Help says streams under 12 hours are automatically archived. Do not assume that a single broadcast lasting longer than 12 hours will be archived in the same way. If preserving the programme matters, keep independent recordings or plan a suitable segmentation approach rather than relying on an indefinite archive.
A single continuous broadcast also has editorial consequences. If the channel is a local news loop or a business information screen, stale content can remain live until someone updates the files. A scheduled replacement process or a human review may be more appropriate than an unattended loop, even when the technical stream is still connected.
Monitor the incoming stream and recovery needs
A process that is running is not necessarily a stream that viewers can watch. Monitor both sides: the VM and Live Control Room. On the VM, inspect whether FFmpeg is still running, whether it is reading the expected file, and whether CPU, memory, disk, and network use remain within workable limits. In YouTube, check the incoming preview and warnings.
Set up alerts for the failures that matter to you. Useful signals include the FFmpeg process exiting, repeated reconnect attempts, a full disk, loss of access to the media directory, and a sustained absence of expected network traffic. The exact monitoring tools are a deployment choice, but the checks should be defined before the first overnight run.
Configure a supervisor to restart FFmpeg when it exits, with a sensible delay so that a temporary failure does not create a rapid restart loop. A restart policy is not a fix for a bad playlist. If the same incompatible file always causes the process to fail, automatic restarts may simply repeat the failure.
Test recovery deliberately. Stop the FFmpeg process, restart the VM if your operating procedure allows it, temporarily make a media path unavailable, and observe the result. Confirm that the service starts in the expected order and that YouTube receives a usable feed again. These tests are more informative than assuming a service definition will behave correctly at 03:00.
Keep a small runbook beside the channel configuration. It should identify the VM, the media directory, the service name, the log location, the YouTube stream in use, and the safe way to rotate the stream key. Do not put the actual key in the runbook if the document is shared widely.
If you run a bhajan, Gurbani, or ambience channel, review the content as well as the connection. A live process can continue sending an unwanted or outdated item perfectly. For questions about whether a prerecorded loop is suitable for a particular channel, see Does YouTube allow 24/7 prerecorded live streams?. That is an editorial and platform-policy question, not something Google Cloud can decide for you.
When the managed Live Stream API makes sense
The Live Stream API becomes useful when the channel needs more than a VM-based encoder sending one output. Google describes a workflow in which an encoder sends an input using RTMP or SRT, a channel transcodes that input, and outputs such as HLS or DASH can be saved to Cloud Storage. The API also documents features such as primary and backup inputs, channel events, and live-to-VOD workflows.
That architecture can make sense for an organisation that already has a live production system and needs managed outputs for several destinations. It may also suit a workflow where Cloud Storage copies are part of the delivery design, or where separate output formats are required for applications beyond YouTube.
It is important to separate ingest from distribution. An encoder can send a signal into the API, but getting that signal to YouTube may require a remote distribution configuration using the API output and YouTube’s destination details. Google’s documentation on distributing Live Stream API output describes remote endpoints over protocols such as SRT or RTMP.
This is more configuration than the direct path. You would need to understand the API’s inputs, channels, outputs, permissions, destination compatibility, and operational events. It can be the right design for a managed multi-output workflow, but it is not a prerequisite for a single continuous FFmpeg-to-YouTube channel.
The API also does not remove editorial or platform responsibilities. You still need suitable media, a valid YouTube destination, a safe key-handling process, and monitoring that tells you whether viewers are receiving the intended programme. Read the current Google Cloud documentation and pricing before committing, because the components and usage pattern determine the cost.
For a small operator, the direct VM design is often easier to audit: one machine, one encoder process, one media directory, and one YouTube output. For a larger operation, the additional API structure may be justified by the outputs and recovery model you actually need. Choose based on those requirements, not on the assumption that a more managed product automatically makes a simple playlist safer.
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
Do I need the Google Cloud Live Stream API to stream a playlist to YouTube?
No. You can run FFmpeg on a continuously running Google Cloud VM and send its encoded output directly to YouTube. The API is an optional route for managed transcoding, alternate outputs, storage, backup inputs, or distribution.
Where do the YouTube server URL and stream key go?
They go in the encoder output configuration. Copy them from YouTube Live Control Room and use them in FFmpeg’s destination settings, while keeping the stream key private.
Why does my playlist stop at a transition?
The files may not be compatible for the concat method you are using, or the input loop may not cover the complete playlist. Check the codecs, stream layouts, dimensions, frame rates, and audio streams, then test every join before running the channel unattended.
Can YouTube archive an all-day stream?
YouTube says streams under 12 hours are automatically archived. Do not rely on the same archive behaviour for a single stream lasting longer than 12 hours; keep an independent recording or plan your broadcast structure if the archive is important.