For ordinary SDR H.264 sent to YouTube Live over RTMP or RTMPS, yuv420p is a sensible compatibility-first pixel format when your chosen encoder supports it. It is a recommendation, not a YouTube requirement: YouTube’s published live settings do not mandate that exact pixel-format string.
The right setting depends on the output you are making and the encoder in your FFmpeg build. Use the SDR guidance below for an SDR stream; treat HDR as a separate workflow with different bit-depth and colour requirements.
Why pixel format matters
A pixel format describes how video samples are represented and arranged before encoding. It affects such things as chroma sampling and bit depth, and it must be understood by the encoder receiving the frames. It is only one part of the path from your source file to the live ingest point: the codec, colour interpretation, resolution, frame rate, bitrate, and connection also matter.
For a pre-recorded stream, FFmpeg reads frames from a file and prepares them for an encoder. The pixel format in the source file may not be the same as the format the encoder accepts or the format you ask FFmpeg to produce. FFmpeg may convert between formats when possible, but an unsupported conversion or encoder input can cause an error, a failed start, or a different output than you intended. The message from FFmpeg’s log is more useful than assuming that a flag is accepted merely because it appears in an example online.
Chroma subsampling is one reason formats differ. The yuv420p name indicates a planar YUV representation with 4:2:0 chroma sampling and 8-bit components. For typical SDR material, that is a widely used target in H.264 workflows. It is not a universal quality setting, nor does the label itself guarantee that your colours, levels, or source conversion are correct.
YouTube’s live encoder guidance lists supported codecs and recommends settings such as Rec. 709 for SDR. It does not list yuv420p as a required input format. YouTube also says it transcodes incoming live video into output formats for viewers, so the ingest configuration and what viewers eventually receive are related but not identical. See YouTube’s current live encoder settings when checking the official requirements for your stream.
Recommended SDR setting: yuv420p
If your target is standard-dynamic-range H.264 and your encoder accepts it, start with -pix_fmt yuv420p. That is a practical baseline for compatibility, especially in a familiar FFmpeg and libx264 workflow. It is not a claim that every FFmpeg encoder supports it, or that YouTube requires it.
YouTube’s guidance identifies SDR as 8-bit and recommends Rec. 709. Those points describe the intended SDR signal; they do not mean that any file tagged yuv420p is automatically colour-correct. A source file can have the wrong transfer characteristics or colour metadata, and conversion choices can affect the result. Check that your input is actually SDR and that the colour handling in your workflow preserves the expected interpretation.
For a simple SDR H.264 output, a command-line fragment might include:
-c:v libx264 -pix_fmt yuv420p
This fragment sets an encoder and pixel format; it is not a complete streaming command. You still need to supply the input, video rate control, audio settings, output target and other parameters appropriate to your workflow. If you are adapting a working command, change one setting at a time so that a new failure is easier to diagnose.
There are situations where another format is appropriate. A hardware encoder may prefer or require a different input format, and an HDR delivery path needs different bit depth and colour handling. Do not force yuv420p just because it worked for a previous SDR stream. Start from the intended output and the formats accepted by the actual encoder.
If you are building a continuous channel rather than testing a one-off broadcast, the surrounding command and recovery plan matter as much as this flag. The walkthrough on streaming Punjabi kirtan 24/7 with FFmpeg is relevant to the broader pre-recorded-file workflow; use it for operating context, not as a substitute for verifying your own encoder’s formats.
Set -pix_fmt in FFmpeg
The -pix_fmt option requests an output pixel format. In a typical output command, put it with the video output options and before the destination. For example:
ffmpeg -re -stream_loop -1 -i programme.mp4 \
-c:v libx264 -pix_fmt yuv420p \
-f flv "rtmp://example.invalid/live/STREAM_KEY"
The address above is a placeholder, not a usable YouTube destination. Use the ingest address and stream key YouTube provides for your live stream, and keep the key private. The example illustrates option placement only; it does not set a complete bitrate, frame rate, audio configuration, or reconnect policy.
FFmpeg options are associated with inputs or outputs according to where they appear. Put output options in the output portion of your command, after the input they apply to and before the output target. If you place an option in the wrong position, it may apply differently than intended or be ignored for the output you are troubleshooting. Check the command and log together rather than moving flags at random.
A useful first test is to run the command against a short representative segment or a private/unlisted test broadcast, then inspect FFmpeg’s output and YouTube’s stream-health feedback. Avoid changing the pixel format, codec, rate control and frame rate simultaneously. If the result changes, you want to know which adjustment caused it.
A pixel-format flag is not a promise to convert every source sensibly. If the source and requested output differ, FFmpeg’s conversion path, colour metadata and any filters in your command can affect the signal. If you use filters such as scaling, overlays or colour correction, examine the format at the end of the filter chain as well as the encoder’s accepted inputs. A filter may produce a format that then requires conversion for the encoder.
For a continuous stream, a process that starts successfully still needs operational checks. A disconnected output or a process that stops later is not necessarily a pixel-format problem. The guide to fixing FFmpeg’s broken pipe when streaming a playlist can help distinguish output failures from an initial encoding configuration issue.
Check encoder and build support
Do not assume the same FFmpeg command behaves identically on every machine. The available encoders depend on how FFmpeg was built and which libraries or platform encoders are present. Even where an encoder name is available, accepted input formats can differ by encoder and build configuration.
Inspect your local build before settling on a format. ffmpeg -encoders can show encoder names compiled into the executable. For details about a particular encoder, use the encoder help output, for example:
ffmpeg -h encoder=libx264
Look for the supported pixel formats in the result and confirm that the encoder you intend to use accepts the requested one. If the information is missing or ambiguous, consult the documentation for that exact encoder and build, then verify with a short encode. FFmpeg’s codec documentation explains the libx264 wrapper and notes that supported 8- to 10-bit colour spaces depend on configuration.
The distinction matters on hardware-accelerated paths. FFmpeg’s MediaFoundation documentation, for example, describes nv12 and yuv420p as formats that video encoders may accept, while warning that some accept only one. Its advice is specific to those encoders, not a general rule for every hardware encoder. The FFmpeg documentation for MediaFoundation is useful if that is the path you are using; for other hardware encoders, check the relevant local encoder help and vendor documentation.
If yuv420p is rejected, do not treat that as proof that the YouTube ingest settings are wrong. First establish which encoder is active and what it accepts. You may be able to choose another supported input format, use a different encoder, or change the build. Any alternative should be tested through the full path, including the stream-health page, rather than judged solely by whether FFmpeg starts.
SDR colour and the rest of the live settings
Pixel format and colour space are related but not interchangeable. yuv420p says something about sample representation and chroma sampling; it does not by itself label the video as Rec. 709 or repair incorrect colour metadata. For SDR, follow YouTube’s Rec. 709 guidance and make sure any conversions, filters or source tags are appropriate for the material you are sending.
YouTube’s recommendations also cover settings that a pixel-format flag cannot fix. Its guidance recommends constant bitrate (CBR), a keyframe interval of two seconds and says not to exceed four seconds. For H.264, it lists recommended bitrates of 14 Mbps for 1080p at 30 fps and 17 Mbps for 1080p at 60 fps. These are YouTube’s published recommendations, not independent measurements or a guarantee that a particular upload connection will sustain them. Check the current official page for the resolution and frame rate you plan to use.
| Output example | YouTube recommended video bitrate | Pixel-format starting point |
|---|---|---|
| H.264, 1080p at 30 fps, SDR | 14 Mbps | yuv420p, if the encoder accepts it |
| H.264, 1080p at 60 fps, SDR | 17 Mbps | yuv420p, if the encoder accepts it |
| AV1 or H.265, 1080p at 30 fps | 10 Mbps | Check the selected encoder and workflow |
The table brings together separate choices rather than making them equivalent: bitrate depends on the codec, resolution and frame rate; pixel format depends on encoder support and the signal you intend to send. Leave headroom in your upload connection and test the actual stream. A nominally correct bitrate can still fail if the connection is unstable or another part of the command is misconfigured.
When sending an existing programme on a loop, check for format changes within the file and for audio that ends or drifts differently from the video. A pixel format suitable for the opening frames does not resolve an input file that has inconsistent properties or a stream that is interrupted by a network issue. A Linux VPS guide for continuous pre-recorded YouTube streaming covers the wider operating choices; the encoding settings still need to match the actual source and encoder.
When HDR needs a different workflow
Do not apply the SDR yuv420p recommendation to HDR. YouTube’s general live guidance identifies 10-bit HDR and recommends H.265 for HDR, while its documented HLS HDR ingestion path specifies a distinct set of requirements. HDR depends on more than choosing a pixel-format name: bit depth, colour primaries, transfer characteristics and the ingestion route must line up.
For the HLS HDR path, YouTube’s documentation specifies HEVC video, AAC audio, M2TS muxing, closed GOPs and 10-bit YUV 4:2:0. It also specifies Rec. 2020 primaries and matrix, with PQ or HLG transfer. These are instructions for that documented HLS route; do not silently apply them to RTMP/RTMPS or to a different workflow. Read the YouTube Live Streaming API HLS ingestion guide before configuring an HLS HDR stream.
A 10-bit pixel format is not a complete HDR configuration. The source needs to be HDR, the encoder must support the required format, and the correct metadata and transfer characteristics must survive the processing chain. An 8-bit SDR source does not become HDR because you select a 10-bit output format. Likewise, choosing a format that has 4:2:0 sampling does not establish that the colour primaries or transfer function are right.
If you are not deliberately producing HDR and have not checked the encoder, metadata and ingest protocol, keep the stream in SDR and use the SDR recommendations. If the source is HDR or the channel requires HDR delivery, validate that separate workflow with a representative test before relying on it for a scheduled broadcast.
Test the outgoing stream before relying on it
A short local encode checks whether FFmpeg can run the command, but it does not prove that YouTube accepts or correctly processes the live output. Test the complete path with the same file, encoder, output settings, network connection and ingest route you plan to use. Review the FFmpeg log for negotiation or conversion messages, then check YouTube’s stream-health indicators for warnings.
A useful test sequence is to confirm the input file’s properties, inspect the encoder’s supported pixel formats, start a brief encode, and then send a private or unlisted test stream. Confirm that the picture is present, that the expected colour appearance is retained, and that audio and video continue together. Look for encoder errors, dropped connection symptoms and health warnings rather than treating a single successful start as proof that a 24/7 run will remain healthy.
Change one variable at a time when debugging. If the encoder refuses yuv420p, address supported formats. If the stream starts but YouTube reports a connection or bitrate issue, investigate those factors separately. If the image looks washed out or has unexpected colour, investigate source and colour metadata as well as conversion; changing pixel format alone may not fix it.
For an always-on channel, also think about what happens after a process or connection failure. A desktop that is switched off cannot keep a local FFmpeg process running. StreamNeo removes that specific always-on computer burden: you upload the video, provide the YouTube stream key, and the broadcast can continue without your computer running, with monitoring and automatic restart if it drops. It is YouTube-only, so it is relevant when that is the destination; it does not remove the need to choose a suitable source file and stream settings.
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 yuv420p required by YouTube Live?
No. YouTube’s published live encoder settings do not state that exact pixel format as a requirement. For ordinary SDR H.264 over RTMP or RTMPS, it is a reasonable compatibility-first choice when your selected encoder supports it.
What should I use if FFmpeg rejects yuv420p?
Check which encoder your command is using and inspect the supported pixel formats for that encoder in your installed build. Choose a format it accepts or use a different supported encoder, then test the resulting stream rather than assuming that a successful local encode proves the live path is correct.
Can I use this SDR advice for an HDR stream?
No. HDR has different bit-depth and colour requirements, and YouTube’s HLS HDR documentation describes a specific ingestion route. Confirm the protocol, encoder support, colour metadata and current official requirements for the HDR workflow you intend to use.
Does -pix_fmt yuv420p fix poor stream quality?
Not by itself. It only requests a pixel format; bitrate, frame rate, source quality, colour handling, network stability and the other encoder settings still affect the result. Test the full output and use YouTube’s stream-health feedback to identify problems.