Video filter hdr_source_unsupported: what to do with an HDR clip

A Sume video filter job fails with hdr_source_unsupported when the clip is HDR, meaning its transfer characteristic is PQ (smpte2084) or HLG (arib-std-b67). The job stops before any encode, and the error carries next_action: use_sdr_source and the color_transfer it saw. No re-encode runs that would have damaged the picture.

The reason is in the worker code, read on 2026-10-05: a luma multiply inside a PQ or HLG signal is not a dim in linear light, and the yuv420p output would drop the mastering metadata silently. Rather than return a clip that looks wrong, the filter refuses with a named code. The worker's error message calls it a v1 limit; see the video filter docs for the rest of the filter contract.

Which clips trigger it?

Any source whose probed color_transfer is smpte2084 or arib-std-b67. Phones that record HDR video and some camera exports fall here. A normal SDR clip, with bt709 or no transfer tag, passes. The check applies to both filter ops (dim and crop) and to a filtergraph, because it runs on the source before the program.

Three ways out

• Start from an SDR export. Most phones and editors can export an SDR copy of an HDR clip. Import that file instead and resubmit.
• Skip the pixel pass. If you only needed a crop for the shape, trim with precision: "keyframe", which copies the stream and lets HDR through, then crop in your delivery tool.
• Check first. A video inspect probe returns hdr: true for the same two transfers, so a pipeline can branch before it submits anything.

Check before you submit

The free POST /v1/video-filter/check validates the program and the source preflight without creating a job. It does not run the encode, so the HDR refusal itself comes from the worker probe, not the check. The inspect probe is the earlier and cheaper signal.

Treat hdr_source_unsupported as a routing signal, not a retryable failure. Resubmitting the same clip returns the same error.