A self-managed Ubuntu 24.04 VM can send a live or looping video feed to YouTube using FFmpeg, provided its source, encoder settings and sustained outbound connection suit the stream. The essential steps are to verify FFmpeg, select a YouTube Live event, copy that event’s current RTMPS URL and key from Live Control Room, then test the feed before relying on it.
The commands below are practical starting points, not a claim that a particular command or Indian cloud VM has been tested. A prerecorded file, a camera feed and a forwarded live source need different inputs, and no region name by itself tells you whether a particular VM can encode and upload your chosen profile continuously.
Check the VM and channel prerequisites
Start with an Ubuntu Server 24.04 image offered by the VM product in the Indian region you intend to use. You will need SSH administrative access, a source file or a separately configured live input, and a YouTube channel able to create a live event. Check the provider’s own service-specific availability list before choosing a machine type: a region being listed does not establish that your preferred instance is available there.
Examples of Indian locations in provider documentation include AWS Mumbai (ap-south-1) and Hyderabad (ap-south-2), with Hyderabad marked opt-in in AWS’s region table, and Google Cloud Mumbai (asia-south1). These are location examples, not a recommendation or a promise of VM capacity. Google’s cited page is for Cloud Workstations locations, not a Compute Engine availability guarantee. Consult the AWS region table and Google Cloud’s locations list alongside the exact VM product details.
A stream is a sustained workload. Software encoding can use substantial CPU, while upload capacity must remain above the stream’s total outbound bitrate with room for ordinary variation. A short speed test’s best reading does not prove a connection can maintain that rate for hours. Think through five things before provisioning: the input’s dimensions and frame rate, whether you must encode or can simply pass through compatible media, the FFmpeg preset, the stable outbound capacity, and the storage required if the file lives on the VM. Egress billing and storage policy are provider-specific; check the provider’s current documentation rather than inferring cost from the region.
For an always-on loop, decide how the media will reach the VM and what happens after a process exits. A headless machine does not gain access to a camera plugged into your office computer merely because FFmpeg is installed. If you are preparing a fixed video, plan the loop source and file first; for a local news or camera feed, arrange an input path the VM can actually reach.
Install and verify FFmpeg on Ubuntu 24.04
Refresh the package index and install the Ubuntu-packaged FFmpeg:
sudo apt update
sudo apt install ffmpeg
The package manager will resolve the package for the configured Ubuntu repositories. Google Cloud’s Live Stream API setup guide uses sudo apt install ffmpeg as an installation example. That does not mean every Ubuntu image has exactly the same FFmpeg version or enabled codecs, so inspect the executable on your own VM rather than assuming a build detail.
ffmpeg -version
ffmpeg -encoders | less
The first command reports the installed version and build configuration. In the encoder list, check whether the video encoder you plan to use, such as libx264, appears, and whether an AAC audio encoder is available. If it is absent, investigate the image and configured package sources before building a command around it. The output of ffmpeg -encoders lists capabilities; it does not tell you whether a VM has enough CPU or network capacity for a particular workload.
You can also inspect an input before going live:
ffprobe -hide_banner /path/to/input.mp4
ffprobe reports streams, dimensions, frame rate and other media properties when available. Those details help you decide whether to scale or re-encode. If your file is already in a suitable format, re-encoding it anyway consumes CPU without necessarily improving the picture. Conversely, passing through unsuitable video or audio may result in a feed that does not match the event profile.
Create or select a YouTube Live event
In YouTube Studio, open Live Control Room and create an event or select the existing broadcast you intend to use. The interface and event options can change, so follow the current prompts on YouTube rather than relying on an old screenshot or a key copied from another broadcast. A stream key and ingest URL are associated with the live configuration; use the values shown for the event you are setting up.
A livestream may need channel access and event preparation before the encoder can connect. Confirm that the event is the intended one, that it is configured for the format you plan to send, and that the control room is ready to receive an encoder feed. If the channel or event interface reports a prerequisite or restriction, resolve it in YouTube’s current help before troubleshooting FFmpeg.
YouTube’s live streaming setup instructions describe setting up an encoder and locating the server URL and stream key. Keep the event page open during testing: it is where you can check whether YouTube is receiving the feed, inspect the preview and read stream-health messages.
Retrieve and protect the current URL and key
Copy the server URL and stream key shown by Live Control Room for the selected event. Where YouTube offers an RTMPS endpoint, use that endpoint. RTMPS is RTMP transported over TLS/SSL, and YouTube recommends it for encrypted delivery. See YouTube’s RTMPS encoder guidance.
The URL and key are credentials for publishing. Do not put a real key in an article, screenshot, public repository, support ticket, or shell command that could be exposed through shared history or process inspection. A common command places both the endpoint and key in the destination argument; anyone able to read that command or its logs may then see the secret. Restrict VM access, avoid pasting credentials into shared terminals, and redact them when sharing diagnostic output. If a key is exposed, replace or reset it through YouTube’s current controls.
Use a placeholder while drafting, such as RTMPS_URL_WITH_STREAM_KEY, and substitute the exact destination form YouTube presents only in the private environment where you run FFmpeg. Do not assume that an endpoint from a previous event remains correct. If a connection appears to reach a service but then stalls, check that the copied URL is the RTMPS endpoint and that the client is not attempting cleartext RTMP. Google’s Live Stream API troubleshooting guidance identifies protocol mismatch as a possible cause of timeout-like behaviour.
Choose a YouTube-supported encoder profile
Set the event and encoder to a profile that fits the source and your VM. YouTube’s current encoder settings allow H.264, H.265/HEVC and AV1 video, AAC or MP3 audio, and frame rates up to 60 fps. The page recommends constant bitrate (CBR), a two-second keyframe interval and says the interval must not exceed four seconds. Use that page as the final reference because published guidance can change.
Here are two H.264 recommendations from YouTube’s settings table, useful as examples rather than universal targets:
| Output profile | YouTube-recommended H.264 video bitrate | Practical implication |
|---|---|---|
| 720p at 30 fps | 4 Mbps | Lower output demand than the 1080p30 example, but still requires stable upload headroom |
| 1080p at 30 fps | 10 Mbps | Requires more sustained outbound capacity and may require more encoding work |
Those figures are YouTube’s recommended video bitrates for the named profiles, not a measurement of what an Indian VM can sustain. The full table includes other resolutions and frame rates; choose from it for your actual output. Avoid setting your encoded rate equal to the best-case peak from a network speed test. Leave room for variation and remember that the audio stream also uses bandwidth.
For stereo audio, YouTube recommends 44.1 kHz and 128 kbps. Its advanced SDR guidance recommends progressive scan and Rec. 709 colour. A straightforward first setup is H.264 video, AAC stereo, progressive SDR, with the output dimensions and frame rate deliberately chosen. A source with a different aspect ratio may need scaling or padding; inspect the preview rather than assuming a command will frame it as intended. For more resolution and frame-rate examples, use this YouTube Live bitrate reference.
Your choice also affects the machine. With software encoding, a slower preset can demand more CPU than a faster preset; the output rate and source complexity matter too. Do not choose a profile solely because its bitrate appears manageable. If CPU use remains high, frames are missed, or the preview falters, lower the output demand or choose a VM and encoding approach appropriate to the workload, then repeat the test.
Configure FFmpeg to publish over RTMPS
For a prerecorded file, this pattern reads the file in real time, loops it, encodes H.264 and AAC, and publishes using an RTMPS destination placeholder:
ffmpeg -re -stream_loop -1 -i /path/to/input.mp4 \\
-c:v libx264 -preset veryfast -pix_fmt yuv420p \\
-b:v 4M -maxrate 4M -bufsize 8M -g 60 \\
-c:a aac -b:a 128k -ar 44100 -ac 2 \\
-f flv 'RTMPS_URL_WITH_STREAM_KEY'
This is an illustrative starting pattern, not a tested command or a guarantee of suitable output. Replace the path with the actual file and the placeholder with the exact private destination format shown in YouTube Live Control Room. Select bitrate and frame rate to match the profile you chose and the VM’s sustained capacity. In this example, -g 60 corresponds to a two-second GOP only if the output is 30 frames per second. At a different frame rate, calculate the GOP for the two-second interval, and do not exceed YouTube’s four-second maximum.
The example does not set a scale or frame rate, so FFmpeg may use properties from the input. That can be wrong for the selected event profile. If you need a specific output size or frame rate, add suitable filter or output options after checking the source with ffprobe; verify the result in YouTube’s preview. A 4 Mbps video setting here corresponds to YouTube’s H.264 720p30 recommendation, but the command does not establish that the input is 720p30. Adjust it to the profile you actually intend to send.
The -re option paces a file as a real-time source, while -stream_loop -1 repeats it indefinitely. If you are sending a camera or another live input, replace the file input and loop behaviour with the appropriate device or feed options. A cloud VM will not automatically see a local camera or capture card. For a new operator, rehearsing the file-based path first can separate ingest problems from device-input problems.
The FLV muxer in this pattern is used for the RTMP-family publishing workflow; the destination must still be the exact RTMPS URL and key form supplied for your YouTube event. FFmpeg’s output in the terminal is useful diagnostic evidence. Keep it private if it could reveal the destination or key, and stop the process if the output profile, source or event is wrong. This method gives you control over the command, but it also leaves process supervision, log handling, and restart behaviour for you to arrange.
Test the preview and monitor stream health
Before treating the feed as ready, run a rehearsal with representative movement and audio. A static image and silence will not reveal a frame-rate issue, an audio-level problem or how the encoding behaves during motion. Check the preview for framing, orientation, image quality and synchronised audio. Confirm that the received resolution and frame rate match your intended profile, and read any warnings in Live Control Room.
YouTube advises testing with representative audio and motion before an event and monitoring stream health and messages while live. During the rehearsal, watch FFmpeg’s output as well as CPU, memory and network use on the VM. Look for sustained CPU pressure, repeated encoding errors, network interruptions or rising resource use. A short successful connection does not prove the same setup can run unattended all night; repeat checks under the conditions and duration that matter for your operation.
If the preview is missing, first check the event selection, current endpoint and secret key. If YouTube receives video but reports poor health, compare the actual feed with the chosen resolution, frame rate, bitrate and keyframe interval, then check upload stability and encoding load. Change one setting at a time where practical so you can identify which change helped. YouTube’s stream-health panel is more useful than treating a local “frame sent” message as proof that viewers receive a healthy broadcast.
For unattended operation, decide how you will restart FFmpeg after a failure, preserve useful logs without leaking credentials, and notice when a process or ingest stops. A service manager can restart a process, but that does not guarantee the stream itself remains healthy or that YouTube will accept every reconnect. Test restart behaviour privately before scheduling a real broadcast. If the goal is primarily to keep a prerecorded devotional or church stream running overnight and you do not want to maintain a VM process, this guide on keeping a YouTube church stream running overnight covers the operational question from that angle.
A self-managed VM makes sense when you need command-level control over input, encoding and deployment, and you are prepared to monitor those pieces. It also means you own package updates, secrets, process supervision, source availability and the effect of an instance or network interruption. If the brittle part of your setup is keeping a local computer awake and relaunching a failed broadcast, StreamNeo removes that specific job by running an uploaded video as a YouTube stream without your computer left on. It does not replace the need to choose suitable material or check the channel and broadcast in YouTube.
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
How do I get the YouTube RTMPS URL and stream key?
Open the intended event in YouTube Live Control Room and copy the current server URL and stream key displayed for that configuration. Use the RTMPS endpoint where available, and keep the key private; do not reuse a value from an old event without checking it.
Can I use the same FFmpeg command for a camera and a video file?
No. The example command is for a prerecorded file, using real-time pacing and looping. A camera or live feed needs an input appropriate to the device and its access path; a headless VM cannot automatically access a camera connected to your local computer.
Which Indian cloud region should I choose?
Choose from regions where the exact VM product and machine type are available, then assess sustained CPU and outbound capacity, storage, egress terms and administrative needs. Mumbai and Hyderabad are examples in provider documentation, not evidence that a particular instance is available or best for your stream.
Does a successful test guarantee an overnight stream will stay up?
No. A rehearsal can uncover configuration and capacity problems, but it cannot guarantee future network, VM or YouTube ingest behaviour. Monitor the stream and arrange tested alerting and restart handling if you operate FFmpeg yourself.