Trim an HDR clip: why precision keyframe works and exact does not

Sume video trim handles an HDR clip differently depending on precision. With precision: "exact" (the default) the job fails with hdr_source_unsupported and next_action: use_precision_keyframe_or_sdr_source. With precision: "keyframe" the cut succeeds, because it is a stream copy.

This is the rule in the trim worker, read 2026-10-05: an exact cut re-encodes to libx264 and yuv420p, an 8-bit SDR pixel format, and that would silently flatten PQ or HLG footage. A keyframe cut copies the compressed stream untouched, so there is nothing to flatten and HDR passes bit-exact.

What you give up with keyframe

A keyframe cut can only start on a keyframe, so the output may begin a GOP early. The result reports actual_start_seconds, and the video trim docs tell you to re-base your later times against it. The output conform object (width, height, fps) is exact-only, so a keyframe cut with output returns video_trim_output_requires_exact.

A safe request for an HDR source

Ask for the copy cut explicitly and read the real start from the result.

curl -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: hdr-cut-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/hdr.mp4",
    "start": 12,
    "duration": 20,
    "precision": "keyframe"
  }'

Choosing between the two

If the clip is going to a timeline or a filter later, remember both of those stages also need SDR. A keyframe cut keeps HDR for archive or delivery, not for the next Sume stage.