For a prerecorded 720p30 stream, start with H.264 at a 6 Mbps video target, AAC stereo audio and a keyframe every two seconds. That is a practical configuration within YouTube’s published bitrate guidance, not a tested optimum or a promise that a particular Indian VPS can sustain it.
The command below loops a file at normal playback speed and sends it to YouTube over RTMPS. Before relying on it overnight, test encoding and upload from the actual VPS, keep the stream key private, and watch YouTube’s stream-health messages.
Choose 720p30 and a sustainable bitrate
YouTube’s H.264 encoder guidance lists 3 Mbps as the minimum and 8 Mbps as the recommended video bitrate for both 720p30 and 720p60. A 6 Mbps target sits inside that recommended range and is a sensible place to begin a test. It is not a universal best setting: source detail, motion, encoder behaviour and the connection from your VPS all affect the result.
The audio rate is additional to the video rate. With the example’s 128 Kbps AAC audio, the combined stream will be a little above the video target, before considering transport overhead and variation. You need stable outbound capacity beyond that combined rate, with some room to absorb changes. YouTube recommends running an upload speed test; test from the VPS and network path you intend to use rather than relying on a speed test from your home or office.
| Choice | Starting point | What to consider |
|---|---|---|
| Resolution and frame rate | 1280×720 at 30 fps | A suitable starting format for a file stream; match the frame rate to the content where practical. |
| H.264 video rate | 6 Mbps | Inside YouTube’s 3 Mbps minimum and 8 Mbps recommended range for 720p30; validate it on your connection. |
| Audio | AAC stereo, 128 Kbps, 44.1 kHz | YouTube lists these as advanced stereo recommendations. |
| Keyframes | Every 2 seconds | YouTube recommends this interval and says not to exceed 4 seconds. |
| Ingest | RTMPS over port 443 | Use the exact endpoint and key shown for your broadcast in YouTube. |
A 720p60 stream may suit footage with fast movement, but it asks the VPS to encode more frames each second. The YouTube table gives 720p60 the same bitrate range as 720p30; that does not mean the two formats will look identical at the same bitrate, or that your VPS can encode them equally well. For a devotional visual loop, study ambience, a local news graphic or a mostly static scene, 30 fps is often the simpler first test. For more motion, compare 60 fps with the actual content and machine under load.
YouTube’s encoder settings page also says automatic detection is the default and recommended behaviour for resolution and frame rate. If you are using a custom stream key that lets you choose settings manually, decide deliberately whether to set them or leave detection enabled. The FFmpeg settings used for a continuous stream from an Intel NUC provide a useful contrast when you are weighing a local machine against a VPS, but neither hardware location removes the need for a real test.
Set H.264 CBR, AAC stereo and two-second keyframes
The example uses H.264 video with constant bitrate (CBR), AAC stereo audio, and a two-second keyframe interval. These choices align with YouTube’s encoder guidance for an H.264 live stream. CBR aims to keep the video rate at a defined target rather than allowing large swings. That makes the requested output rate easier to plan around, though it cannot make a weak network stable or guarantee that every moment has equal visual quality.
The command sets -b:v, -minrate and -maxrate to the same video target. It also sets a buffer size of twice that target. These options describe the encoder’s rate-control behaviour; they do not prove that the VPS can keep up with encoding or that the route to YouTube has enough capacity. If the source contains fine detail, grain, fast cuts or moving text, 6 Mbps may not preserve every detail. If the connection cannot sustain the combined output, lowering the target can be more useful than insisting on the initial figure.
The keyframe options set a 60-frame group at 30 fps: -g 60 and -keyint_min 60. The command disables scene-change keyframe insertion with -sc_threshold 0, keeping the interval predictable. YouTube recommends a keyframe interval of two seconds and says it should not exceed four seconds. If you change the frame rate, update the frame count as well: at 60 fps, two seconds is 120 frames.
For audio, the template encodes AAC at 128 Kbps, 44.1 kHz and two channels. That is a straightforward stereo starting point for music, speech or a mixed programme. Confirm that the input actually contains the audio you expect. A file with no audio track will not become audible because the output options request AAC; inspect the source and, where automatic stream selection is unsuitable, specify the desired input streams explicitly. FFmpeg documents stream selection and output options in its command-line documentation.
Build the FFmpeg command for a prerecorded file
Replace input.mp4 with the source file available on the VPS. Replace the output placeholder with the exact RTMPS ingest URL and stream key supplied for your YouTube broadcast. Do not run the placeholder literally.
ffmpeg -re -stream_loop -1 -i input.mp4 \\
-vf "scale=1280:720,fps=30,format=yuv420p" \\
-c:v libx264 -preset veryfast -tune zerolatency \\
-b:v 6000k -minrate 6000k -maxrate 6000k -bufsize 12000k \\
-g 60 -keyint_min 60 -sc_threshold 0 \\
-c:a aac -b:a 128k -ar 44100 -ac 2 \\
-f flv 'RTMPS_INGEST_URL/STREAM_KEY'
-re reads the file at its intended playback speed instead of consuming it as fast as the machine can process it. -stream_loop -1 repeats the input indefinitely. Together they suit a prerecorded-file loop; they are not a general setting to copy blindly for a capture device or an already-live input. The FFmpeg manual describes the available inputs and options, while the protocol documentation explains RTMP and RTMPS support.
The video filter scales the image to 1280×720, makes the output 30 frames per second and converts pixel format to yuv420p, a broadly used compatibility format for video playback. Scaling can change the aspect ratio if the source is not 16:9. If preserving the source’s shape matters, inspect its dimensions and choose a scaling-and-padding approach rather than stretching faces or graphics. The supplied command is deliberately a starting template, not a finished filter chain for every source.
libx264 is the H.264 encoder. veryfast is a preset choice intended to reduce encoding work compared with slower presets, with a trade-off in compression efficiency. zerolatency is included in the template, but a prerecorded loop does not become a low-latency live production simply because of that option. Observe CPU load and whether FFmpeg keeps pace with playback. If it falls behind or drops frames, investigate the encode workload before raising quality settings.
For a 720p60 output, change fps=30 to fps=60 and set the GOP options to 120 frames, while checking that the VPS can encode the file in real time. Do not change only the filter and leave a 60-frame GOP: that would produce a one-second interval at 60 fps rather than two seconds. For a live capture or network input, adapt or omit -re and -stream_loop; those options in this example assume a file. If you are adapting a directory of clips on a Windows computer instead, the guide to streaming a video folder from a Windows PC covers a different source and operating setup.
Use YouTube’s RTMPS URL and protect the key
Use RTMPS, and take the exact ingest URL and stream key from YouTube Live Control Room or the Live Streaming API. Google’s RTMPS ingestion guide documents the RTMPS endpoint and port 443. Do not guess the path, reuse an example endpoint from an unrelated broadcast, or assume the key is interchangeable between streams.
The key grants access to the live ingest for the associated configuration. Treat it like a password: do not publish it in an article, paste it into a public repository, share a terminal screenshot containing it, or leave it in a script that other users can read. The command uses a placeholder to make the required substitution visible without exposing an actual credential. If a key is accidentally disclosed, use YouTube’s controls to replace or reset it and update the sender with the new value.
A shell command can be saved in a file or appear in shell history, depending on how you run it. For a VPS used by multiple people, restrict access to files containing credentials and avoid copying the command into public support posts. You can also arrange your own launch procedure so the key is supplied privately at runtime, but verify that the method does not print it to logs or process output visible to others. The important point is not a particular secret-management technique: it is to keep the full endpoint-and-key combination out of public places and grant access only to people who need it.
RTMPS encrypts the connection between sender and ingest endpoint; FFmpeg’s protocol documentation describes RTMPS as RTMP over an encrypted SSL connection. Encryption protects the transport, but does not protect a key copied into a public script or a compromised account. If you are new to ingest URLs and keys, the introduction to custom RTMP explains the general terms. Always use the stream-specific values shown by YouTube for the broadcast you are preparing.
Test encoding and the VPS connection before relying on it
An Indian VPS is not automatically suitable because it is located in India. Location alone tells you neither how much CPU is available to your process nor whether the route to YouTube’s ingest endpoint is stable. The research for this configuration did not establish a provider-specific performance result, universal CPU or memory requirement, or a tested VPS size. Treat the command as a template to validate on the plan and region you select.
Begin with the actual file, the exact FFmpeg build and the chosen preset. Run a test long enough to reveal whether the encoder maintains real-time output instead of judging it from a short start-up. Watch CPU use and FFmpeg’s progress output; if processing consistently falls behind playback, the machine or encode settings may be unsuitable. Try a less demanding combination, a different frame rate, or another plan only after identifying what is limiting the test. A provider’s advertised specification is not a substitute for measuring your workload.
Then measure outbound capacity from the VPS itself. YouTube recommends a speed test to test upload bitrate. Confirm that the connection has stable capacity above the combined audio and video target, with headroom for variation. A single high reading does not establish that a continuous stream will remain stable through congestion, route changes or provider maintenance. Recheck from the same region and connection path used for the broadcast.
Send a private or otherwise controlled test broadcast before scheduling a public overnight run. Include the kind of audio and movement your real content has: a static title card may not reveal the same quality or encoding behaviour as scrolling news text or a moving devotional visual. Check that the file loops cleanly, audio is present, the image is the expected shape, and playback reaches YouTube without recurring interruptions. Review the Live Control Room rather than assuming that a successful FFmpeg process means viewers receive a healthy stream.
YouTube’s Live Streaming API exposes stream health status and configuration issues in its LiveStreams reference. Health messages can help distinguish a bitrate, audio or GOP warning from a local encode problem. Use the status detail to decide what to change instead of repeatedly altering unrelated settings. If you are comparing a VPS with a local device for a channel that runs continuously, the Indian VPS guide for a prerecorded Assamese music channel may help frame the operating trade-offs, but it is not a performance test for your chosen provider.
Adjust bitrate when the feed is unstable
If YouTube reports that the bitrate is too low, or the feed repeatedly disconnects while the VPS has spare encoding capacity, first recheck the upload path and the actual output rate. A speed test and stream-health message answer different questions: the former samples network capacity, while the latter reports what YouTube sees from the live contribution. Ensure the stream is not being sent at a different rate than the command’s target and that the endpoint and key are correct.
If the connection cannot sustain the target, try a lower video bitrate that remains within YouTube’s published guidance where possible, then repeat the test. For 720p H.264, YouTube lists 3 Mbps as the minimum and 8 Mbps as recommended. Moving towards the lower end may improve the chance of maintaining a constrained connection, but can reduce picture detail, particularly in complex or moving scenes. The right setting depends on observed capacity and picture quality, not on a claim that one number works for every Indian VPS.
If the connection is stable but the picture is poor, check the source resolution and motion before increasing the target. Upscaling a small file to 1280×720 does not recreate missing detail. A highly detailed source may need more bits than a flat graphic to look clean, yet the VPS and connection still need to sustain the output. Change one variable at a time and compare the same representative segment so you can tell whether a change helped.
For dropped frames or an encoder that cannot keep up, reducing the video bitrate may not solve the underlying CPU constraint. A faster preset, 30 fps instead of 60 fps, or an appropriately sized VPS can reduce the work, each with its own quality or motion trade-off. Do not infer from a provider’s region label that it will support the required workload. Repeat the encode test and live test after each material change, and record the settings that produced a stable result for your own file and route.
If a stream-health warning identifies audio or keyframe settings, verify those specific settings against YouTube’s guidance before changing the video rate. The two-second keyframe interval and AAC stereo setup are already represented in the template. For a 60 fps adaptation, remember the 120-frame GOP. A warning is a reason to inspect the reported issue, not proof that all other parts of the command are wrong.
Keep the operating arrangement practical
A VPS can keep the sending computer out of the room and allow a file loop to continue without leaving a personal laptop switched on. It also makes you responsible for checking the selected plan, file placement, credentials, restart behaviour and monitoring arrangements. The command itself does not arrange recovery after a process exits, alert you when a broadcast has stopped, or establish that the plan permits the intended continuous use. Confirm those operational details with the provider and test the procedure you will use after a failure.
If operating FFmpeg over SSH is a recurring burden, a managed workflow may remove the need to leave your own computer running and manually restart a dropped file stream. StreamNeo takes an uploaded video and runs it as a YouTube live stream, which addresses that specific repeat-upload-and-restart work; it does not change the need to use content you have rights to broadcast or to check YouTube’s current requirements. It is YouTube-only, so it is not the fit if you need the same feed sent to another platform.
The choice is between control and operating effort. A self-managed VPS gives you control over the FFmpeg command, files and environment, but you validate the workload and maintain the sending process. A managed file-to-live workflow reduces those recurring tasks, but is less suited to a custom capture pipeline or a multi-platform encoder setup. Whichever route you choose, do a real test with your content before scheduling a long broadcast and keep a recovery plan that does not depend on an untested assumption.
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
Is 6 Mbps the best bitrate for every 720p YouTube stream?
No. It is a practical starting target within YouTube’s published 3 Mbps minimum and 8 Mbps recommended range for H.264 at 720p30 and 720p60. Test the actual VPS route and content, then adjust to the stream-health feedback and observed picture quality.
Can I use the command for 720p60?
Yes, but change the filter to fps=60 and set the keyframe interval to 120 frames for two seconds. Confirm the VPS can encode at that rate in real time; a higher frame rate may require more encoding work even though YouTube lists the same bitrate range for 720p60.
Does an Indian VPS guarantee a stable YouTube connection?
No. A location does not establish CPU capacity or route stability, and no provider-specific VPS performance was verified for this template. Test upload capacity and run a real stream from the selected plan and region before depending on it.
Should I put my YouTube stream key in the command?
The command needs the stream-specific endpoint and key to send to YouTube, but do not disclose a real key in a public script, screenshot or repository. Restrict access to files and logs that could contain it, and replace the key through YouTube if it is exposed.