To run a prerecorded video as a YouTube Live loop from AWS Mumbai, launch an EC2 instance in ap-south-1, install FFmpeg, then send a real-time loop to the ingest URL and stream key shown in YouTube Live Control Room. The command below is a pattern to adapt and test, not a verified YouTube-specific recipe; the AWS example behind its loop options targets IVS.
This route keeps your home computer out of the broadcast path, but it also leaves you responsible for the instance, credentials, output settings and event lifecycle. Start with a short test, check YouTube’s preview and stream health, and only then decide whether this arrangement suits a long-running channel.
Choose the Mumbai region
In the AWS console, choose Asia Pacific (Mumbai), whose region code is ap-south-1. Check the region selector before creating anything: the instance, its network settings and related resources need to be in the region you intend to operate. AWS’s region list identifies Mumbai and its code.
A Mumbai location may be a practical choice if you are operating from India or want to keep the cloud machine near your intended audience. It does not, by itself, guarantee a particular route to YouTube’s ingest service, lower latency for every viewer, or uninterrupted delivery. Your instance’s available network path, selected ingest endpoint and YouTube’s handling of the stream still matter.
The broadcast is an outbound connection from EC2 to YouTube. You do not need to expose a public web service merely to send a stream. Keep the design narrow: remote administration should be restricted, while outbound access should be sufficient for package downloads and the ingest destination you select.
Before launching, decide what file you will loop, its dimensions and frame rate, and the quality you want to send. These choices influence encoding load and bitrate. Do not choose a machine size from an example alone: measure the workload you actually intend to run.
Create and secure an EC2 instance
Create an Ubuntu EC2 instance in ap-south-1. AWS’s EC2 connection guidance covers SSH and browser-based connection methods. Keep the private key somewhere controlled, and make a note of the instance ID, public address if applicable, operating system and region. A connection failure may be a status-check or access-rule issue rather than an FFmpeg issue.
Use a security group as a boundary, not as a convenient place to open every port. AWS describes security groups as virtual firewalls for controlling traffic to and from instances. For SSH, allow inbound access only from the administrator’s current public IP address where practical. Avoid opening SSH to all IPv4 addresses. If your public IP changes, update the rule deliberately rather than widening it permanently.
The stream itself is sent out from the instance, so do not copy inbound port rules from a tutorial for another media service. In particular, an AWS IVS tutorial may have ports and destinations specific to IVS; those are not YouTube requirements. Permit the outbound network access needed to install packages and reach the RTMPS endpoint provided by YouTube. Review the current AWS security-group documentation and your organisation’s own network policy before changing rules.
Choose authentication and access with the same care. Do not paste private keys into chat, commit them to a repository or leave them on an unprotected shared machine. If you use SSH, check that the instance passes status checks and that the key, username and address match the instance. AWS also documents EC2 Instance Connect and Systems Manager Session Manager as alternatives, depending on your account and configuration.
An EC2 instance does not make the stream self-managing. Updates, disk space, process supervision, billing and recovery remain operational concerns. Make sure you know how to stop the instance, inspect its status and retrieve logs before leaving it to run. A one-file test is a useful first milestone; a permanent loop is a separate operating commitment.
Install FFmpeg and check capabilities
Connect to the Ubuntu instance, update its package information and install FFmpeg using the package method supported by the operating system version you selected. Package versions and enabled codecs can differ, so check what was actually installed rather than assuming that every build includes the same encoders.
Run ffmpeg -version to see the build information and ffmpeg -encoders to inspect available encoders. Look for the video encoder you plan to use, such as libx264, and the audio encoder you need, such as AAC. If the expected encoder is missing, resolve that before creating a long-running process. Do not respond by copying an arbitrary binary from an untrusted source.
Probe the input file before streaming. ffprobe can show its video and audio streams, dimensions, frame rate, sample rate and duration. Check that the file opens from the instance and that it has the audio you expect. A file that plays correctly on your laptop may still be incomplete after upload, encoded in a format unavailable to the installed FFmpeg build, or have an unusual variable frame rate or audio layout.
The machine must both read the source and encode or pass through media in real time. The work varies with codec, resolution, frame rate, filters and whether you transcode. No particular EC2 size is established here as sufficient for every workload. Begin with a short run, observe CPU and memory use, and leave headroom rather than treating a single successful start as proof of overnight suitability.
For a deeper discussion of the loop approach and its limits, see building a 24/7 Indian classical music stream with FFmpeg concat. Concatenating a sequence and looping one file are different jobs, but both require you to test the media transitions and resulting stream rather than trust the command shape alone.
Create a YouTube encoder event
In YouTube Studio, open Live Control Room and create or select the event you mean to broadcast. YouTube’s guide to creating a live stream with an encoder describes the workflow. The precise screens and event options may change, so use the current instructions in Studio rather than relying on an old screenshot or a copied URL.
The event provides a stream URL and a stream key. The key is a credential that allows an encoder to send a feed to your channel; treat it like a password. Do not put the real key in a public script, a screenshot, a shared document or a repository. If you need to store it for an automated run, restrict access to the file or secret store and avoid echoing it into logs or shell history.
YouTube’s encoder settings page recommends RTMPS, its secure extension to RTMP, and lists supported formats and stream settings. Use the server destination shown for your event, and select RTMPS if it is offered for the setup. Do not assume a URL copied from an example or a different provider is the right destination. The route and key presentation can vary in Live Control Room, so follow its current display exactly.
Treat the event and the process as separate pieces. FFmpeg sends media; Live Control Room shows whether YouTube is receiving it and lets you manage the event. Check that the event is configured as intended before sending a test feed, and understand whether you need to start the event manually after the preview becomes available.
If you are preparing a recurring channel, consider how the file and event fit the content plan as well as the encoding plan. A continuous loop can be technically stable while repeating an unsuitable segment or reaching an event lifecycle limit. YouTube says streams under 12 hours are automatically archived; the cited guidance does not establish what happens for longer broadcasts. Check current YouTube limits and plan how you will handle event duration and archives.
Adapt an FFmpeg loop pattern for YouTube ingest
The essential loop pattern is -re -stream_loop -1 -i "$VIDEO": -re paces file input in real time, while -stream_loop -1 asks FFmpeg to repeat it indefinitely. AWS documents this pattern in an FFmpeg example for IVS. That example is not a verified YouTube command, and its destination-specific details must not be carried over as if YouTube had the same ingest configuration.
A schematic command can show where the settings belong without supplying a reusable endpoint or credential:
VIDEO="/path/to/video.mp4"
INGEST="<use the exact RTMPS destination and key format shown in YouTube Live Control Room>"
ffmpeg -re -stream_loop -1 -i "$VIDEO" \
-c:v libx264 -pix_fmt yuv420p -r 30 -g 60 \
-b:v 6M -maxrate 6M -bufsize 12M \
-c:a aac -b:a 128k -ar 44100 -ac 2 \
-f flv "$INGEST"
This is a template to adapt, not a tested recipe. It illustrates an H.264, 720p-at-30-fps-class output target, with a two-second keyframe interval represented by a 60-frame GOP at 30 fps. The bitrate shown, 6 Mbps, is YouTube Help’s listed H.264 recommendation for 720p at 30 fps in the settings reviewed for this article. Confirm the current table and your actual output before using it. If you choose another resolution, frame rate or codec, select the corresponding current recommendation rather than retaining these values by habit.
YouTube’s encoder settings list RTMP/RTMPS transport, H.264, H.265/HEVC or AV1 video, AAC or MP3 audio, and frame rates up to 60 fps. The same page recommends constant bitrate encoding and a two-second keyframe interval, and says not to exceed four seconds. It lists different recommended bitrates by codec, resolution and frame rate: for example, H.264 at 1080p30 is listed at 10 Mbps and 1080p60 at 17 Mbps, while 720p60 is listed at 8 Mbps. Those are settings recommendations, not a promise that your instance or connection will sustain them.
The sample includes -b:v, -maxrate and -bufsize as encoder controls, but your chosen bitrate must reflect the selected output and YouTube’s current table. Match audio and image settings to the material where possible. YouTube recommends stereo audio at 44.1 kHz and 128 Kbps, square pixels, progressive scan and Rec. 709 for SDR. Forcing a frame rate or pixel format without checking the source can alter the image or create unnecessary encoding work.
The INGEST placeholder is deliberately not a canonical URL. Use the exact server URL and stream key format displayed for your event. Because command-line arguments may be visible in process listings and shell history, consider an approach that keeps the credential out of shared scripts and recorded command history. Never publish a command containing a working key. If it is exposed, replace the key through the current YouTube controls.
If you prefer not to keep a home computer running and manually recover a dropped process, StreamNeo removes that specific burden by turning an uploaded video into a cloud-run YouTube broadcast that is monitored and restarted if it drops. It is YouTube-only, so this does not replace an EC2 workflow if you need direct machine access or a different destination.
Run a test and inspect the preview
Start with a short test rather than switching immediately to an unattended loop. Launch the adapted command and watch FFmpeg’s output for input errors, encoder initialisation failures, repeated warnings or a disconnect. A command that remains open in a terminal is not proof that the viewer-facing stream is healthy; confirm reception in Live Control Room.
Wait for the preview and check both picture and sound. Look for a frozen or black image, unexpected stretching, missing audio, clipping, silence or a mismatch between what FFmpeg reports and what YouTube displays. YouTube recommends testing before going live and checking audio and video movement. For a loop, inspect the point where the file returns to its beginning: an abrupt cut may be expected, but a missing frame, gap or audio pop may call for a different edit or transition.
Keep the test representative. A short excerpt can establish that the file opens and the ingest route works, but it cannot show whether CPU stays available throughout a full encode or whether a loop boundary behaves cleanly. Test the selected resolution and frame rate, the actual audio track, and the exact file you plan to broadcast. If you change any of those, test again.
Do not click the event’s final go-live control until you understand what the preview and event settings indicate. Some channel plans involve a scheduled event, while others use an immediate broadcast; follow the current Studio workflow for the event type you chose. If the stream should not be public yet, check visibility and start settings before sending a live feed.
A first successful connection is also an opportunity to verify the credential handling and recovery path. Confirm that the key is not exposed in a public place, that you can stop the encoder cleanly, and that you know how to restart it. YouTube’s encoder workflow says to end a stream by stopping content from the encoder, but review current event behaviour before relying on that as the only shutdown step.
For common FFmpeg input and stream errors, the guide to fixing invalid-data errors when streaming to YouTube is useful when the problem appears before YouTube receives a valid feed. For broader comparisons of ingest approaches, see sending an FFmpeg RTMP stream to AWS media services, while keeping the destination-specific settings separate from YouTube’s.
Monitor the instance and stream
For a live run, monitor two different things: the process on EC2 and the stream as YouTube receives it. On the instance, watch FFmpeg output, CPU and memory, storage availability and network connectivity. In Live Control Room, check stream health and any messages. A process can still exist while the feed has stalled, and YouTube can report an ingest issue that is not obvious from a quiet terminal.
Decide how you will notice a failure when nobody is logged in. A basic setup might use a process manager or a carefully controlled restart mechanism, but automatic restarts do not repair a bad input file, a revoked key, an exhausted disk or an incorrect bitrate. Test the actual recovery procedure: stop the process, confirm what the viewer sees, and make sure you can restore the feed without exposing the key.
Plan for the event lifecycle, too. A loop that continues on the instance does not necessarily mean a YouTube event will remain in the same state indefinitely. The YouTube documentation cited here says streams under 12 hours are automatically archived, but does not establish longer-stream behaviour. Check the current official event and archiving guidance before designing a continuous channel around an assumption.
If you use a long-running instance, account for maintenance. Keep a record of the operating system and FFmpeg version, where the source file lives, how the command is launched, and who can access the key. Make updates during a planned maintenance window and retest after changes to FFmpeg, the file or encoder settings. Keep logs useful but scrubbed of credentials.
An AWS-hosted loop gives you control over the machine and command, with responsibility for its upkeep. It is a reasonable fit when you can administer Linux and need that control. If your real requirement is simply to keep one prepared video broadcasting while your own computer is off, a managed route may remove some operational tasks; compare that convenience with the control you give up. Do not infer uptime from either route without measuring your own use.
If the feed disconnects, first separate likely causes rather than changing several settings at once. Check whether FFmpeg exited, whether the input remains readable, whether CPU or network conditions changed, and whether Live Control Room reports ingest health or a credential issue. The guide to restarting a disconnected 24/7 stream from Live Control Room covers the YouTube-side recovery context. Record what happened before restarting so a repeated failure is easier to diagnose.
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 use an AWS IVS FFmpeg command unchanged for YouTube Live?
No. The documented AWS example targets IVS, so its destination and any service-specific settings are not verified for YouTube. Keep only the general loop idea, then use the exact YouTube ingest destination and key and validate the feed in Live Control Room.
What instance size should I choose in Mumbai?
There is no single size established here as reliable for every file and output. Encoding load depends on the source, codec, resolution, frame rate and filters; test the actual workload and watch CPU and memory before relying on it unattended.
Which bitrate should I use?
Use YouTube’s current encoder-settings table for the codec, resolution and frame rate you select. Its listed recommendations include 6 Mbps for H.264 at 720p30 and 10 Mbps for H.264 at 1080p30 in the settings reviewed here, but check the current official page before publishing.
Does a looped FFmpeg process guarantee an always-on YouTube event?
No. FFmpeg repeating a file does not guarantee that the instance, network path or YouTube event will stay healthy. Monitor the process and Live Control Room, plan recovery, and confirm current YouTube duration and archive behaviour for your event.