To change the resolution YouTube receives from FFmpeg on an OVHcloud VPS, set the output dimensions with FFmpeg’s scale video filter. YouTube normally detects the dimensions and frame rate arriving at ingest; it does not apply that filter for you.
A resolution change is not just a width and height. You also need to check which input stream is being encoded, the video codec and bitrate, frame rate, keyframe interval, and whether the VPS can encode and send the result steadily. Treat the command below as a pattern to adapt and test, not as a guaranteed recipe for a particular OVHcloud plan.
Output dimensions and YouTube detection
The scale filter changes the pixel dimensions of the video that FFmpeg sends. If you ask FFmpeg to produce 1280 by 720, the outgoing encoded video should be 1280 pixels wide and 720 pixels high, assuming the filter is attached to the video stream that is actually mapped to the output. YouTube receives that stream and identifies its incoming resolution. It may then create different playback formats for viewers.
In the usual Live Control Room workflow, YouTube detects the incoming resolution and frame rate automatically. Its live encoder settings guidance also describes manual resolution selection for creators using a custom stream key. That setting affects how YouTube handles stream selection; it does not resize your source or replace FFmpeg’s filter. If you need exact output dimensions, set them in FFmpeg and confirm what arrives in YouTube.
This distinction is useful when the preview does not show the resolution you expected. A YouTube setting cannot correct an incorrectly scaled or mapped FFmpeg output. Conversely, a correct FFmpeg command does not mean that every viewer will receive the same playback resolution: YouTube processes live input and offers playback variants, and viewers’ devices and connections affect what they can select.
Before changing a long-running channel, identify the source file’s dimensions and aspect ratio, desired output dimensions, frame rate, and audio arrangement. A 1920 by 1080 source scaled down to 1280 by 720 is straightforward. A portrait, square, or unusually wide source needs an explicit decision about whether to preserve its shape, crop it, or add bars to fit a fixed canvas.
Set output size with the FFmpeg scale filter
FFmpeg’s -vf option is a shorthand for applying a video filter. A direct example is:
-vf "scale=1280:720"
For a 1920 by 1080 output, use -vf "scale=1920:1080". Place the filter in the output processing path before the output destination. These examples specify dimensions, but they do not specify the rest of a working YouTube stream: input, stream mapping, encoder, audio, bitrate, keyframes, container and ingest URL all matter.
If you want to preserve the source aspect ratio while setting a target height, a common expression is:
-vf "scale=-2:720"
Here FFmpeg derives the width from the input proportions; -2 asks for a width that is divisible by two, useful with common video encoders. Check the result rather than assuming the input is 16:9. If the video must fill a fixed 16:9 canvas, scaling alone may leave unused space or distort the picture. You can instead preserve proportions and pad the remaining area, or crop deliberately, depending on whether the entire source image must remain visible.
A command shape for a typical file input might look like this:
ffmpeg -re -i input.mp4 \
-vf "scale=1280:720" \
-c:v libx264 -b:v 4500k -maxrate 4500k -bufsize 9000k \
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k \
-f flv "rtmps://YOUR_YOUTUBE_INGEST/YOUR_STREAM_KEY"
This illustrates where the scale filter fits, not a tested or universal bitrate prescription. Replace the placeholder ingest address and key with the values YouTube supplies, and keep the key private. Adjust the encoding options to the content, desired frame rate, current YouTube guidance and measured capacity. Confirm the installed FFmpeg build supports the selected filters and encoder; its filter documentation describes the scale filter syntax.
Adapt the example to the input and stream mapping
The simple command assumes the input has one relevant video stream and one relevant audio stream. Real files may have multiple audio tracks, subtitles, attached images, or more than one video stream. FFmpeg’s automatic stream selection can choose a stream other than the one you intend. Add explicit -map options when needed, such as selecting a particular video and audio stream, then ensure the scale filter applies to that video path.
For example, a command may use -map 0:v:0 -map 0:a:0? to select the first video stream and, if present, the first audio stream from input zero. The question mark makes the audio mapping optional; omit it if audio is required and you want FFmpeg to fail clearly when none exists. Mapping syntax and filter placement can vary with more complex filter graphs, so inspect the input and command output rather than copying this fragment blindly.
If the source is already encoded to a suitable size and codec, you may not need to scale or re-encode it. FFmpeg’s stream-copy mode avoids video re-encoding, but cannot change dimensions: a scale filter requires decoding and encoding the video. The distinction is explained in this guide to streaming a pre-encoded H.264 playlist with copy mode. Use copy mode where the source already matches your delivery requirements; use a filter and encoder where you need different dimensions or other video changes.
After starting the process, inspect FFmpeg’s startup information and logs for the input and output stream descriptions. The output should report the dimensions you asked for. If it reports the source dimensions instead, check that the filter is attached to the output video stream and that you are reading the output description, not only the input. If the dimensions are right but the image looks stretched, revisit aspect ratio and padding or crop choices.
Check video codec, bitrate and frame rate
Resolution works together with codec, frame rate and bitrate. A higher resolution and more motion generally require more data to preserve detail. A higher frame rate gives more temporal detail but increases the encoding and delivery workload. Choose a combination that fits the content and the upload capacity rather than raising the dimensions in isolation.
For RTMP or RTMPS ingest, YouTube’s current encoder settings guidance lists supported video codecs and recommends constant bitrate encoding. It also lists AAC or MP3 audio. H.264 with AAC is a common broadly compatible combination, but check the current official guidance for your ingest route and requirements. YouTube recommends RTMPS, a secure extension to RTMP.
The bitrate figures below are YouTube’s recommended H.264 ingest bitrates, not promises of visual quality, viewer playback resolution, or encoding capacity on an OVHcloud VPS. They are values in YouTube’s guidance checked in 2026; verify the current table before an event.
| FFmpeg output | YouTube recommended H.264 bitrate |
|---|---|
| 720p at 30 fps | 3 Mbps |
| 720p at 60 fps | 8 Mbps |
| 1080p at 30 fps | 5 Mbps |
| 1080p at 60 fps | 6 Mbps |
| 1440p at 30 fps | 21 Mbps |
| 1440p at 60 fps | 34 Mbps |
| 2160p at 30 fps | 42 Mbps |
| 2160p at 60 fps | 50 Mbps |
The table is a starting point for the video bitrate. Add audio bitrate and allow outbound headroom; do not size the stream at the exact advertised network ceiling. In the example command, -b:v, -maxrate and -bufsize are video encoder controls. The sample values are not appropriate for every resolution or content type. A static devotional image with a gentle animation behaves differently from a fast-moving local news loop, but neither removes the need to test the actual stream.
Use -r only when you intend to set the output frame rate. If the source is 25 fps and your planned output is 30 fps, that may involve duplicated frames and more encoding work without adding source motion. Conversely, outputting 30 fps from a higher-frame-rate source discards temporal detail. Match the frame rate to the source and event where practical, then compare YouTube’s current recommendation for that resolution and frame rate. The YouTube bitrate settings guide for ambient live streams provides another useful context for balancing sustained video settings.
Set and verify the keyframe interval
YouTube recommends a keyframe frequency of two seconds and says not to exceed four seconds in its encoder guidance. For an output at 30 frames per second, a keyframe every 60 frames corresponds to two seconds. That is why the illustrative command uses -g 60 and -keyint_min 60, with -sc_threshold 0 to prevent scene-change keyframes from changing the interval in this example.
The relationship is frame rate multiplied by the desired interval in seconds. At 25 fps, two seconds corresponds to a 50-frame GOP; at 60 fps it corresponds to 120 frames. If you alter -r, review the GOP settings as well rather than leaving a frame count intended for another rate. Encoder options do not behave identically across all codecs, so check the documentation for the encoder you selected.
A keyframe interval is not the same thing as bitrate or resolution. It governs how often the encoder emits a full reference frame, which helps the receiving system and playback pipeline work with the stream. An interval that conflicts with YouTube’s current guidance can trigger ingest warnings even where the picture dimensions are correct. Check the stream health messages after connecting, especially after changing frame rate or codec.
For a continuous channel, test a full representative section rather than only watching FFmpeg’s first line of output. A stream can connect successfully and still have periodic encoder delay, bitrate variation, or audio problems later. If you are also checking sound, this guide to finding and fixing buzzing noise in a live stream covers a separate fault that can be mistaken for a general streaming problem.
Test the output in YouTube Live Control Room
Start with a private or otherwise appropriate test broadcast, using the actual input file, audio, frame rate and movement expected in the channel. YouTube advises testing with audio and movement similar to the event, and its help page says, “We recommend running a speed test to test your upload bitrate.” A speed test is useful, but it is not proof that the VPS can encode the video in real time or that the route will behave identically during a long broadcast.
In Live Control Room, check the incoming stream’s detected resolution and frame rate, stream health, and any warnings or messages. Compare the dimensions shown there with FFmpeg’s output stream information. If they disagree, first confirm the correct FFmpeg process and stream key are feeding the event, then check output mapping and filtering. Avoid changing several settings simultaneously: isolate the filter, frame rate, codec or bitrate change so you can identify which one resolved the discrepancy.
If you use a custom stream key with manual resolution settings, review those settings in the Control Room. For most setups, automatic detection is the ordinary path; manual configuration is not a substitute for setting the dimensions at the encoder. Keep the preview open long enough to catch fluctuations and inspect both picture and sound. A still image may conceal problems that become visible when the loop changes scenes or contains motion.
If a stream reports a bitrate issue, compare your selected encoder settings with YouTube’s current table and then check actual outbound use. If it reports dropped or delayed frames, distinguish network delivery from encoding lag by observing the FFmpeg process and host load. For broader connection troubleshooting, the article on sending video to YouTube Live through streaming ingestion explains the ingest path and the role of the encoder.
Measure host capacity before raising resolution
An OVHcloud VPS is a host for the FFmpeg workload, not a guarantee that a given resolution will encode at a given frame rate. Software encoding draws CPU, and higher output dimensions or more complex encoding can increase that work. The outgoing bitrate also consumes network capacity. The plan’s allocated vCPU, memory and public bandwidth do not, by themselves, establish the sustained real-time performance of your particular input and command.
Measure on the actual VPS with representative content. Watch CPU usage, memory use, FFmpeg’s reported speed, and whether the process can keep pace with real time. Observe network traffic and compare it with the combined video and audio bitrate, leaving room for variability and other workloads. If FFmpeg falls behind or YouTube reports unstable ingest, test a lower resolution, frame rate, or encoding complexity one change at a time. Consider hardware encoding only if a compatible option is available and suits your workload; scaling itself does not require a GPU.
OVHcloud lists different resources and bandwidth allocations across its VPS configurations, and its offerings and regional terms can change. Check the current configuration in your OVHcloud account and its VPS product information, rather than relying on an old comparison or assuming an advertised bandwidth figure is continuously available to this process. OVHcloud also offers separate Cloud GPU services; check current regional availability and supported hardware before treating one as a possible encoding route.
If the channel must run overnight, a short launch test is not enough. Leave the target command running long enough to observe normal changes in the playlist and resource use, then review the logs and stream health. Plan a rollback setting you can switch to if the higher output falters. For a channel moving from a home computer to a VPS, the practical considerations in moving a 24/7 YouTube music stream from a PC to a VPS are relevant beyond the resolution setting itself.
A cloud-running broadcast can remove the need to keep a local computer switched on, but it does not remove the need to choose settings and confirm what YouTube receives. StreamNeo is relevant when the operational pain is keeping a file-based channel running after your own computer is off: upload the file once, provide your YouTube stream key, and the broadcast runs from the cloud with monitoring and automatic restart if it drops. It is YouTube-only, so it is not a fit if you need a different destination or direct control over an FFmpeg process on your VPS.
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
Does YouTube change the resolution I set in FFmpeg?
FFmpeg’s scale filter sets the dimensions of its outgoing video. YouTube detects the incoming stream and may transcode it into playback formats; that is separate from resizing the input in your FFmpeg command. Check the incoming resolution in Live Control Room after a test.
What scale expression should I use for 720p?
Use scale=1280:720 when you want an exact 1280 by 720 output canvas. If you want to preserve a non-16:9 source’s aspect ratio at 720 pixels high, scale=-2:720 lets FFmpeg derive a compatible width. Confirm the resulting shape and decide whether padding or cropping is needed.
Will a particular OVHcloud VPS run 1080p reliably?
No tier can be assumed to guarantee a resolution or frame rate from its resource listing alone. Test your actual input, encoder options and target bitrate on the VPS you will use, while monitoring CPU, real-time encoding pace, network use and YouTube stream health. Reduce workload or assess suitable hardware encoding if the process cannot keep up.
Should I use YouTube’s manual stream resolution setting?
YouTube normally detects resolution and frame rate automatically. Manual resolution options are available with a custom stream key, but they do not replace FFmpeg’s scale filter. Set the intended output at the encoder, then use the Control Room to verify what arrived and investigate warnings.