Pick the resolution and frame rate first, then set FFmpeg’s video bitrate against YouTube’s published H.264 recommendation for that combination. Those figures describe what to send to YouTube; they do not show that a small VPS can encode it in real time or carry it reliably.
For a cautious first test, 720p30 at 6 Mbps video is a useful reference point if your source and VPS sustain it. Add audio to the network budget, leave upload headroom, and test the complete stream before relying on it overnight.
Choose resolution and frame rate before bitrate
A bitrate is not a quality setting in isolation. Its useful range depends on the resolution and frame rate you intend to send, as well as the codec. If you choose a target after copying a bitrate from another channel, you may send too little data for a detailed picture or spend bandwidth on a higher setting that your source and VPS cannot maintain.
For a devotional loop made from mostly static artwork, 720p30 may be adequate. A local news loop with moving footage may benefit from more detail, but raising it to 1080p30 also raises the bitrate YouTube recommends and the work required to encode it. A 60 fps target makes sense only when the source has useful motion at that rate and your encoding path can sustain it.
Check what is actually in the file before setting output options. Use a media inspection tool or FFmpeg’s input information to confirm dimensions, frame rate, and whether audio exists. Upscaling a low-resolution file does not create detail, while setting a 60 fps output for a 30 fps source does not make the original motion smoother in a meaningful way.
The practical sequence is to decide what viewers need to see, choose a source-compatible output resolution and frame rate, and then look up the corresponding recommendation for the selected codec. You can find more of the loop and process details in this guide to running a 24/7 YouTube stream on Linux with FFmpeg, but treat the bitrate and compute test as separate decisions.
Use YouTube’s H.264 bitrate recommendations
YouTube’s current encoder guidance gives recommended H.264 video bitrates by resolution and frame rate. The table below is for H.264 video, not total feed bitrate. Audio is additional, and a different ingest codec has its own guidance. Check YouTube’s encoder settings before a production change, since the platform’s current documentation is the authoritative reference.
| H.264 output | YouTube-recommended video bitrate |
|---|---|
| 720p30 | 6 Mbps |
| 720p60 | 8 Mbps |
| 1080p30 | 10 Mbps |
| 1080p60 | 17 Mbps |
For example, if you select 720p30 H.264, set a video target of 6 Mbps as the starting point. If you select 1080p30, the corresponding figure is 10 Mbps. Do not read these values as a promise of an exact constant rate at every instant, nor as proof that a VPS has enough CPU or network capacity. YouTube describes its ranges as based on the ingestion codec, resolution, and frame rate.
The table is deliberately limited to common 30 and 60 fps choices. YouTube’s page includes other resolutions and guidance for other codecs; consult it if your target differs rather than extrapolating from this table. Keep codec explicit in your notes: saying “6 Mbps” without saying H.264 and 720p30 loses the context that makes the number useful.
A lower output target can be sensible when the original file is smaller or the VPS cannot encode the chosen profile reliably, but it is a change to validate, not a shortcut around testing. YouTube’s recommendation is a platform-side reference. The source file, encoder preset, competing work, and network route remain your own constraints.
Set CBR and a two-second keyframe interval
For a conventional H.264 live feed, YouTube recommends constant bitrate (CBR) and a keyframe interval of two seconds, with keyframes no more than four seconds apart. In FFmpeg, -b:v sets the target video bitrate; -maxrate and -bufsize are rate-control options often used alongside it. The buffer value is part of rate control, not extra bandwidth that your network needs to supply.
For a 30 fps output, two seconds corresponds to 60 frames, so -g 60 is a typical GOP setting. For 60 fps, two seconds corresponds to 120 frames. If you change frame rate, revisit the GOP frame count rather than leaving a value that now represents a different interval. Confirm the actual output frame rate: input metadata and output filters can differ.
An illustrative command for a file loop is:
ffmpeg -re -stream_loop -1 -i input.mp4 \\
-c:v libx264 -b:v 6000k -maxrate 6000k -bufsize 12000k -g 60 \\
-c:a aac -b:a 128k \\
-f flv "rtmps://<ingest-address>/<stream-key>"
This example assumes a 30 fps output, uses a 60-frame GOP, and is a starting point rather than a universal command. FFmpeg documents -b:v, -maxrate, and related options in its official documentation. The rate-control flags do not make every moment’s measured bitrate perfectly flat, and the example does not confirm that your file contains a usable audio stream.
-re paces a file input in real time, which is useful when a prerecorded file is being used as a live source. Do not apply a deliberately low read rate to a live capture input: FFmpeg warns that it can cause packet loss. If your source is already encoded compatibly, copying streams may avoid video re-encoding and reduce CPU load, but verify that the output container, codecs, audio, and YouTube preview all behave as expected.
Configure AAC audio and RTMPS
The example uses AAC stereo at 128 kbps, a common starting point that matches YouTube’s published guidance for stereo AAC or MP3 audio. That audio rate is separate from the video value. A feed at 6 Mbps video plus 128 kbps audio has a nominal payload of about 6.13 Mbps before transport overhead, so budgeting only the number in -b:v understates what must leave the VPS.
Check the source’s audio before scheduling a continuous stream. If the file has no audio stream, FFmpeg cannot encode one merely because -b:a is present. Map an existing track deliberately, or add an appropriate audio source if the programme requires it. Listen to the YouTube preview: a silent output, wrong track, clipping, or an unexpected channel layout can be missed by a command that exits without an obvious error.
For the common H.264 workflow, YouTube recommends RTMPS, the encrypted extension of RTMP. Use the ingest address and stream key shown in YouTube Live Control Room, and keep the key private; anyone who obtains it may be able to send to that live stream. Do not paste it into a public log or a screenshot shared for troubleshooting.
The URL shape in the command is illustrative. Replace both placeholders with the current ingest details provided for your broadcast. YouTube’s ingestion protocol comparison describes other choices, including segment-based protocols that may suit workflows with different latency and codec requirements. Do not select a protocol simply because its name appears in a sample command.
If you are building a programme from separate clips, check transitions and continuity as well as the encoding flags. This guide to joining videos continuously with FFmpeg concat addresses the file sequence; the published output still needs a live test for picture, sound, and ingest health.
Leave upload headroom for the whole feed
YouTube advises that total stream bitrate should stay within available upload bandwidth and recommends leaving about 20% headroom. Include both video and audio, and include the backup feed too if you are sending one. The headroom is not an additional stream; it is capacity left unused so normal variation and transport overhead do not push the feed against the connection’s limit.
Using the 720p30 example, 6 Mbps video plus 128 kbps audio is approximately 6.13 Mbps of payload. With about 20% headroom, a planning figure is roughly 7.4 Mbps of sustained outbound capacity. This is arithmetic from the example settings, not a guarantee about any provider or route. A backup feed would increase the requirement, so do not assume a single-stream estimate covers it.
Measure the VPS’s actual outbound route during a representative period, and check the provider’s traffic allowance, port limits, and any fair-use conditions. A speed test from your home connection says nothing about the VPS’s path to YouTube. A short burst result also does not establish that the connection can keep carrying a stream over a full night.
This is one reason to separate encoding from delivery in your diagnosis. If FFmpeg is comfortably faster than real time but YouTube reports unstable bitrate, investigate the outbound connection and route. If the network is stable but FFmpeg falls behind, increasing upload capacity will not solve an encoding bottleneck. The YouTube streaming tips explain the platform’s bandwidth advice and testing considerations.
Test encoding load on the VPS
There is no universal vCPU or RAM figure that can responsibly promise 720p or 1080p encoding on every small VPS. The workload changes with resolution, frame rate, x264 preset, motion and detail in the source, concurrent services, and whether the job is encoding or only forwarding compatible pre-encoded media. Two machines with the same advertised core count may also behave differently under sustained load.
Run a representative test before planning unattended operation. Use the actual file or footage with comparable motion and audio, the intended output settings, and the services that will share the machine. Observe FFmpeg’s reported speed and CPU use over time. For real-time streaming, speed should remain at or above real time; repeated dips below real time mean the encoder is not keeping up, even if a short preview initially looks fine.
The x264 preset is a trade-off between encoding effort and compression efficiency. A faster preset generally reduces the work needed from the CPU, but may need more bitrate to achieve similar visual quality. Do not change the bitrate casually to hide a slow encode: first test a faster preset, a lower resolution or frame rate, or a compatible stream-copy path. Then inspect the resulting picture and stream health again.
Keep other work on the VPS in view. A scheduled backup, package update, or another process can use CPU or outbound capacity at the same time as the stream. A quiet test that runs only the encoder may not represent the overnight conditions you intend to rely on. If the machine must also perform other work, include that work in the trial.
For a small business or study channel, the least demanding route may be to send an already-encoded file without re-encoding, provided its codecs and container are accepted and its playback remains healthy. If you need to transform the picture, add overlays, or mix audio, encoding remains part of the job and must be tested. A useful OBS settings checklist for 24/7 YouTube streaming in India can help clarify the same distinction between output configuration and the computer doing the work.
Monitor stream health and revise settings
A command that starts is not the same as a stream that will survive unattended operation. Start a test in YouTube Live Control Room, inspect the preview for both picture and sound, and check the stream-health indicators for warnings. YouTube can flag issues involving bitrate, codec, audio, or keyframes. Resolve warnings before treating a test as representative.
Let the test run long enough to expose sustained load and connection problems. Watch FFmpeg’s speed and error output, CPU use, network traffic, and the YouTube health status together. If the feed drops, note whether the process exited, slowed below real time, lost its connection, or continued while YouTube stopped receiving valid media. Those causes call for different changes.
Make one material change at a time and test again. If encoding cannot hold real time, try a faster preset or a lower target resolution or frame rate. If encoding is stable but the ingest reports bitrate trouble, check total stream rate, the VPS route, and whether a backup is consuming bandwidth. If audio is wrong, fix the input mapping or audio source rather than adjusting video bitrate.
An always-on channel also needs a recovery plan. A process supervisor can restart a failed command, but restarts do not repair a bad source file, exhausted traffic allowance, or persistent network fault. Alerting matters because a restart loop can look active on the server while viewers see a gap. For failures caused by a broken loop input, see how to make an FFmpeg YouTube live loop recover after a file error.
If the recurring operational problem is keeping a file-based broadcast running while your own computer is off, StreamNeo removes that specific task: you upload the file once and the YouTube broadcast is monitored and restarted if it drops. It does not change YouTube’s bitrate guidance or establish what a VPS can encode, and it is for YouTube streams.
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
What bitrate should I use for YouTube Live?
Choose the resolution, frame rate, and codec first, then use the matching recommendation on YouTube’s current encoder settings page. For H.264, the published examples here are 6 Mbps at 720p30 and 10 Mbps at 1080p30; add audio when estimating total upload use.
How do I set FFmpeg bitrate?
Use -b:v for the video target and -b:a for audio, with suitable rate-control options such as -maxrate and -bufsize where appropriate. Set the GOP to about two seconds in frames for the output frame rate, and confirm the result in YouTube Live Control Room rather than assuming the command alone proves a healthy stream.
Can I stream to YouTube from a VPS?
Yes, if the VPS can sustain the encoding workload and its route can carry the complete feed with headroom. A platform bitrate recommendation establishes neither condition, so test the actual source, settings, and machine before leaving it unattended.
Does 6 Mbps mean I need exactly 6 Mbps of upload?
No. That is the H.264 video figure for 720p30, not the complete stream payload or a connection target. Include audio, transport overhead, any backup feed, and YouTube’s advised upload headroom when assessing capacity.