For a general-purpose SDR YouTube stream from an Indian VPS, start with H.264 video, CBR, AAC audio and a two-second keyframe interval. Choose the resolution and bitrate from YouTube’s current encoder guidance, then check that the VPS can encode the file and sustain the required outbound traffic.
These settings describe what to configure, not what will keep every stream online. A suitable bitrate cannot compensate for an overloaded CPU, a restricted VPS network, a poor route to YouTube or a process that is never tested under overnight conditions.
Start with YouTube’s encoder recommendations
YouTube’s live encoder settings and bitrate guidance is the right starting point because the ingest service, rather than the VPS provider, determines what it can receive reliably. For a normal SDR broadcast, its general guidance is progressive video, square pixels, Rec. 709 colour and H.264 encoding.
The H.264 recommendations below are useful planning values. The minimum is not a target for a 24/7 channel. The recommended figure gives you a quality reference, but it still does not prove that your selected VPS or network route can sustain the stream.
| Output | YouTube minimum video bitrate | YouTube recommended video bitrate | Example keyframe interval at the listed frame rate |
|---|---|---|---|
| 720p30 | 3 Mbps | 8 Mbps | 60 frames at 30 fps |
| 720p60 | 3 Mbps | 8 Mbps | 120 frames at 60 fps |
| 1080p30 | 5 Mbps | 14 Mbps | 60 frames at 30 fps |
| 1080p60 | 6 Mbps | 17 Mbps | 120 frames at 60 fps |
The figures in this table are YouTube’s published encoder recommendations, not independent performance measurements. They also cover the video stream only. AAC audio and protocol overhead require additional outbound capacity.
For a devotional video with limited movement, a 720p30 output may be a sensible first test. A news loop containing text, transitions and scrolling graphics may need more care because compression artefacts are easy to notice around lettering. If the source is 1080p but the VPS cannot encode and upload it steadily, reducing the output to 720p is more useful than selecting a nominally higher setting that repeatedly falls behind.
Keep the stream key private. YouTube’s live stream management instructions explain where to obtain the stream URL and key in Live Control Room. Do not place the key in a public script, paste it into a support forum or leave it in shell history where other users on the VPS could read it.
Choose resolution and frame rate deliberately
Resolution and frame rate determine much more than the visible dimensions of the picture. They affect the amount of work libx264 performs, the number of frames it must process, the bitrate needed for movement and the amount of data sent continuously from the VPS.
For many always-on channels, 720p30 is a practical baseline. It provides a clear enough image for worship slides, ambient scenes, simple announcements and a fixed camera while asking less of the encoder than 1080p. It is also easier to test on a modest VPS without immediately turning every CPU spike into a stream problem.
Use 1080p30 when the source and content justify it and the VPS has demonstrated enough processing headroom. Text-heavy local news, maps and screen recordings can benefit from the extra resolution, but only if the output remains stable. A 1080p30 configuration using YouTube’s 14 Mbps recommendation should be treated as a capacity test, not as the default answer for every Indian VPS.
Sixty frames per second is useful when the source contains fast movement, such as sport or gameplay. It is less useful for a still devotional image or a slowly changing ambience scene. Doubling the frame rate can increase encoding work and network demand without producing a visible benefit for mostly static material.
Do not blindly force a frame rate that conflicts with the source. An input recorded at 25 fps, for example, may need a considered conversion rather than a casual -r 30. Inspect the file with ffprobe, check its dimensions, frame rate, audio streams and pixel format, then decide what the output should be.
The sample command later in this article uses 720p30’s recommended video bitrate as an example, but it does not resize or normalise the input. If the file is not already 720p30, add and test an explicit video filter and output frame-rate decision rather than assuming FFmpeg will produce the format you intended.
If you are deciding between a VPS and local hardware, the practical differences are discussed in how to set up a Raspberry Pi for 24/7 YouTube streaming with FFmpeg in India. The same principle applies in both cases: choose an output your encoder can maintain, not merely one your source file happens to contain.
Set H.264, CBR and two-second keyframes
For a broad-compatibility YouTube ingest, use H.264 video with a constant bitrate. In FFmpeg, libx264 is the usual software encoder when it is present in the build. CBR means the encoder aims to keep the video rate close to the value you specify instead of producing large peaks and low periods according to scene complexity.
A two-second keyframe interval is YouTube’s recommended starting point, and YouTube says not to exceed four seconds. At 30 fps, two seconds corresponds to 60 frames. At 60 fps, it corresponds to 120 frames. In a command, -g sets the maximum GOP length, while -keyint_min sets the minimum interval. -sc_threshold 0 prevents scene-change detection from unexpectedly shortening the interval in this particular pattern.
Here is a starting pattern for a prerecorded MP4 intended to loop:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-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 8M -maxrate 8M -bufsize 16M \
-c:a aac -b:a 128k -ar 44100 -ac 2 \
-f flv "$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"
This is a template, not a tested command. It assumes the input and output decisions have already been checked. The command does not automatically make an input 720p, and it does not prove that your FFmpeg build contains the libx264 encoder.
The -b:v, -maxrate and -bufsize values above illustrate an 8 Mbps video target. For 1080p30, YouTube’s published recommendation is 14 Mbps, but use that only after confirming that the CPU and outbound connection can sustain it. A larger buffer can change how the encoder absorbs short-term variation; it does not create bandwidth or processing capacity.
If the input is a real capture device or a live network input, do not copy -re from a prerecorded example without checking what it does. FFmpeg documents -re as controlling the input read rate and cautions about using low read rates with actual capture or live inputs. A file being read from disk needs pacing so that it is not sent as fast as the storage can provide it. A live source is already paced.
After starting the process, verify the actual output rather than trusting the command line. Check the dimensions, frame rate, codec, audio stream and observed bitrate with FFmpeg’s output or a separate inspection tool. Stream copying can preserve properties you did not intend to send, while re-encoding can create a CPU load that only becomes visible after the system has been running for some time.
Configure AAC audio
For stereo audio, YouTube’s general encoder guidance recommends AAC at 128 kbps and 44.1 kHz. The example therefore uses -c:a aac -b:a 128k -ar 44100 -ac 2.
Audio problems can make an otherwise healthy 24/7 channel unusable. A silent first stream, an audio track that ends before the video, incorrect channel mapping or a sample-rate conversion that overloads a weak CPU can all appear as operational failures even when the network is fine.
The optional map in the example, -map 0:a:0?, lets the command continue when the file has no audio stream. That does not guarantee that YouTube will receive a useful audio track. For a music, devotional or spoken-word channel, check the file explicitly and decide whether silence, a generated track or a different source is appropriate.
Listen to the result in the Live Control Room preview before making it public. Check the beginning, a normal speaking or music section and a point where the file loops. A file that plays correctly in a local media player can still expose timing or stream-selection problems after it has been remuxed and published.
Prefer RTMPS when the endpoint and build support it
YouTube supports RTMP and RTMPS ingest, and its encoder guidance recommends RTMPS for encryption in transit. Use the exact endpoint supplied by YouTube rather than constructing a URL from an old tutorial.
The destination in the example is written as:
$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY
Replace that placeholder with the current stream URL and key from YouTube Live Control Room. Your installed FFmpeg build must support the protocol and TLS behaviour required by the selected endpoint. The fact that a command appears in a blog post does not establish that every distribution, package or older build will accept the same URL form.
You can inspect the protocols compiled into a build with FFmpeg’s normal capability and version commands, then perform an actual test to YouTube. The FFmpeg protocol documentation describes RTMP-related options, but documentation for an option is not a guarantee that your particular package was built with every dependency or feature enabled.
Do not switch to RTMPS during a live event without testing it first. A protocol mismatch may look like an authentication error, a connection refusal or a process that exits immediately. Test the complete path, including the endpoint, key, firewall rules, DNS resolution and certificate handling, while the stream is still private or unlisted.
Check VPS encoding capacity and outbound rate
The phrase “Indian VPS” describes a location or market, not a performance result. A server in India may have a different route, CPU allocation, traffic policy and maintenance pattern from another server in the same city. Location alone does not demonstrate that the server can sustain an upload to YouTube.
Measure the actual workload you intend to run. Start with the selected input, encoder, preset, resolution, frame rate, audio and output bitrate. Watch CPU usage, load average, process speed and memory while the stream runs. If encoding speed drops below real time, frames are missed or the process gradually falls behind, lower the output demand or use a faster preset after checking the quality trade-off.
A faster preset generally reduces CPU work at the cost of compression efficiency. That can mean more bandwidth is needed for comparable quality, so it is not automatically a fix. A slower preset may improve compression but leave too little headroom for a 24/7 process, system tasks or recovery work. The right choice is the one that stays ahead of real time under representative content.
Test outbound capacity over a sustained period rather than relying on a short speed-test result. The video target is not the complete network requirement: add audio, protocol overhead and room for ordinary variation. A server that briefly reports a high upload speed may still have a traffic cap, an overloaded shared port or a route that becomes unreliable at night.
Before selecting a provider, confirm its current terms for continuous outbound streaming, traffic limits, restart behaviour and maintenance. Also check whether the advertised CPU is dedicated, shared or subject to throttling. These are provider facts that must be verified on the provider’s own current documentation, not inferred from the data-centre country.
If your main concern is recovering from a host reboot rather than choosing encoder flags, see how to keep a 24/7 YouTube stream running when a VPS reboots. A restart policy can relaunch a process, but it cannot repair a wrong stream key, an unsupported protocol or insufficient CPU.
For a channel where you do not want to maintain an encoder process and VPS yourself, StreamNeo removes the need to leave your computer running by taking an uploaded video and publishing it to YouTube from the cloud, with automatic monitoring and restart handling. It remains YouTube-only, and you should still test the resulting channel and content before relying on it.
Add recovery without treating it as a guarantee
A plain FFmpeg process may exit when publishing fails. FFmpeg’s FIFO muxer documentation shows a pattern for continuing real-time processing and attempting recovery after temporary output failures:
ffmpeg -re -i input.mp4 \
-c:v libx264 -c:a aac \
-f fifo -fifo_format flv \
-drop_pkts_on_overflow 1 -attempt_recovery 1 -recovery_wait_time 1 \
-map 0:v:0 -map 0:a:0? \
"$YOUTUBE_RTMPS_URL/$YOUTUBE_STREAM_KEY"
Treat this as an illustration of documented FIFO options, not a complete production command. Add the actual resolution, frame rate, bitrate, keyframe and input decisions for your stream, and confirm that your FFmpeg version accepts the options in the way you expect.
Recovery options can help with a temporary output failure, but they do not promise that YouTube will preserve one uninterrupted public event after a disconnect. They also do not replace process supervision, logs, alerts, stream-health checks or a deliberate test. Protocol reconnect controls vary according to the input or output protocol and the installed build.
A practical recovery plan has several layers. Let the process report and log failures, use a service manager or supervisor to restart an unexpected exit, monitor the published stream in YouTube, and decide what you will do if the stream key is revoked or the source file is damaged. Keep a tested copy of the command and configuration, but keep credentials separate from the command where possible.
Test stream health before relying on it
Create the stream in Live Control Room and begin with an unlisted or private test where appropriate. YouTube recommends testing before going live, checking the preview and monitoring stream health and messages. Its live streaming tips are useful for checking the complete path rather than just the FFmpeg process.
Use content that represents the real channel. A still image alone will not show how the encoder behaves during a transition, scrolling text or a complex scene. Include the loudest normal audio, a quiet passage, any scheduled graphics and a point where the playlist or file loops.
During the test, check the following:
- FFmpeg remains at real-time speed without steadily increasing delay.
- The selected resolution, frame rate, codec and audio format appear in the encoded output.
- YouTube’s stream health does not report persistent bitrate, network or encoding warnings.
- The public or preview playback has continuous video and audio at the loop boundary.
- CPU use leaves room for the operating system and any recovery process.
- Outbound traffic remains stable for a sustained test, not just the first few minutes.
- A deliberate process restart or temporary network interruption produces the behaviour you expect.
Do not use a successful short preview as an uptime guarantee. Repeat the test with the actual file and command, and check it at the time of day when you expect the channel to run. If the VPS provider offers a traffic graph, compare it with FFmpeg’s observed output and investigate unexplained gaps.
A playlist can introduce a separate failure point when one file ends before the next begins. If your channel uses several videos, how to stream different videos in a YouTube Live playlist without a gap covers the continuity problem separately from encoder bitrate.
A practical selection checklist
Use this order when choosing settings or a host:
- Confirm that the YouTube channel can live stream and that the current Live Control Room provides the stream URL and key.
- Inspect the source file and decide whether 720p30, 720p60, 1080p30 or another supported output is appropriate for the content.
- Select YouTube’s corresponding H.264 video bitrate as a starting point, then account for AAC audio and protocol overhead.
- Configure CBR, progressive video, square pixels, Rec. 709 SDR and a two-second keyframe interval.
- Confirm that the FFmpeg build includes the encoder and protocol features you intend to use.
- Measure CPU and outbound traffic with representative content from the actual VPS.
- Test RTMPS, preview playback, audio, loop boundaries and recovery before publishing publicly.
- Monitor the FFmpeg process, YouTube stream health and the VPS during the first overnight run.
When comparing VPS options, compare sustained outbound capacity and limits, CPU behaviour under the chosen preset, route performance to YouTube, service terms and restart support. When comparing stream settings, compare visible quality for the actual content against the processing and network headroom they consume. There is no India-specific bitrate in YouTube’s general table, and no server location by itself can settle the route question.
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 8 Mbps enough for a 24/7 YouTube stream?
YouTube lists 8 Mbps as its recommended H.264 video bitrate for both 720p30 and 720p60. It is a starting value, not a guarantee that your VPS can encode the output or sustain the complete upload, including audio and overhead.
Should I use 1080p30 from an Indian VPS?
Use 1080p30 when the content benefits from it and testing shows that the VPS can encode and upload it consistently. YouTube lists 14 Mbps as the recommended H.264 video bitrate for 1080p30, but a stable 720p30 stream is preferable to an unstable 1080p stream.
Do I need RTMPS instead of RTMP?
YouTube recommends RTMPS for encryption in transit, so prefer it when the endpoint and installed FFmpeg build support it. Test the exact URL and key before publishing because builds and endpoint requirements are not identical everywhere.
Does FFmpeg recovery guarantee that the live stream will continue?
No. FIFO and reconnect options can attempt to recover from temporary failures, but they do not guarantee an uninterrupted YouTube event. Use them alongside supervision, monitoring and a test that deliberately checks how your channel behaves after a disconnect.