YouTube SDR uploads: BT.709 and what to check on a Sume MP4

YouTube recommends BT.709 as the color space for SDR uploads, along with 4:2:0 chroma, progressive scan and an MP4 whose moov atom is at the front. Of those, Sume's docs state only one: precision: exact in video trim re-encodes with libx264 and yuv420p, which is 4:2:0. The rest you verify on the file.

What YouTube recommends

What the Sume docs say

Video trim exact precision is a frame-accurate re-encode with libx264 and yuv420p; keyframe precision is a stream copy, so it keeps whatever the source had. The docs do not mention color space, scan type, B-frames or Fast Start for any Sume tool, so this post does not claim a Sume file meets them.

Video inspect returns a probe and stills and never re-encodes. Among the probe fields, the docs name only has_audio, so use a local tool for the rest.

Check the file

Download the finished MP4 and ask ffprobe for the fields that matter. Only trust what it prints:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,profile,pix_fmt,field_order,color_space,r_frame_rate \
  -of default=nw=1 clip.mp4

Reading the output

• pix_fmt=yuv420p matches 4:2:0.
• field_order=progressive matches the progressive-only line.
• color_space=bt709 matches the SDR recommendation. If it is unknown or empty, the file is untagged. YouTube's page does not say what it does with untagged files, so retag or re-encode before you rely on it.
• r_frame_rate should be one of the listed rates.

Why bother

Color tags tell a player how to interpret the numbers in the file. A file with no tag leaves that to the player's default, and the page's recommendation is the way to remove the ambiguity. The check takes seconds and runs on the downloaded file, so it fits at the end of a pipeline just before upload.

Do the same check on a file that has been through several tools. Each re-encode is a chance for tags to change, and the last file in the chain is the one that counts.

When something is off

If the color tag is wrong or missing, fix it with your own encoder, since Sume's trim API rejects client codec and filter fields (ffmpeg_fields_rejected). Compare a still against the original on screen before you publish.