[StuartCameronCode]

Adds v210 (uncompressed 10-bit 4:2:2) as an output codec for editing in Premiere and Resolve, requested on the videohelp forum (thread 419911, post #154). While checking interlaced output, I found that every interlaced ProRes or v210 MOV was flagged progressive. That is fixed too.

v210

• VideoCodec::V210 / Dart VideoCodec.v210 (serde "v210"), labelled "Uncompressed 10-bit 4:2:2 (v210)". It has its own Uncompressed family and isUncompressed, kept out of isLossless, and every isLossless call site was checked.
• Containers are MOV (the default), MKV and AVI. MP4 has no tag for v210. It has no quality slider, preset or -crf. The settings note gives the data rate (about 221 Mbit/s at 720x576 25p, 1.1 Gbit/s at 1080p25), worked out for the loaded source when there is one.
• The settings dialog groups it with ProRes under "Editing Intermediates".
• The 4:2:2 10-bit conversion happens in the script, whatever Color Format is selected (effective_chroma_subsampling, Rust and Dart). There zimg respects _FieldBased; ffmpeg's -pix_fmt blends the two fields' chroma on an interlaced 4:2:0 source. forced_pix_fmt still pins yuv422p10le as a guard.
• v210ChromaPinWarning says when the override ignores the user's choice or drops 4:4:4 chroma. It is pinned case for case to the worker's table, v210_stores_422_10_whatever_is_selected.
• There is no +faststart for v210, because it would rewrite a file of about 1 Gbit/s a second time. Restored audio beside v210 is PCM.

Field order (ProRes and v210)

vspipe's Y4M header always says Ip, so ffmpeg never learned that a still-interlaced picture's fields existed, and MOVs got fiel 0x0100 (progressive). -field_order is inert in FFmpeg 9. Now:

• -top 1|0 goes on the pipe input, from ScriptGenerator::output_field_order. That function starts from still_interlaced_tff and drops to progressive after Stabilize pitch, mpeg2stinx or the Frame Rate pass. test_221 fails on any SetFieldBased( in the templates that it doesn't account for.
• ProRes also gets -flags +ildct, so its own frame header is coded as fields.
• Result: fiel 0x0209 (TFF) / 0x020e (BFF) in MOV, and tb/bt in MKV. AVI cannot carry field order.

⚠️ Release note: ProRes from a job left interlaced is now coded and flagged as interlaced instead of progressive.

Also

• ffprobe in FFmpeg 9 prints nb_read_frames twice for a MOV with a timecode track. The worker failed to parse that, so a job without totalFrames encoded one frame. It now takes the first line.
• Docs: README output formats, a new CLAUDE.md section ("Intermediate codecs"), an ENGINEERING_NOTES entry, and a report with its probe script in docs/reports/2026-11-v210-field-order/.

Testing

• cargo test: all pass except test_subtitle_generation_srt_file, which needs a Whisper model that wasn't installed locally. After the review fixes, the library tests (416) and filter_integration_test (213) were run again and passed.
• flutter test --exclude-tags heavy,gpu: 1475 passed, 7 skipped.
• New heavy test integration_v210_output_test.dart, 11/11 passed:
  • a 10-bit 4:2:2 source comes back bit-exact;
  • the fiel bytes are right for v210 and ProRes in MOV, and the field order for v210 in MKV and AVI;
  • per-field chroma survives the 4:2:0 → 4:2:2 conversion;
  • PCM works in MOV;
  • preview = encode.
• Heavy regressions (chroma subsampling, interlacing status, high bit depth, colour-tag pixels): 32 passed.
• Only macOS arm64 was tested; nightly covers the other platforms. No output has been opened in Premiere or Resolve yet.

Follow-ups are tracked separately:

• ProRes from interlaced 4:2:0 still converts in ffmpeg.
• Field-order flags for FFV1/HuffYUV/x264/x265.
• +faststart and PCM for ProRes.

🤖 Generated with Claude Code