To stream a prerecorded video from an Indian Linux VPS to YouTube, install FFmpeg, transfer the file, then send it at real-time speed to the RTMPS URL and stream key shown in YouTube Live Control Room. Choose an output mode your VPS can sustain; the example below is a starting point, not a command guaranteed to work with every FFmpeg build or source file.
The VPS takes over the work of reading and encoding the file, but it does not remove the need to check YouTube’s live-stream eligibility, encoder settings, or the host’s sustained CPU and outbound network capacity. Test with movement and audio before relying on the setup for a public broadcast.
Check channel eligibility and create the live stream
First confirm that live streaming is available on your YouTube channel. If this is the channel’s first live broadcast, enable the feature and allow for any activation process shown in YouTube Studio before planning a test. The steps can change, so follow the current YouTube instructions for enabling live streaming and check the eligibility notices in your own account.
In Live Control Room, create or schedule a stream and choose its settings. You are preparing a YouTube live event that will receive an encoder feed; the prerecorded file remains on your VPS. A scheduled event can give you a place to check the incoming signal before the intended start, but do not assume that creating an event automatically makes a broadcast public or starts it. Review visibility, audience, start time and any other options in Studio.
Decide whether this is a finite broadcast or an intended continuous channel. By default, FFmpeg reaches the end of a file and exits. Repeating a file indefinitely is a separate requirement, and loop behaviour should be checked against the installed FFmpeg documentation and tested with your actual file rather than inferred from this example. For a playlist or a fallback programme, plan that playback logic separately.
Install FFmpeg and confirm codec support
Install FFmpeg from your Linux distribution’s trusted package source or an appropriate official build. Commands vary by distribution and release; use the package manager instructions for the operating system on your VPS rather than copying a package command from a different system. You will generally want ffmpeg and ffprobe, which is commonly distributed alongside it.
Check what is installed before building the stream command:
ffmpeg -version
ffmpeg -encoders | grep -E 'libx264|aac'
ffprobe -version
The walkthrough’s transcode example assumes an FFmpeg build with the libx264 video encoder and AAC audio encoder. Not every package is built with the same options. If an encoder is absent, the command will fail; use a suitable build or select an encoding path supported by your installation. Confirm RTMPS support as well, and consult that build’s output and documentation if a TLS connection cannot be made.
Inspect the file before choosing settings. For example:
ffprobe -hide_banner -i /srv/media/video.mp4
Note the video and audio streams, codecs, frame rate, resolution and whether audio is present. This helps distinguish a file that needs transcoding from one that may already be suitable. FFmpeg’s documentation explains its input and output options; their placement matters because many options apply to the next input or output specified.
If a source already has compatible streams and parameters, stream-copying can reduce CPU work. That does not make every MP4 suitable: container extension alone does not establish codec, keyframe interval, frame rate or audio compliance. Verify the actual streams against YouTube’s requirements and check the resulting signal in Live Control Room before using -c copy in place of encoding.
Transfer the prerecorded file to the VPS
Upload the media to a stable directory that the account running FFmpeg can read. You might transfer it over SSH with scp, use an SFTP client, or use a storage method provided by your host. Whatever method you choose, check the final path and file permissions on the VPS before starting a stream.
For example, if the file is at /srv/media/video.mp4, confirm it is present and readable:
ls -lh /srv/media/video.mp4
ffprobe -hide_banner -i /srv/media/video.mp4
A slow or interrupted transfer is a file-preparation problem, not evidence that the live uplink is too slow. Check file size, available disk space and transfer completion first. If the account cannot read the file, fix ownership or permissions narrowly rather than making the media directory broadly writable.
Before encoding, review the content as well as its technical properties. YouTube’s policies and rights requirements apply to prerecorded material too. A stream that runs for many hours does not make reused material original or resolve rights questions; the discussion of reused content after a 24/7 livestream is relevant if the programme relies on material you did not create or license.
Get the RTMPS URL and stream key
Open the stream’s settings in Live Control Room and copy the current RTMPS URL and stream key. YouTube’s help describes finding the RTMPS URL from the stream setup, while Google’s RTMPS ingestion guide describes the endpoint structure and use of port 443. Use the values YouTube shows for this stream rather than an endpoint copied from an old tutorial.
The complete destination is formed from the RTMPS host and application path plus the stream key. Keep it in a protected environment variable rather than putting the key directly into a script, published command, screenshot or source repository. A URL containing a key may also be visible to users who can inspect process arguments or shell history, so consider server access and deployment practices when handling it. Restrict who can log in and who can inspect running processes.
For an interactive test, a shell variable can keep the key out of the command text you share, but it is not a complete secret-management system:
read -rsp 'Stream key: ' STREAM_KEY; echo
STREAM_URL='rtmps://<host-from-live-control-room>:443/<application-path>/'"$STREAM_KEY"
Replace the placeholder host and application path with the exact values supplied by Live Control Room. Do not post the resulting URL in logs or support requests. For an unattended service, inject the secret through a protected mechanism appropriate to your host and account, and ensure logs do not print it.
If connection fails, verify the scheme is rtmps, the host and path are current, and outbound access to port 443 is permitted. YouTube’s RTMPS help page covers RTMPS support and common connection problems. A key copied from another stream, an extra character, or an old URL can look like a network fault, so check the values carefully without exposing the key.
Configure FFmpeg for real-time playback
A file can be read faster than its intended playback rate. FFmpeg’s -re input option reads at the input’s native frame rate (equivalent to -readrate 1), so place it before the file input when using prerecorded media for a live broadcast. Without real-time pacing, FFmpeg may send the file as quickly as the machine and storage allow rather than at normal programme speed.
Here is an illustrative H.264 and AAC baseline for a 1080p30 output, assuming the installed build supports libx264 and AAC and the VPS has enough measured capacity:
INPUT='/srv/media/video.mp4'
ffmpeg -re -i "$INPUT" \\
-map 0:v:0 -map 0:a:0? \\
-c:v libx264 -preset veryfast -pix_fmt yuv420p \\
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \\
-b:v 14M -maxrate 14M -bufsize 28M \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "$STREAM_URL"
This is not a tested command for every input, package or host. It assumes a video stream and optionally maps the first audio stream if present. If there is no audio, check whether a silent track is needed for the intended output; if the file has multiple streams or unusual layouts, inspect and map them deliberately. FFmpeg option order is significant: -re governs the input that follows, while the codec and rate options apply to the output.
The example uses 30 frames per second and a GOP length of 60 frames, which makes a two-second keyframe interval at that frame rate. If you choose a different frame rate, calculate a GOP length that corresponds to the intended interval rather than leaving the number unchanged. The H.264 settings are intended to give a controlled, CBR-like output; the selected bitrate still has to fit the real VPS uplink.
If the source’s codecs and parameters already satisfy YouTube’s requirements, a copy-based command may avoid software encoding, but it also preserves the source’s bitrate and keyframe pattern. Check the results, not just the file extension. If encoding overloads the CPU, you may need to lower output resolution or frame rate, use a less demanding encoder setting, or choose a host with more suitable capacity.
A normal FFmpeg process ends when the file ends. For unattended operation, use a process supervisor or session manager only after deciding how the stream should behave on completion, disconnection and restart. Test that policy: a service restart can reconnect to a scheduled broadcast, but it cannot correct an expired or wrong key, missing file or unsuitable encoder settings. Keep logs useful for diagnosing failures without printing the secret URL.
Check resolution, frame rate and bitrate guidance
YouTube’s current encoder settings list H.264, H.265/HEVC and AV1 options for RTMP/RTMPS, support up to 60 frames per second, recommend CBR, and specify a two-second keyframe interval with a four-second maximum. For audio, the guidance includes AAC or MP3, 44.1 kHz stereo and 128 Kbps stereo audio. H.264 with AAC is a straightforward conventional choice for this FFmpeg walkthrough, not the only supported combination.
The recommended H.264 video bitrate depends on resolution and frame rate. The figures below are video bitrate guidance, not a promise about what a VPS can sustain or the total network traffic required:
| Output example | YouTube H.264 recommended video bitrate | What to consider |
|---|---|---|
| 720p30 | 8 Mbps | Lower detail than 1080p, with a smaller video bitrate target to accommodate on a constrained uplink. |
| 1080p30 | 14 Mbps | More detail, but a higher sustained video bitrate and potentially more encoding work. |
YouTube lists these recommendations for the stated modes; use its current table for other resolutions, frame rates and codecs. Audio and transport overhead add to the video bitrate, so do not treat the video figure as the entire outbound requirement. A nominal provider network speed is not a measurement of sustained throughput from your VPS to YouTube’s ingest endpoint.
Preserve the source aspect ratio. If it does not match the target frame, choose an explicit scale-and-pad approach or a different output mode rather than stretching the picture. If the source is already 720p, producing a 1080p output does not add genuine detail and can increase encoding and network demands. For a visual comparison of switching modes, see the 720p and 1080p profile settings guide.
Test preview and monitor server capacity
Before a public broadcast, make a short test using a section that contains both movement and audio. Confirm that Live Control Room receives the stream, the picture has the expected resolution and frame rate, sound is present, and YouTube reports healthy stream status. Review any warnings and messages rather than assuming that a successful connection means the encoder settings are correct. YouTube explicitly recommends testing before an event and checking stream health.
Measure the actual VPS while the test is running. Watch CPU use and memory, and observe sustained outbound traffic on the route to the ingest service. You need enough headroom for encoding as well as a stable connection that can carry the selected video bitrate plus audio and overhead. No provider plan can be assumed to sustain a bitrate from its advertised link speed alone; ask the provider about relevant traffic policies and test from the region and host you plan to use.
India is not a single network path. A VPS region’s route to YouTube, host contention and outbound restrictions may matter as much as its advertised capacity. If the signal drops frames or becomes unstable, compare measured throughput with the chosen output, then test a lower bitrate or resolution. The practical checks in this dropped-frames troubleshooting guide can help distinguish network limits from encoder load, although a broadband connection and a VPS are not the same environment.
If CPU is saturated, check whether the source can be copied without transcoding and still meets YouTube’s requirements. Otherwise reduce the encoding workload by lowering resolution or frame rate, or use a VPS whose CPU is adequate in a real test. If the connection times out, check the exact RTMPS URL, key and outbound port; if playback runs too quickly, confirm -re precedes the input. These checks isolate different failure modes instead of changing several settings at once.
For a channel intended to run continuously, test the operational details as well as the initial connection: file availability after reboot, log access, restart behaviour and how you will know that YouTube has stopped receiving a healthy signal. A single successful short test does not establish overnight reliability. Repeat a representative test under the load and schedule you expect, and retain a manual recovery path.
If maintaining an FFmpeg process and checking a VPS overnight is the specific burden you need to remove, StreamNeo takes an uploaded video and runs it as a YouTube live stream while your computer is off. It is YouTube-only; you still need to prepare the file and channel and verify the resulting broadcast.
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
Does -re make any prerecorded file suitable for YouTube Live?
No. It paces file reading at real-time speed, but it does not fix unsupported codecs, missing audio, an unsuitable frame rate, keyframes or an inadequate network connection. Inspect the input and confirm the stream YouTube receives.
Can I use -c copy instead of libx264?
Possibly, if the source’s codecs and stream parameters already meet YouTube’s requirements. Copying can reduce CPU use, but it does not adapt bitrate, frame rate or keyframe spacing, so test it in Live Control Room before relying on it.
Why does FFmpeg connect but YouTube show an unhealthy stream?
A connection only confirms that data is arriving; the encoder output may still have a wrong resolution, frame rate, bitrate, keyframe interval or audio format. Check YouTube’s stream-health messages and compare the actual output with the current encoder guidance.
Will the command keep broadcasting after the file ends?
No. The example exits when FFmpeg reaches the end of the file. Repeating a programme or joining multiple files requires separate playback logic, which you should verify against your installed FFmpeg build and test before scheduling a continuous channel.