To stream a loop video from Azure Blob Storage to YouTube Live, store the source file as a blob, download it to the Azure VM, and play that local copy through an encoder. Blob Storage holds the video; it is not, by itself, a loop-ready live feed to YouTube.
The choice between OBS and FFmpeg depends on how you want to operate the stream. OBS suits a scene-based show that may need human adjustments, while FFmpeg suits a pipeline you can define and repeat in scripts. Neither is a universal reliability winner: the VM, disk, network, media and recovery plan all matter.
Why reliability has no universal winner
A continuous broadcast is a chain of separate jobs. The blob must be available when needed, the VM must have the file and enough capacity to play it, the player must repeat it as intended, the encoder must send the right signal, and YouTube must receive that signal. A failure in any link can interrupt the picture or sound, even if the other components are working normally.
That is why “OBS versus FFmpeg” is not enough to make a reliability decision. It tells you little about whether the VM will run out of disk space, whether a script will restart after a reboot, whether a scene contains the right audio source, or whether the upload connection can sustain your chosen output. The useful question is which workflow makes the likely failure visible and recoverable for the person who will look after it.
Azure Blob Storage should be treated as the source and recovery copy, not as the thing that continuously feeds each frame to YouTube. Downloading the video to VM-local storage separates playback from repeated blob reads. It also gives you a concrete recovery step: after a VM is replaced or its local copy is lost, retrieve the named blob again before starting the broadcast.
If you want a closer look at the FFmpeg side of the decision, the Linux loop-video walkthrough covers that style of workflow. The details of a particular playback command depend on the VM operating system and media file, so check the command against your own installation rather than treating a generic example as a tested Azure recipe.
When OBS fits the workflow
OBS is a reasonable fit when your channel is more like a small production than a single unattended file. You may want to compose a video with a logo, a clock, captions or multiple sources, or to change scenes when a person is present. YouTube’s encoder guidance lists OBS among software encoders, and explains that an encoder can support a more advanced production setup. See YouTube’s encoder guide.
The scene-based approach makes the state of the show visible. An operator can inspect the preview, see which sources are present, adjust a scene, or replace a source without editing a command line. That can be valuable for a local news loop with a live presenter insert, a devotional stream that occasionally needs a title card, or a study channel that alternates between recorded material and a schedule screen.
The trade-off is that a visible interface is not the same as an unattended operating plan. Someone still has to ensure OBS starts after a VM restart, that the intended scene is active, that media reaches its end and repeats in the installed version as expected, and that the stream is actually reaching YouTube. The research for this article does not establish exact OBS loop controls or restart behaviour, so verify these in the version you install and test the end of the file before relying on it overnight.
OBS is less attractive if the only task is to repeat one unchanging video and nobody will be watching the interface. In that case, scene tools may add operational state without solving a real need. They can still be the right choice if you know OBS well and can document a simple recovery procedure for another operator.
When FFmpeg fits the workflow
FFmpeg fits when you can express the playback and output as a repeatable command or managed script. The main advantage is that the desired sequence can be recorded in configuration and started consistently: select the local file, repeat it, encode or pass through the media as appropriate, and send it to the configured YouTube ingest endpoint. This is a workflow advantage, not proof that the stream will fail less often.
A scripted pipeline is easier to reproduce on a replacement VM than a sequence of undocumented interface clicks, provided you keep the script, file path, dependencies and configuration together. You can also have a supervisor or scheduled task relaunch the process after an exit, but that recovery mechanism needs to be configured and tested. It should report failures somewhere you will notice; automatic restart without useful alerts can simply hide a recurring fault.
The cost is that scripts expose more of the setup to the person maintaining them. A changed file path, an expired or reset stream key, a malformed command, or a codec mismatch can prevent the broadcast from starting. A command that runs interactively is not automatically ready for unattended service: confirm it runs under the intended account, after reboot, with the correct permissions and network access.
FFmpeg is a sensible choice for a single prerecorded loop, particularly when you are comfortable maintaining scripts or have someone who can. If you want a command-oriented example outside Azure, see running FFmpeg continuously with Docker. Containerisation and Azure VM setup are separate concerns; do not assume that copying a command from another environment covers identity, local storage, or reboot behaviour on your VM.
Compare operator intervention and automation
Compare the two encoders by the work you expect a person to do, not by a general reliability label. OBS gives an operator a visual production surface and supports intervention while the show is running. FFmpeg gives you a defined pipeline that can be repeated, but changes and diagnosis are more likely to happen through configuration, logs and process management.
| Operating question | OBS workflow | FFmpeg workflow |
|---|---|---|
| What is easiest to inspect? | The preview, scenes and visible sources | The process state, command configuration and logs |
| What suits a changing programme? | A show with scene changes or operator adjustments | A stable sequence that can be scripted |
| What should you rehearse? | Launch, correct scene, media repeat, audio and operator recovery | Startup, file access, repeat behaviour, process restart and alerts |
| What does a replacement need? | A saved profile or scene collection, media paths and operator notes | The script, dependencies, media path and protected configuration |
| Who is likely to prefer it? | Someone comfortable operating a visual interface | Someone comfortable maintaining a repeatable pipeline |
Automation does not remove operational responsibility. With either workflow, decide what happens if the VM reboots, the process exits, the local file is missing, or YouTube reports a problem. Write down who receives an alert and how they can verify the stream. If you cannot be available at the time of an interruption, design around that constraint rather than assuming the encoder will recover every possible fault.
There is also a third operating model: use a managed continuous-streaming service instead of maintaining an Azure VM and encoder yourself. YouTube’s encoder documentation names cloud-based tools for prerecorded-video streaming, but commercial terms, product capabilities and support differ and should be checked directly. If your priority is not operating a VM, a managed service such as StreamNeo removes the specific task of keeping your own computer or VM running the uploaded file as a YouTube broadcast; it does not remove the need to prepare the video, configure the channel and check the result.
Check Azure VM capacity and constraints
Before selecting an encoder, make sure the VM can do the work. Consider the source file’s size, the local disk space available for it, the resources needed for playback and any encoding, and the upstream connection required for the outgoing stream. There is no defensible universal VM size in the evidence for this setup: actual needs depend on the file, output resolution and frame rate, whether you are re-encoding, and the VM configuration.
Start by identifying where the VM’s operating system and account will keep the downloaded file. Leave room for the complete video and any other files or logs the stream needs. Confirm that the account starting OBS or FFmpeg can read the file and that the local disk will persist for the period you expect. If the VM is recreated or its disk is ephemeral, plan to download the blob again before playback rather than assuming yesterday’s local copy remains.
For a first version, download the blob once and play the local copy. This avoids making each playback cycle depend on storage retrieval and makes the file’s presence easy to check. If you choose to fetch it again after a restart, build the retrieval step into startup and make the encoder wait until the download is complete and verified. Otherwise, a boot-time race can leave the stream process attempting to open a file that is not yet present.
Account for the full transfer path, not just the storage line item. Azure charges and service terms depend on factors such as region, tier, operations and data movement; this article does not establish a total cost or a cost-winning tier. Check the current Azure pricing for the storage account and VM regions you intend to use, along with disk, retrieval and outbound transfer charges. Keeping storage and compute in a suitable region may affect latency and transfer costs, but confirm the implications for your account rather than assuming a particular saving.
Store and retrieve the video safely
Create a container in an Azure Storage account and upload the video as a block blob. For a source that must be available promptly, choose an online access tier—Hot, Cool or Cold—based on the anticipated reads and applicable costs. Microsoft explains the access tiers in its Blob Storage access tier overview. Archive is an offline tier: Microsoft says rehydration to an online tier can take up to 15 hours, so do not keep the only immediately needed copy there.
A lifecycle policy can be useful for older assets, but apply it to the actual use of the file. Microsoft’s documentation gives example transitions based on age or access conditions; an example schedule is not a recommendation for a video currently needed on air. Check whether your policy could move the active file into Archive, and keep a recovery copy in an appropriate online tier if prompt restart matters.
For VM access, prefer a managed identity over embedding a storage key or long-lived token in a script. Microsoft documents using AzCopy with a managed identity and specifies the Storage Blob Data Reader role for downloads. Assign the narrowest suitable role scope for the resource, enable a system-assigned or user-assigned identity on the VM, and authenticate AzCopy with that identity. The exact steps depend on your Azure account and deployment, so follow Microsoft’s current AzCopy authorisation guidance.
Download the named blob to the local path your player will use, then verify that the file is readable before launching the encoder. Keep the role assignment limited to what the VM needs: downloading a source file does not require giving the playback process broader storage control. If you do use a SAS token for a specific reason, treat it as a credential, limit its scope and duration, and keep it out of publicly accessible scripts or logs.
Configure YouTube ingest settings
In YouTube Live, obtain the stream URL and stream key for the broadcast and enter them in the encoder. Protect the key as a secret: YouTube describes it as functioning like the stream’s password and address. Do not paste it into a public repository, a support screenshot or an unprotected shared document. If you believe it has been exposed, use YouTube’s channel controls to reset it and update the encoder configuration.
Use the current official encoder guidance for protocol and output settings. YouTube recommends RTMPS, H.264, constant bitrate (CBR), and a two-second keyframe frequency, with keyframes not exceeding four seconds. These are YouTube’s published recommendations, not a guarantee that any particular VM or connection will sustain the stream. Follow the live YouTube encoder settings guide for its current bitrate table and choose a resolution and frame rate that your VM and upstream connection can support steadily.
Avoid copying a bitrate from an unrelated channel as if it were universal. A devotional still-image loop, a lofi animation and a local news programme with movement can place different demands on encoding and bandwidth. Start with the target format you can maintain, then assess YouTube’s stream-health feedback during a representative test. If the connection is unstable, reduce the output demand or address the connection before concluding that the encoder itself is at fault.
YouTube says that first-time live-stream enablement may take up to 24 hours. Treat that as a channel prerequisite to check in advance, not as the expected startup delay for every broadcast. If you are still preparing eligibility or access, the YouTube Live eligibility guide is a useful companion; confirm current requirements on YouTube’s own page because platform rules can change.
Test the chosen workflow realistically
A short test that only proves the encoder can connect is not enough for an overnight stream. Test the full path: retrieve the blob, open the local file, play through its end, observe the repeat transition, verify audio and picture, and confirm YouTube receives the intended stream. YouTube recommends testing before an event and monitoring stream health; use the current live-stream troubleshooting guidance alongside the encoder’s own status information.
Test with representative material rather than a blank screen or a few seconds of audio. Include the loudest and quietest portions, motion, captions or overlays, and any scenes that are part of your real broadcast. Watch for a gap or unwanted silence at the loop boundary. Confirm that the local playback remains in sync and that a long enough run reveals resource or connection problems that do not show up immediately.
Rehearse failure and recovery deliberately. Restart the VM and check that the file can be retrieved, the process starts under the expected account and the correct stream is sent. Stop the encoder process and see whether your documented restart method works. If a download is interrupted, establish how you detect an incomplete file before the player tries to use it. These checks do not prove uninterrupted operation, but they replace assumptions with observed behaviour in your own environment.
Keep a small runbook near the configuration: blob name and path, identity and role scope, how to check the download, where logs or stream-health information are visible, and who can reset the key if needed. Record the date you last verified the workflow and repeat the test after material changes such as a new VM image, different video, changed output settings or encoder update. For other operating models, the always-on spare-PC setup guide can help frame what ongoing machine maintenance involves, even though an Azure VM has different storage and identity steps.
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 loop a video directly from Azure Blob Storage?
Not in the architecture described here. Store the source as a blob, retrieve it to VM-local storage, and use a player or media source that can repeat it before sending the feed through an encoder. Test the actual end-of-file behaviour in your chosen software.
Should I use OBS or FFmpeg for a 24/7 stream?
Choose OBS if you need scenes and expect an operator to inspect or change the production. Choose FFmpeg if the programme is stable and you can maintain a scripted, repeatable pipeline. Your VM capacity, restart plan, monitoring and ability to respond matter as much as the encoder choice.
Is Archive suitable for the video that is currently on air?
It is a poor fit for a file that must be retrieved promptly, because Archive is offline and rehydration can take up to 15 hours according to Microsoft. Keep the active source in an online tier and check Azure’s current costs and conditions for your account. A lifecycle rule should not move the only live copy into Archive unexpectedly.
Do I need to store an Azure storage key on the VM?
For a VM download workflow, managed identity can authorise AzCopy without embedding a storage credential in the script. Microsoft documents the Storage Blob Data Reader role for this download use. Review current Azure guidance and scope access only to the storage resource the VM needs.