Choose your output resolution and frame rate first, then match the video bitrate to YouTube’s H.264 guidance for that format. After that, test whether your chosen x264 preset can encode the actual workload in real time on the VPS you have, rather than choosing an instance size or preset from a rule of thumb.
The bitrate target describes the video stream you send; the preset affects how much processing FFmpeg needs to produce it. Neither setting alone tells you whether a stream will stay on pace overnight. Check the output format, configure a starting command, and observe FFmpeg under a representative sustained load before relying on it.
Choose resolution and frame rate first
Your bitrate choice depends on the resolution and frame rate YouTube receives. Decide what viewers should see before changing FFmpeg options. A devotional video with a mostly static image may not need the same output format as a fast-moving local news loop, but the recommended target still comes from the selected resolution and frame rate, not from a guess about how simple the pictures look.
Consider the source material as well. If your file is 1080p at 30 frames per second, sending a 1080p30 output is a straightforward starting point. Upscaling it to 4K does not restore detail that was not in the source, and it raises the encoder’s work and the required bitrate target. Conversely, a channel that genuinely needs 60 frames per second should configure and validate that output rather than copying a 30 fps setting.
For a playlist, check whether files share dimensions and frame rates. A mixed collection can lead to scaling or frame-rate conversion in the filter chain, and those operations add work. The final output settings matter even if the source clips differ. A playlist workflow also needs to account for transitions and failed inputs; see this guide to keeping an FFmpeg playlist stream alive when a video fails.
Start with the smallest output format that meets the channel’s purpose and looks acceptable on the devices your viewers use. For a static study background, that may be less demanding than a detailed 4K scene. For text-heavy local news, ensure that names and tickers remain legible. Treat resolution and frame rate as editorial choices first, then translate that choice into encoder settings.
Find YouTube’s H.264 bitrate guidance for that output
YouTube publishes recommended live encoder settings by codec, resolution and frame rate in its live encoder settings and bitrate guidance. Use the H.264 column for an libx264 stream, and consult the current page when you configure the channel; platform guidance can change. These are recommended video bitrates, not a promise that a network connection or VPS will sustain the stream.
The following figures are YouTube’s stated H.264 recommendations. They show why resolution and frame rate must be decided before entering a target in FFmpeg.
| Output format | YouTube H.264 recommended video bitrate |
|---|---|
| 720p or lower at 30 fps | 4 Mbps |
| 720p at 60 fps | 6 Mbps |
| 1080p at 30 fps | 10 Mbps |
| 1080p at 60 fps | 12 Mbps |
| 1440p at 30 fps | 15 Mbps |
| 1440p at 60 fps | 24 Mbps |
| 2160p at 30 fps | 30 Mbps |
| 2160p at 60 fps | 35 Mbps |
If the channel is 1080p30, for example, the table gives 10 Mbps as the recommended H.264 video target. At 1080p60, the listed recommendation is 12 Mbps instead. Do not apply the 1080p30 figure to a different output merely because it is a familiar number. If your format is not shown here, refer to YouTube’s live table rather than interpolating a target.
Remember that these figures are for video. Audio has its own encoding setting and contributes additional traffic. Leave room for audio and normal network variation when checking whether the connection can carry the complete output. A bitrate recommendation is not a bandwidth test, and it says nothing by itself about the CPU capacity of your VPS.
If you are deciding between output formats for a channel made from repeating clips, consider how those formats affect the file workflow too. This explanation of streaming a playlist of devotional videos from an Indian server covers the broader continuity and source-file decisions; the encoder target still needs to match the output you choose.
Set FFmpeg’s video target with -b:v
FFmpeg’s -b:v option sets a video bitrate target in bits per second. Thus, the 10 Mbps recommendation for 1080p30 is represented as 10000000, not 10. The unit can be easy to confuse: the FFmpeg command-line option uses bits per second, while x264’s own bitrate parameter is expressed in kilobits per second. Check the FFmpeg documentation for command-line options and the libx264 codec options if you are setting encoder-specific parameters.
Here is a command skeleton for an existing input file and a 1080p30 H.264 target:
ffmpeg -re -i input.mp4 \
-c:v libx264 -preset veryfast -b:v 10000000 \
-c:a aac -b:a 128k \
-f flv "rtmps://INGEST_ENDPOINT/STREAM_KEY"
This is an example, not a verified universal command or a complete production configuration. Replace the video target with the recommendation for your actual output, and substitute the RTMPS endpoint and stream key shown in YouTube Studio. Protect the key as a credential: do not put it in a public script repository or share a terminal screenshot that exposes it. The veryfast preset is illustrative, not a promise that it will be suitable for your instance.
The -re option reads a file at its native rate rather than letting FFmpeg consume the file as fast as possible. It is useful when simulating a live feed from a file, but it does not guarantee that encoding will keep pace. Similarly, -b:v sets a target; it is not a command to allocate CPU or network capacity. If you change the resolution, frame rate, codec or filter chain, re-evaluate the target against YouTube’s table.
Do not add a collection of rate-control or buffer options simply because a copied command includes them. The precise rate-control behaviour can depend on the encoder and use case. Begin with the documented target and the settings you understand, then consult FFmpeg’s current documentation for any extra option you plan to use.
Choose an x264 preset from real-time CPU headroom
The x264 preset is a speed-versus-compression-efficiency trade-off. Faster presets generally require less encoding work, while slower presets spend more processing time for improved compression efficiency. On a VPS, the practical question is not which preset is best in isolation; it is whether the encoder can produce every frame on time for this input, output resolution and frame rate.
A slower preset is not automatically a better choice for a live stream. If it makes FFmpeg fall behind, the theoretical compression benefit does not help viewers who receive late or dropped frames. A faster preset may use a less efficient encoding path, but keeping up with real time is the first constraint. There is no universal preset-to-VPS-size mapping that applies across processors, file complexity and simultaneous workloads.
Begin with a reasonable test preset such as veryfast only as a trial setting, not as a fixed recommendation. If the process maintains pace and the VPS has headroom during representative content, test a slower preset and compare its processing speed and output. If it falls behind, return to a faster preset or reduce the workload by reconsidering resolution, frame rate or additional filters. Change one of those factors at a time so you can identify the cause.
CPU headroom matters because a quiet opening slate is not necessarily representative. A scene with movement, fine detail, animated text or transitions can demand different work. For a 24/7 channel, run the test through content that resembles the most demanding part of the planned loop and observe it for long enough to see sustained behaviour. A brief successful start only confirms that the command launches.
A playlist also creates operational work beyond encoding. If the goal is an always-on channel but maintaining a VPS session and restarting a stalled process is the particular burden, StreamNeo can remove that hands-on task by taking an uploaded video and running it as a YouTube live stream while your own computer is off. It is YouTube-only, so a custom FFmpeg VPS remains relevant when you need command-level control or a workflow beyond that scope.
Test the stream and watch encoder progress
First test locally or with a private/unlisted YouTube broadcast, depending on your channel workflow. Check that the image, sound, aspect ratio, frame rate and stream health are as expected before making the output public. Keep the first test focused: confirm the selected format, then let FFmpeg run long enough to reveal whether the encoder can keep pace rather than judging it from the first few seconds.
FFmpeg prints progress including a processing speed value, commonly shown as speed=. For a real-time input, a value near real-time pace indicates the process is keeping up at that moment; a value that remains below real time suggests it is falling behind. Treat this as an observation over time, not a single definitive reading. Watch for repeated slowdowns, dropped frames, growing delay, CPU saturation, memory pressure, and YouTube’s incoming stream health messages.
Compare the configured output rate and the actual behaviour. If speed= declines during a demanding section, note what was happening in the video and what else was running on the VPS. A CPU-heavy filter, a second encoding job, or a playlist transition may explain a problem that a simple test clip did not show. If the process is comfortably ahead, that does not prove that every future workload will behave identically; leave margin for the harder material and other tasks.
Do not choose a VPS size from the bitrate table. The table is about YouTube’s recommended incoming video bitrate, not CPU cores, memory or instance performance. Hardware models and shared-resource conditions differ, and the actual input and processing chain matter. Measure on the instance you intend to use, during a representative run, and keep a record of its settings and progress output.
For channels with several clips in rotation, test a full pass or the sections most likely to stress the encoder. A single static image can be an easy workload; a moving concert recording or scrolling news panel may be more demanding. If you have a low-power local connection and are comparing where to run the workload, this piece on making a 24/7 YouTube lofi stream with a Jio connection discusses the separate network and continuity question. It does not replace a CPU test on your chosen VPS.
Use YouTube’s recommended RTMPS ingest
YouTube recommends RTMPS for live ingest. Use the server URL and stream key presented for your broadcast rather than copying an endpoint from an old command or an unrelated example. YouTube’s LiveStreams API documentation describes stream settings, including resolution and frame-rate handling for custom stream keys.
YouTube can detect resolution and frame rate automatically, and custom stream keys support manual settings. Automatic detection is a practical default when you want YouTube to identify the incoming format. If you configure a custom key manually, make its selected resolution and frame rate agree with the FFmpeg output. A mismatch can make troubleshooting confusing because the setting in one place does not reflect what the encoder actually sends.
RTMPS and encoder capacity solve different problems. Secure ingest does not make a slow CPU encode faster, and a capable encoder cannot prevent problems caused by a poor connection or incorrect key. Check the YouTube live control room for incoming signal status as well as FFmpeg’s own progress. If YouTube reports no signal, verify the endpoint, key and output format before making broad changes to the codec settings.
Store the stream key securely and avoid embedding it in logs or public examples. If you rotate or replace it in YouTube Studio, update the command that uses it. For a 24/7 stream, test the recovery procedure as well: know how you will notice a dropped process, restart it, and confirm that the new connection is visible in the control room.
Adjust one setting at a time
When a test fails, resist changing the bitrate, preset, resolution and VPS plan together. That leaves you with no clear explanation for any improvement or regression. Record the initial settings, identify the symptom, change one relevant variable, and repeat the same representative test. A short log of the input, output format, preset, speed= observations and YouTube status is more useful than relying on memory after several overnight runs.
Use the symptom to guide the next check. If FFmpeg cannot keep up but YouTube reports a stable network connection, try a faster preset before assuming a larger server is necessary. If the encoder keeps pace but YouTube reports unstable incoming data, investigate the VPS network path and whether other traffic is competing for bandwidth. If the image is soft or text is hard to read, first check whether the chosen resolution and bitrate target match YouTube’s current recommendation; do not simply raise the bitrate beyond the published target without a reason.
If the workload still cannot sustain the chosen output with a faster preset, simplify the work and test again. Remove unnecessary filters or concurrent jobs, or reconsider whether the channel needs the selected frame rate or resolution. Where the VPS choice itself is in question, compare the actual CPU allocation and sustained behaviour from the provider’s documentation and your own test; avoid treating a nominal core count as a measured result.
Keep the intended use in view. A channel that only needs a stable loop may prefer a lower output format that the source supports and the VPS handles reliably. A channel showing detailed moving footage may justify more processing, but only if the measured machine and network sustain it. For alternative ways to organise continuous YouTube playback, see this guide to using a YouTube 24/7 streaming service with a playlist.
A sensible finished configuration is not merely one that connects. It is one that matches the chosen output to YouTube’s guidance, maintains pace through representative content, and has a recovery plan for failures. Re-test after changing input material, filters, output settings or the VPS, because each can change the workload.
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 1080p30 on YouTube Live?
YouTube’s H.264 guidance lists 10 Mbps for 1080p at 30 fps. In FFmpeg, that is -b:v 10000000, because this option uses bits per second. Check YouTube’s current table before configuring a stream, and confirm that the output really is 1080p30.
Is veryfast the right x264 preset for every VPS?
No. It is only an example starting point for testing. A suitable preset depends on whether the actual VPS can encode your content in real time with margin; observe FFmpeg progress and try changes using representative material.
Does a higher bitrate fix a stream that is lagging?
Not if the encoder itself cannot produce frames quickly enough. First determine whether FFmpeg is falling behind or whether the problem is the network or ingest. Keep the video target tied to YouTube’s recommendation for the selected output rather than treating bitrate as a remedy for every symptom.
Should I set YouTube’s resolution and frame rate manually?
YouTube can detect them automatically, while custom stream keys allow manual settings. Automatic detection is a reasonable default; if you set values manually, make them consistent with FFmpeg’s actual output and verify the incoming format in YouTube Studio.