A practical way to run one continuous YouTube feed is to place the source file on a Mumbai-region cloud VM, run FFmpeg there, and publish directly to YouTube Live over RTMPS. Your computer can then be switched off, but the VM, encoder process, source file, network path and YouTube ingest connection still need checking and recovery plans.
This pattern suits a single looped devotional video, bhajan playlist, ambience file, local information loop or study channel. It is different from Google's managed Live Stream API: the API has a documented session limit, while the reviewed documentation does not establish that the same limit applies to a direct FFmpeg process publishing from a VM.
Choose a Mumbai VM and validate it first
Mumbai is a useful starting point when your audience, operator or other cloud resources are in India, but a region name alone does not tell you whether the machine you need is available. Google Cloud identifies Mumbai as asia-south1 in its Live Stream API location documentation. That confirms the managed API location, not the availability of every compute family or every VM size in that region. Check the exact SKU, operating system image, attached storage and network options in the provider's console before designing around it. See Google's regional location guidance for the factors it asks operators to consider.
For a direct VM encoder, compare the following rather than choosing a region only because it is geographically close:
| Decision | What to check | Why it matters |
|---|---|---|
| Region | Mumbai availability for the exact VM family | The chosen CPU and storage combination may not be offered in every region |
| CPU | Measured load while encoding your real file | Transcoding can use substantially more CPU than copying compatible streams |
| Memory | FFmpeg, the operating system and any monitoring process together | A source file or process that exhausts memory can stop the feed |
| Storage | Space for the source, temporary files and logs | A full disk can prevent downloads, writes or useful diagnostics |
| Network | Stable outbound route and permitted RTMPS traffic | The VM must maintain a connection to YouTube on port 443 |
| Recovery | Reboot behaviour, process restart and operator access | A machine that starts but does not start FFmpeg is not a finished setup |
Do not claim that a particular CPU or memory size is universally sufficient. The workload depends on the source resolution, frame rate, codec, audio, output settings and whether FFmpeg is decoding and re-encoding or passing compatible streams through. Start with a small test VM if appropriate, then measure the actual process while it runs for longer than a short preview.
The most important test is not a speed test from your home connection. It is a real publishing test from the selected region. Upload a representative file, run the encoder, watch CPU and memory use, and check that YouTube receives a stable feed. Repeat after a reboot. If the exact Mumbai SKU is unavailable, choose another region only after considering latency, cost, support access and the effect on your audience. Do not present a different region as equivalent without testing it.
A cloud VM also creates costs beyond the machine itself. Your estimate may need compute time, attached storage, outbound data transfer and any managed service charges. The exact figures depend on the provider, region, VM type, bitrate and duration, so calculate them from the selected provider's current console rather than copying a figure from an unrelated setup.
Check channel eligibility and create the YouTube event
Before installing FFmpeg, confirm that the YouTube channel can use live streaming and that the required verification or activation steps have been completed. YouTube's live streaming help is the right place to check the current requirements. These requirements and account checks can change, so a working VM does not by itself make a channel eligible to broadcast.
Open YouTube Live Control Room and create the broadcast or scheduled event. For a first test, use a private or unlisted event rather than sending an untested feed to your public audience. Choose the visibility, title, description and category that match the actual content. If you are looping archived services, music, adverts or other material, check the current YouTube policies and rights position separately. Technical delivery does not settle questions about copyright, reused content or channel suitability.
The event gives you the ingest details that FFmpeg needs. Copy the secure RTMPS server URL and stream key from Live Control Room. YouTube may show an ordinary RTMP URL by default, so explicitly reveal and select the secure option where the interface provides it. YouTube describes RTMPS as RTMP carried inside TLS and uses port 443 for the secure connection.
Treat the key like a password. Do not put it in a screenshot, public tutorial, ticket, shell history, shared document or world-readable configuration file. Avoid placing it directly in a command that will remain in a process list or terminal recording. If you believe it has been exposed, replace or reset it in YouTube and update the encoder configuration.
You can use a scheduled event if you want the page prepared before the feed starts. The important distinction is between the YouTube event and the publishing process: creating the event does not make the VM send video. FFmpeg must still be running, connected to the correct destination and producing an accepted video and audio stream.
Put the source file on the VM and configure FFmpeg
Transfer one representative source file to the VM and inspect it before attempting a long run. Check its duration, dimensions, frame rate, video codec, audio codec and whether it contains a continuous audio track. A file that plays correctly in a desktop player can still expose timing, codec or audio problems when looped by an encoder.
Keep the source in a controlled directory with permissions that allow the encoder account to read it but do not expose it unnecessarily. Keep logs somewhere with rotation or a retention plan. If you download replacement files automatically, make sure a partial download cannot be mistaken for the active source. A simple approach is to download to a temporary name, verify the file, then rename it into place while FFmpeg is not reading that particular file.
Google's documentation uses sudo apt install ffmpeg as an installation example. The package name, available version and exact command depend on the operating system image, so follow the selected image's package guidance and confirm the installed version. Do not assume a command written for one distribution will behave identically on another.
For a looped file, the core pattern is to read at normal playback speed, repeat the input indefinitely and publish to the YouTube RTMPS destination. AWS's official FFmpeg streaming example demonstrates the -re -stream_loop -1 -i pattern for a recorded video and an RTMPS endpoint. It is useful evidence for the loop mechanism, not a YouTube-specific command or a guarantee for your VM.
A starting shape is:
ffmpeg -re -stream_loop -1 -i /srv/channel/source.mp4 \
-c:v libx264 -preset veryfast -b:v VIDEO_BITRATE \
-maxrate VIDEO_BITRATE -bufsize BUFFER_SIZE \
-pix_fmt yuv420p -g KEYFRAME_FRAMES \
-c:a aac -b:a AUDIO_BITRATE -ar 48000 \
-f flv "rtmps://YOUTUBE_ENDPOINT/STREAM_KEY"
Treat the values in capitals as decisions, not values to paste blindly. The keyframe interval depends on the output frame rate, so a two-second interval means a different -g value at different frame rates. YouTube recommends a two-second keyframe interval and says not to exceed four seconds. Its current encoder settings guidance also covers supported codecs, frame rates, audio and constant bitrate encoding.
YouTube recommends CBR and asks operators to match the bitrate to a reliable upload connection. Select the output resolution and bitrate from the current YouTube table, checking the codec column and labels on the rendered page before using an exact figure. Do not repeat a bitrate from a copied table if the page presents conflicting or ambiguous values.
If the source already has suitable codecs and timing, copying may reduce CPU use, but compatibility must be tested. Re-encoding gives you control over output dimensions, frame rate, keyframes and audio, while increasing CPU work. A 1080p source re-encoded continuously is a different workload from a compatible file copied into the output container. Benchmark the setting you will actually run.
Before making the event public, run the command with the real file and examine the output. Look for repeated input playback, regular video frames, an audio stream, encoder errors and a stable connection. Do not put a real key in a public code sample or log. Use a protected environment variable or a restricted configuration method appropriate to the selected operating system, and inspect permissions before starting a long session.
For practical format decisions, the bitrate and format guidance for a nonstop church stream is relevant even if your channel is devotional, musical or informational. It should supplement, not replace, the current YouTube documentation.
Send the single feed directly to YouTube Live
The publishing path is deliberately simple:
source file on VM → FFmpeg process → RTMPS over port 443 → YouTube Live event
This is a single outbound feed. The VM is not automatically a distribution system, a multi-rendition transcoder or a backup broadcaster. If you need several resolutions, several destinations or remote production features, compare this arrangement with a managed live service instead of adding complexity without testing it.
Start with an unlisted or private event. Copy the RTMPS server URL and key from that event, combine them in the encoder's destination format, and confirm that the final URL is not being altered by shell quoting or configuration parsing. A missing slash, copied whitespace or wrong event key can look like an encoder failure when the actual problem is the destination.
YouTube's ingest service receives the feed over the network path available to the VM. A Mumbai VM does not guarantee that the route to YouTube will remain healthy, and it does not remove the possibility of an ingest-side issue. Watch the encoder's connection messages and YouTube's stream-health panel together. One may show a successful socket connection while the other reports missing frames, audio or an unsuitable stream.
If you are moving from a local OBS setup, the change is operational rather than merely geographic. A local encoder exposes a desktop, power supply and home connection as failure points. A VM removes the need to keep that computer switched on, but introduces cloud credentials, provider access, disk management, remote logging and recovery after reboots. The OBS worship-stream guide can help you compare the operating assumptions, although its workflow is not the same as a direct VM publisher.
For a single loop, avoid adding a playlist scheduler until the basic feed is reliable. First prove that one file can play, repeat and reconnect. Then decide whether you need song changes, title changes, overlays or scheduled transitions. Each added component creates another place where a restart can stop the feed or produce an unexpected output.
Preview the event and monitor what is actually happening
A successful FFmpeg command is not enough. Preview the private or unlisted event in Live Control Room and check that YouTube reports the expected video and audio. Watch for black frames, frozen motion, missing audio, lip-sync drift, excessive keyframe spacing and warnings about stream health. YouTube recommends testing before starting and checking messages during the event.
Use a short checklist before changing visibility:
- The event is the intended event, not an older test.
- The stream key belongs to that event or its configured stream.
- The video is the expected resolution and frame rate.
- Audio is present at a sensible level and does not clip.
- The loop returns to its beginning without an unwanted blank interval.
- The VM has enough CPU, memory, disk space and outbound capacity.
- FFmpeg logs show a continuing process rather than repeated exits.
- You can reconnect to the VM using a separate session.
- You know how to stop the process without leaving two publishers running.
For a 24/7 channel, monitoring should cover more than whether a process exists. A process can remain alive while the source is stalled, audio has disappeared, the output is dropping frames or YouTube is no longer receiving usable data. Record basic health information such as process state, recent log activity, CPU and memory pressure, disk space and network errors. Set a human review routine even if you also use automated alerts.
YouTube's live encoder settings and troubleshooting page should be checked again when warnings appear, because accepted formats and recommendations can change. Keep a note of the exact source, FFmpeg version, output settings and event configuration used for the test. This makes a later failure easier to reproduce.
If your source is a collection of files rather than one prepared programme, normalise the files before publishing. Mixed dimensions, frame rates and audio layouts can create visible jumps or require the encoder to make decisions at each transition. The advice on making playlist videos consistent applies to this problem even though the encoder here runs on a VM instead of inside OBS.
Plan recovery for every failure point
A 24/7 target is an operating plan, not a command-line option. List what happens if each layer fails and test the response deliberately. The main failure points are the process, the VM, the source, the network path and YouTube's ingest connection.
Process failure. FFmpeg can exit because of a malformed source, an input read error, an invalid option or a lost connection. Arrange for the process to be started after a reboot and restarted after an unexpected exit, using a service manager or container method that you have tested on the chosen operating system. Do not copy a generic unit file into production without checking its user, paths, permissions, environment variables and restart behaviour.
A restart policy can create a loop of rapid failures. Add logging and a sensible delay, then investigate why the process stopped. Make sure a restart does not launch a second copy while the first copy is still connected. Keep the stream key out of world-readable service files and avoid logging the complete destination URL.
VM failure. The machine can reboot, become inaccessible, run out of disk space or fail at the provider level. Confirm that your source is stored persistently and that you can rebuild the encoder configuration from a protected record. Keep a second copy of the source and configuration outside the VM, but do not store the stream key in an unprotected shared location.
Source failure. A file can be deleted, become unreadable or reach an unexpected end because looping was not enabled. Check the file before starting and monitor for input errors. If you replace it, test the replacement privately. A looped single file is easier to recover than a dynamically assembled playlist, but it also gives viewers the same material repeatedly, so choose the content and loop boundary intentionally.
Network failure. The VM may remain reachable while the route to YouTube is impaired. Watch for reconnect attempts and confirm whether FFmpeg exits or remains blocked. A process restart may restore a connection, but it may also create a new interruption. Test the behaviour rather than assuming that a retry option provides uninterrupted service.
YouTube ingest or event failure. A valid key can still be attached to the wrong event, an event can be stopped, or YouTube can report stream-health problems. Include Live Control Room in the recovery procedure. Decide who is allowed to change visibility, reset a key or start a replacement event, and keep the current event details accessible to that person.
A single VM and a single publishing process have a single failure domain. A second VM or a separate publishing arrangement can reduce some risks, but it also introduces stream-key coordination, duplicate publishers, additional testing and potentially additional charges. Do not add failover merely to claim redundancy. Define which system is active, how the standby is started, and how you prevent both from publishing at once.
If maintaining a VM, logs and restart rules is not the real work you want to do, a cloud-hosted upload-and-publish workflow such as StreamNeo removes the need to keep this particular encoder machine running and monitored yourself. It does not remove the need to choose suitable content, configure YouTube correctly or review the channel.
Do not confuse direct FFmpeg with the managed Live Stream API
Google's managed Live Stream API is a different architecture. It accepts input, creates managed channels and produces configured outputs. Its location documentation includes Mumbai, and its quotas documentation states that a live session lasts 24 hours and that a channel may be restarted after 24 hours when it remains in an active streaming state. Read the current Live Stream API quotas and limits before designing around that service.
That documented limit belongs to the managed API workflow. It should not be applied automatically to a direct FFmpeg process running on a VM and publishing to YouTube over RTMPS. The reviewed sources do not establish that a direct VM process has the same 24-hour session rule. They also do not establish that a direct VM process will run without interruption. Those are separate statements and should remain separate in your design.
Choose the managed API when you need its managed channel and output model, API-controlled workflows, or multiple processing requirements that justify it. Choose a direct VM encoder when one prepared feed is the main requirement and you are willing to own the operating work: source storage, FFmpeg configuration, credentials, logs, monitoring, restarts, VM access and recovery. Compare total cost from current regional compute, storage, egress and managed-service configuration rather than treating either pattern as automatically cheaper.
For a direct VM setup, the sensible acceptance test is concrete: the exact source plays correctly, the chosen encoder settings meet YouTube's current guidance, the event receives a healthy private feed, the process survives a planned restart, and you have written steps for a failed process, VM, source, network route or event. Only then should you decide whether the operating burden suits a continuous public channel.
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 I loop one MP4 on YouTube Live from a Mumbai VM?
Yes. Run FFmpeg on the VM with real-time input reading and indefinite input looping, then publish the resulting feed to the RTMPS URL and key from YouTube Live Control Room. Test the exact file privately or unlisted first, because looping does not fix incompatible codecs, missing audio or timing problems.
Does a Mumbai VM guarantee lower delay or stable streaming?
No. Region selection can affect network distance and operational convenience, but it does not guarantee a stable route, YouTube ingest availability or uninterrupted operation. Confirm the exact VM availability and run a real publishing test from the selected region.
Does the 24-hour Google Live Stream API limit stop direct FFmpeg streaming?
The documented 24-hour session limit applies to Google's managed Live Stream API. The reviewed documentation does not establish that the same limit applies to a direct FFmpeg process publishing from a VM, but that distinction is not a promise of continuous uptime.
What should I do if the stream stops overnight?
Check whether FFmpeg exited, the VM rebooted, the source became unreadable, the network connection failed or YouTube reported an event problem. Use tested restart and logging procedures, keep a protected copy of the source and configuration, and verify the feed in Live Control Room before making it public again.