Repository navigation
refactor(engine): one builder for the video frame filter chain - #6908
Conversation
Edit accuracy: accurate 271 (base branch 271), smooth 105 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (2)
|
There was a problem hiding this comment.
Requesting changes at 25ee0f12. The refactor itself is correct, but it turns CI red.
Blocker: the CI Fallow audit job fails, and this PR causes it. The report finds 2 new dead-code issues:
fallow/unused-type:VideoFilterChainInput(videoFrameExtractor.ts:1125)fallow/unused-export:videoFilterChain(videoFrameExtractor.ts:1139)
Both are exported, but nothing outside this module imports them until the #6881 follow-up lands. Either fix is enough:
- Drop
exportfrom both for now. The follow-up can add it back when it imports them. - Or mark them the way the repo already does:
// fallow-ignore-next-line unused-export(used 9 times inpackages/) andunused-typefor the interface.
Fallow is not a required check, so the merge loop would merge with it red. That is why I'm asking for the fix here rather than letting it land.
The refactor is equivalent (checked):
- Order. Before:
[nv12?] + sampling(seek) + [SAR, sdr→hdr, tone-map, sdr canvas (+ halve-to-cover, bt601) for jpg], with sampling spliced in atsamplingAt(0 or 1). After:head+sampling(seek)+tail, which gives the same filters in the same order. - Tone map.
toneMapFrom !== undefinedmatches the caller'stoneMappedToSdrexactly.readFirstFrameColour→parseFirstFrameColouralways returns an object (at worst{}) and neverundefined. It is still read only when tone-mapping, at the same point as before. - Tests. The 9
videoFrameExtractor*test files give 289 passed and 1 skipped, which matches the PR body.tsc --noEmiton the engine package is clean.
Nit, not blocking: the shortened sdrToHdrTransfer comment drops the reason it is safe today ("the remap only applies to SDR sources, nv12 only to HDR sources, so the flags are mutually exclusive"). That line is worth keeping.
There was a problem hiding this comment.
Approving at b45a5812. My blocker from 25ee0f12 is resolved.
- What changed since
25ee0f12. The only edits are droppingexportfromvideoFilterChainandVideoFilterChainInput, plus the comment. The PR diff is still the single filevideoFrameExtractor.ts. No filter logic changed, so the equivalence I checked last round still holds. - Fallow is green on this head, and so is Lint.
- The comment nit is addressed. The
sdrToHdrTransfernote again says the remap never meets nv12, because nv12 is HDR-only. - Local checks are unchanged. The 9
videoFrameExtractor*test files give 289 passed and 1 skipped, andtsc --noEmiton the engine package is clean.
What
Moves the ffmpeg filter chain that decides which source frame a video slot shows and how its colour is converted (frame sampling, tick-rounding fix, aspect ratio, HDR/SDR conversion) out of the extraction function into one exported builder,
videoFilterChain. Extraction calls it and produces the same filters in the same order as before.Why
A follow-up (refs #6881) lets ffmpeg composite the source video itself instead of round-tripping every frame through JPEG and the page. That path has to pick the same frames and colours as extraction, so both must call one builder rather than keep two copies that drift.
Tests
No behaviour change: the 9 existing videoFrameExtractor test files pass (289 passed, 1 skipped), typecheck and format clean.
Size
About 70 changed lines, one file.