YouTube’s upload recommendations give you a useful starting point for preparing an MP4 with FFmpeg on a Hetzner VPS: match the output resolution and frame rate to your source, then use the corresponding bitrate reference. Those figures describe an upload file, not required live-stream ingest settings or a promise about how the video will look.
Treat encoding and transferring the finished file as separate jobs. The VPS plan, encoder, preset, input and competing workload affect how long encoding takes; the file size, route and plan’s outgoing traffic allowance affect its transfer.
Upload encoding is not live streaming
A video file uploaded to YouTube and a live feed sent to YouTube are different outputs. In this guide, FFmpeg prepares a file for upload. YouTube’s recommended upload settings help you choose a container, codec and reference bitrate for that file. They do not set a mandatory cap for a live stream or tell you which bitrate your live encoder must send.
For an always-on channel, you might encode a devotional video or a loop in advance, upload it, and then use a separate workflow to broadcast content continuously. A prepared file can be useful when you want your main computer switched off during the broadcast; the choices for encoding that file still depend on its source and how you intend viewers to watch it. If the broader question is whether prerecorded material can run without a PC, see how prerecorded lectures can run as a 24/7 YouTube live stream.
A bitrate reference is not a visual-quality guarantee. Two videos encoded at the same resolution and bitrate can differ because their motion, texture, noise and source quality differ. A static image with gentle movement is not the same encoding workload as detailed footage with fast motion. YouTube also processes uploaded files for playback, so the upload file’s settings should not be mistaken for a promise about every playback rendition.
YouTube’s format and colour guidance
For a conventional SDR upload, YouTube recommends H.264 video in an MP4 container, progressive scan, variable bitrate (VBR), and 4:2:0 chroma subsampling. Its guidance also recommends keeping the uploaded frame rate the same as the source where possible. Check the current YouTube recommended upload encoding settings before finalising a workflow, particularly if the source is interlaced, HDR or uses an unusual frame rate.
For SDR, the recommended colour target is BT.709. That does not mean you should blindly overwrite colour metadata: the correct conversion and signalling depend on the source and how it was captured. If the input has incorrect or missing colour metadata, an output flag alone may not perform the conversion you need. Check the source first, then test a short output and confirm that it displays as intended.
YouTube lists MP4 with AAC-LC or Opus audio and a 48 kHz sample rate in its recommendations. It also recommends a fast-start MP4, with the moov atom at the front of the file. FFmpeg’s MP4 muxer offers options related to this, but inspect the documentation for the installed build and validate the resulting file rather than assuming that changing a filename makes a file fast-start.
Progressive video means each frame represents a complete picture rather than an interlaced field. If the source is interlaced, YouTube says to deinterlace before upload. Deinterlacing is a processing choice: it may alter motion and detail, and the appropriate filter depends on the source. Do not add a generic filter to every input simply because an example command contains one.
Choose resolution and frame rate from the source
Start with the source dimensions, aspect ratio and frame rate, then decide what output is useful for your viewers. YouTube’s standard computer aspect ratio is 16:9, while its player adapts to vertical and square uploads. There is no single resolution that is right for every channel. A 720p source does not gain captured detail simply by being enlarged to 1080p, though you may have a specific delivery reason to make that conversion.
Keeping the original frame rate is usually the clearest starting point. If a source was recorded at 25 fps, choosing 60 fps does not create new captured moments; it can increase processing and file demands. Conversely, if the source contains higher-frame-rate motion that you want to retain, selecting a lower output rate discards temporal detail. YouTube’s upload guidance covers common rates from 24 to 60 fps and groups its SDR bitrate references into standard (24, 25 or 30 fps) and high (48, 50 or 60 fps) categories.
Scaling needs input-specific care. FFmpeg’s scale filter can set output dimensions, but a correct expression depends on whether the input is landscape, portrait or square, whether you need to preserve aspect ratio, and what should happen to dimensions that do not divide cleanly. A simple -vf scale=1920:1080 forces those dimensions and may distort a source with a different aspect ratio. Do not copy that expression unless stretching is genuinely intended.
If you need to resize, decide whether to preserve the full image with padding or fill the target frame by cropping. Check the result for distorted circles, cut-off captions and unexpected borders. For a loop of different videos, assess each source rather than presuming that one scale setting fits every clip. The practical concerns overlap with streaming a folder of videos to YouTube Live in a loop, where consistent playback across varied files matters too.
Use bitrate references without treating them as caps
YouTube states that its guidance uses variable bitrate and that no bitrate limit is required, while offering recommended bitrates for reference. The figures below are its SDR upload references. They are not required maximums, live ingest settings, or guarantees that an encode at that rate will look a particular way.
| Output resolution | Standard frame rate (24, 25 or 30 fps) | High frame rate (48, 50 or 60 fps) |
|---|---|---|
| 720p | 5 Mbps | 7.5 Mbps |
| 1080p | 8 Mbps | 12 Mbps |
| 1440p | 16 Mbps | 24 Mbps |
| 2160p (4K) | 35–45 Mbps | 53–68 Mbps |
Source: YouTube’s upload guidance, checked in October 2026. For HDR or other cases outside this table, consult the relevant current guidance rather than treating SDR figures as a universal rule.
The table helps narrow a starting point after you have selected resolution and frame rate. It does not replace judgement about your material. At a given reference, complex movement or fine detail may be harder to preserve than a mostly static picture. Raising bitrate can create a larger file and take longer to transfer, but it does not restore detail missing from the source. Lowering it can reduce file size; inspect the result for visible blocking, smearing or loss of texture before encoding a long programme.
For example, an intended 1080p output at 25 fps falls in the standard-rate column, while an output at 50 fps falls in the high-rate column. This is only a way of reading YouTube’s upload reference. It does not imply that the source should be converted to either frame rate, nor that the same numbers should be entered into a live encoder.
Set FFmpeg output options carefully
FFmpeg’s generic -b bitrate option is specified in bits per second. An 8 Mbps reference corresponds to 8000000 bits per second, or the equivalent 8M suffix where accepted. That is a translation of units, not a complete instruction to use a fixed-rate encode. YouTube describes VBR; how you configure rate control depends on the encoder you choose and the options it supports.
A command is therefore best treated as a template only after its assumptions are clear. For an input that is already the desired size and frame rate, a basic H.264-in-MP4 workflow might select an H.264 video encoder, copy or encode audio as appropriate, and set a bitrate-related option supported by that encoder. If you need scaling, deinterlacing, colour conversion or a different frame rate, those choices must be added deliberately. There is no universally correct one-line command for unknown input.
The encoder-specific options matter. FFmpeg’s general documentation describes the command-line interface, and its codec documentation documents codec options; an installed build may expose different encoders and capabilities. Check available encoders and their help output on the actual VPS. Do not assume that an option written for one H.264 encoder has the same meaning or effect for another.
A bitrate target, a maximum rate and a buffer size are distinct rate-control concepts. A command copied from a live-stream tutorial may include settings intended to constrain a real-time feed; that does not make them necessary for an upload encode. For upload preparation, choose the rate-control mode and quality/file-size balance supported by your selected encoder, then verify the output. If a constant-quality mode is available, understand that the resulting bitrate can vary with content and may not land on a particular reference number.
For audio, preserve a suitable source track or encode it to a format accepted by YouTube’s guidance, with the stated sample rate where appropriate. Check channel layout and synchronisation in a sample. If the video is a visual loop with music or spoken content, audio quality and continuity still matter; see the separate guide to improving audio quality on a live stream for listening checks that also apply to prepared material.
Check encoding and transfer on the VPS
Encoding and file transfer are separate measurements. A VPS can finish an encode quickly but take longer to send a large file, or encode slowly while still having ample outbound capacity. Record the input, output settings, FFmpeg build, encoder, preset and elapsed encode time for a representative test. Then measure the upload separately, using the actual destination and route you plan to use.
Video encoding is CPU-intensive, but a Hetzner product name alone does not tell you how long your particular job will take. Hetzner’s Cloud FAQ distinguishes shared-resource instances from dedicated-resource instances; the latter provide exclusive CPU resources and are recommended for CPU-intensive applications and predictable production workloads. This is a distinction in resource allocation, not a published guarantee of a particular encode time. Your input, encoder, preset, resolution and concurrent work still matter.
Benchmark the real job on the target VPS. Use a representative section that includes the kind of movement and detail found in the full programme. Compare output appearance, file size and elapsed time, and make one change at a time. A slower preset may take more CPU time while producing a different compression result; which trade-off is acceptable depends on how often you prepare files and when they need to be ready. No result from a short test establishes a guaranteed time for a longer or different file.
After encoding, check the file before transferring it: confirm that the duration is plausible, the resolution and frame rate are what you intended, audio plays, and the image has no obvious scaling or colour problems. Then estimate the transfer from the actual file size and measured upload rate. Keep units consistent: Mbps describes bits per second, while file size is often shown in bytes. A transfer estimate is only an estimate because the rate can vary.
Hetzner’s outgoing traffic allowances vary by Cloud product family and location. Its traffic documentation lists product-specific figures, but do not assume one allowance applies to every VPS. Check the current Hetzner traffic information for your exact product and region, and account for repeated uploads as well as the initial file. If your upload workflow sends large files regularly, traffic planning may matter as much as the one-time encode.
The wider channel workflow can also affect your choice of hosting and file preparation. If you are estimating recurring costs, use the actual plan and region rather than treating one example as universal; the Hetzner VPS cost guide for an always-on YouTube stream is a relevant starting point, but confirm current terms with the provider.
When repeated preparation on a personal computer is the pain point, StreamNeo can take an uploaded video and run it as a YouTube live stream without keeping your computer on; it is a separate broadcast workflow, not a way to determine FFmpeg’s upload bitrate.
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
Are YouTube’s upload bitrate figures required maximums?
No. YouTube presents them as recommended references and says no bitrate limit is required. They are for upload encoding guidance, not live ingest requirements or a quality guarantee.
Should I always upscale a 720p source to 1080p?
No. Upscaling changes the output dimensions but does not recover detail that was not captured. Keep the source dimensions unless you have a clear delivery reason to resize, and check aspect ratio to avoid stretching or unwanted cropping.
Can I predict encode time from my Hetzner VPS plan?
Not reliably from the plan name alone. CPU allocation, source, encoder, preset, output settings and concurrent workload all affect the result, so benchmark a representative job on the target instance.
Does the VPS’s encoding speed tell me how long the upload will take?
No. Encoding creates the file; transferring sends it to YouTube. Measure those stages separately, and check the outgoing traffic allowance for your exact Hetzner product and region before planning repeated uploads.