Does Sume trim output match YouTube's H.264 and AAC recommendations?

Partly, and the docs let you say which part. YouTube's recommended settings (read 2026-10-08) name an MP4 container, H.264 video and AAC-LC audio. Sume's video trim docs say exact precision re-encodes with libx264 in yuv420p and remuxes kept audio as AAC. Those three items line up. Sume's docs do not state H.264 profile, B-frame count, closed GOP, CABAC, a fast-start moov atom or audio sample rate, so those points need a check on your own output.

Side by side

The left column is YouTube's list. The right column is only what the Sume docs say.

Why this is not a problem for most uploads

YouTube also publishes a longer list of file formats it accepts: MOV, MPEG-1, MPEG-2, MPEG4, MP4, MPG, AVI, WMV, MPEGPS, FLV, 3GPP, WebM, DNxHR, ProRes, CineForm and HEVC (H.265). MP4 with H.264 is on it. The encoding page is a recommendation for faster processing, and it is not a reject list. A re-encoded MP4 from Sume is inside the accepted formats.

Keyframe precision is different. It stream-copies the source, so the output keeps whatever codec the source had. The video trim docs say that precision can start a GOP early, so use exact when you want the libx264 and yuv420p output described above.

Check your own file

Run ffprobe on the downloaded file and compare it with the table. This command prints the codec, profile, pixel format, frame rate and audio settings:

ffprobe -v error -show_entries stream=codec_name,profile,pix_fmt,r_frame_rate,sample_rate,channels \
  -of default=noprint_wrappers=1 trimmed.mp4

What to do if a field differs

If the profile or sample rate is not what you want, Sume does not accept codec or crf fields on any media route: the docs refuse them with ffmpeg_fields_rejected, because the server compiles ffmpeg itself. The practical path is to upload the file anyway, since YouTube re-encodes on its side, and to keep the original frame rate. A trim is $0.02 per job, so re-running with a different output size costs little. For the file-size side of the same question, see the 8 Mbps arithmetic.

A Python check against YouTube's list

This script runs ffprobe on a downloaded trim result and compares four values with the YouTube recommendations quoted above. It checks only what ffprobe can report; closed GOP and CABAC need a deeper look and are left out.

If a field fails, YouTube will usually still accept the file, because its page is a recommendation for faster processing and its formats page lists many other containers. Treat a failure as a note to look at the source, not as a blocker.

import json, subprocess, sys

out = subprocess.run(
    ["ffprobe", "-v", "error", "-print_format", "json", "-show_streams", sys.argv[1]],
    capture_output=True, text=True, check=True,
).stdout
streams = json.loads(out)["streams"]
v = next(s for s in streams if s["codec_type"] == "video")
a = next((s for s in streams if s["codec_type"] == "audio"), {})
checks = {
    "h264": v.get("codec_name") == "h264",
    "high profile": v.get("profile") == "High",
    "4:2:0": v.get("pix_fmt") == "yuv420p",
    "aac": a.get("codec_name") == "aac",
    "48 kHz": a.get("sample_rate") == "48000",
}
for name, ok in checks.items():
    print(("ok   " if ok else "FAIL ") + name)