HDR phone clip through Sume video trim: exact mode outputs yuv420p

If you trim an HDR clip with Sume video trim in its default exact precision, the output is a frame-accurate re-encode with libx264 and yuv420p, according to the docs. Sume's docs do not document any HDR or 10-bit handling for that path, so do not promise an HDR deliverable from it. The keyframe precision is a stream copy, which does not re-encode, but the docs make no HDR promise there either: probe the result and look before you ship.

This post uses only Video trim and Video inspect, read on 2026-10-06.

What does each precision do?

The precision field decides how the cut is made.

How do I check what came out?

Run the result URL through video inspect. It returns a probe object for the clip without re-encoding anything, and probe plus stills are billed only by the Modal compute they use. Compare the probe of the source with the probe of the trim result, and only then decide whether the result is acceptable for an HDR workflow.

If a client needs HDR end to end, keep the HDR master outside Sume and use Sume for the preview, captions or social cuts, which are normal SDR deliverables.

• Trim exact: use it for social cuts where frame accuracy matters.
• Trim keyframe: use it when you only need a rough range and want no re-encode.
• Timeline renders also come out as MP4 jobs compiled by Sume; the docs list no HDR option on them.

Can I ask for 10-bit in the request?

No. Trim accepts precision, audio, and output with width, height and fps. Fields such as codec, crf and vf are rejected with ffmpeg_fields_rejected, because the server compiles ffmpeg itself.