yuv420p10le vs yuv420p: 8-bit vs 10-bit pixel formats

yuv420p and yuv420p10le are the same pixel layout at two bit depths. Both are planar YUV 4:2:0: a full-resolution luma (Y) plane plus one Cb and one Cr sample for every 2×2 block of luma samples. yuv420p stores 8 bits per sample; yuv420p10le stores 10 bits per sample, each in a 16-bit little-endian word, which is what the "10le" means.

The format definitions come from FFmpeg's pixel format reference and its ffmpeg, filters, and codecs documentation, the platform notes from YouTube's, X's, and Vimeo's own pages, and the Sume facts from the Video trim, Video filter, and Video inspect docs and the Sume API reference, all read on 2026-09-28. Anything described as current behavior is read from Sume's code.

What is the difference between yuv420p and yuv420p10le?

The bit depth, and with it how each sample is stored. FFmpeg's reference lists yuv420p as "planar YUV 4:2:0, 12bpp" and yuv420p10le as "planar YUV 4:2:0, 15bpp" and little-endian, and its colorspace filter calls yuv420p "YUV 4:2:0 planar 8-bits" and its 10-bit counterpart "YUV 4:2:0 planar 10-bits". More bits give each color more shades: Vimeo's guide says a lower bit depth makes "sharp delineations between color changes" more likely, and it recommends "a bit depth of 10 or greater for the highest quality results."

The 4:2:0 part is what delivery specs pin down: YouTube's recommended upload settings list 4:2:0 chroma subsampling, and X's media docs say only YUV 4:2:0 is supported. Both formats here are 4:2:0.

Is yuv420p10le the same as HDR?

No. The pixel format says how many bits each sample has; whether a video is HDR depends on its transfer function, which the file carries as separate color metadata. A 10-bit file can be SDR. Vimeo, for example, counts a file as HDR only with a bit depth of 10 or greater and a PQ (SMPTE 2084) or HLG transfer function.

Sume's probe reports the two separately. POST /v1/video-inspect with frames: false is an unbilled, probe-only inspect of a Sume-hosted clip. Its probe carries pix_fmt, color_transfer, and hdr, which the API reference defines as true for PQ and HLG transfers. Get a video's duration, resolution, and fps covers the rest of the probe, and how to check a video's codec shows an ffprobe command that prints a file's pixel format.

How do I convert yuv420p10le to yuv420p with FFmpeg?

Re-encode the video with -pix_fmt yuv420p. FFmpeg's docs say a stream copy can't apply filters, since filters work on decoded frames, so the video is encoded again; the audio can still be copied:

• -pix_fmt sets the output pixel format. If the encoder can't take the one you name, FFmpeg prints a warning and picks another format the encoder supports; prefix the name with + and it exits with an error instead.
• Inside a filter chain, the format filter does the same conversion; FFmpeg's own example is format=pix_fmts=yuv420p.
• Encoding 10-bit with libx264 instead depends on the build: FFmpeg's codecs docs say x264 supports 8- to 10-bit color spaces, with the exact bit depth controlled at x264's configure time.
• Watch flat areas for banding: FFmpeg's docs describe banding artifacts that are sometimes introduced into nearly flat regions by truncation to 8-bit color depth.
• A pixel format change doesn't turn HDR into SDR. That takes tone mapping; FFmpeg's tonemap filter docs show a zscale and tonemap chain that ends in format=yuv420p.

ffmpeg -i input.mp4 -c:v libx264 -pix_fmt yuv420p -c:a copy output.mp4

Which pixel format does Sume write?

yuv420p. The video trim docs name it for an exact trim, the default frame-accurate re-encode with libx264, and in current code video filter, Timeline compose, and Timeline render also encode with -pix_fmt yuv420p. There is no field to pick another: trim and filter, for example, refuse encoder fields such as codec and crf with ffmpeg_fields_rejected.

• A keyframe trim is the exception: it is a stream copy, so the result keeps the source's pixel format.
• The filter's crop op is even-rounded for yuv420p, and Timeline output edges must be even integers. FFmpeg's not-divisible-by-2 error explains why sizes stay even.
• Two tools refuse HDR instead of converting it: in current code an exact trim refuses PQ and HLG sources with hdr_source_unsupported, since its yuv420p output would flatten them, and the API reference says video filter refuses those sources too. Convert HEVC to H.264 covers HDR clips and the rest of the trim's settings.