fix(engine): exports carry full colour tags with every encoder, SDR and HDR - #5742

What changes for users

MP4/MOV exports encoded with VideoToolbox (macOS --gpu, or a macOS FFmpeg without libx264) now carry their full colour description:

• SDR: before, tagged color_space=bt709 but color_transfer and color_primaries unknown, so players guessed and could show a colour cast. Now bt709,bt709,bt709.
• HDR: before, tagged bt2020nc but transfer and primaries unknown, so players treated the export as SDR. Now bt2020nc, smpte2084 (PQ) or arib-std-b67 (HLG), bt2020.

libx264 and libx265 exports were already fully tagged and are unchanged.

Root cause

The encoders set colour two ways: on the frames through the conversion filters, and through -color_primaries / -color_trc output options (plus x264/x265 params). The SDR conversion only set the frames' matrix (from scale=out_color_matrix=bt709), and the HDR paths set nothing on the frames. VideoToolbox ignores the output options and writes only what the frames carry. With FFmpeg 8.1.1 on macOS:

• h264_videotoolbox given all four -color_* options writes bt709,unknown,unknown;
• hevc_videotoolbox with bt2020/PQ options writes bt2020nc,unknown,unknown.

The fix tags the frames on every path, streamed and disk (so HLS and distributed chunks too):

• SDR: both SDR filters (capture and raw RGB) now end in SDR_RGB_TO_TAGGED_BT709_FILTER, the BT.709 conversion plus setparams tags that ProRes already uses for the same reason.
• HDR: every HDR branch, including the GPU branch of the disk encoder and the raw-HDR stream that had no filter before, now appends hdrFrameTagsFilter(transfer). It's built from getHdrEncoderColorParams, so the frame tags and the x265 params share one source.
• The -color_* options stay; they still set the container tags.

Verification

• 0.8.167 on linux/x64 with libx264: default, one-worker, low-memory, segmented, HLS and HDR-source --sdr renders are all bt709,bt709,bt709, range tv. An HDR render keeps bt2020nc/smpte2084/bt2020. So the report only reproduces with VideoToolbox.
• macOS, FFmpeg 8.1.1, real VideoToolbox through the new filters:
  • h264_videotoolbox: bt709,bt709,bt709 (was bt709,unknown,unknown);
  • hevc_videotoolbox main10: bt2020nc,smpte2084,bt2020 and bt2020nc,arib-std-b67,bt2020 (was bt2020nc,unknown,unknown).
• New tests run real ffmpeg and ffprobe. Each encodes through the -vf the arg builder produces, with a plain libx264 or 10-bit libx265 given no colour options, which like VideoToolbox writes only the frames' colour, then ffprobes the stream.
  • chunkEncoder.test.ts: SDR; HDR PQ and HLG; HDR PQ on the VideoToolbox branch.
  • streamingEncoder.test.ts: SDR captured and raw RGB frames; raw HDR PQ and HLG; raw HDR PQ on VideoToolbox.
  • On main all 9 fail. With the change, chunkEncoder (103) and streamingEncoder (84) pass, 3 runs each.
• One existing expectation updated: the GPU HDR odd-dimension test now expects the HDR tags ahead of the pad.
• tsc --noEmit in packages/engine and oxfmt --check are clean.