YouTube asks for 4:2:0 chroma: keyframe trim copies, exact writes it

If your camera file is 4:2:2 and YouTube asks for 4:2:0, cut it with video trim precision exact. Exact is a frame-accurate re-encode with libx264 and yuv420p, which is 4:2:0 chroma. Keyframe precision is a stream copy, so the output keeps whatever format the source had. Both cost $0.02 per job; the difference is what leaves the worker.

YouTube's recommended upload settings page (read 2026-10-09) lists H.264, progressive scan, High Profile, chroma subsampling 4:2:0, and an MP4 container. It also lists AAC-LC, Opus or Eclipsa audio, and says to upload at the frame rate you recorded.

Two precisions, two outcomes

Sume's video trim doc defines both modes. Exact re-encodes the video (libx264, yuv420p) and remuxes kept audio as AAC. Keyframe uses stream copy: it is fast, but the cut can start a GOP early, and the codec and pixel format are the source's. The result reports actual_start_seconds so you can re-base your times.

What Sume does not let you set

The YouTube page also names a closed GOP at half the frame rate, two consecutive B frames, CABAC, variable bitrate, and no edit lists. Sume does not expose those. The trim API refuses vf, filter, ffmpeg, cmd, codec and crf fields with ffmpeg_fields_rejected, because the server compiles ffmpeg itself. This post therefore claims only the two things the trim doc states: libx264 with yuv420p on exact, and a copy on keyframe.

If your pipeline needs one of the other settings verified, inspect the delivered file with your own tools after download. Sume does not claim they match.

What to check afterward

Download one output and look at its properties in a tool you trust before you push a batch. Sume reports actual_start_seconds and duration_seconds in the job result, and the result video_url is a new artf_ file, never the source. If a job is replayed with the same Idempotency-Key you get the same job back rather than a second charge, which is useful when a script retries after a network error.

Where the line is in the docs

Everything above comes from two places: the YouTube page for the 4:2:0 requirement, and Sume's video trim page for the exact and keyframe behavior. Sume's catalog lists the trim price at $0.02 per job, and the doc says there is no provider inference, only worker ffmpeg. That means the price does not change with the clip's content and a repeat of the same request with the same Idempotency-Key returns the same job.

A practical rule

Use exact whenever the file is going to a platform with a stated pixel format, and use keyframe only for a quick preview where a slightly early start is fine. Exact is also the only mode that accepts the output object (width and height 256 to 2160, fps 24, 25, 30 or 60), so a resize and a chroma fix can ride in the same $0.02 job.