[miguel-heygen]

What

A video stored on a non-square pixel grid (for example a phone HEVC clip stored 2160x2160 with sample aspect ratio 9:16) now renders at the shape it displays, so object-fit: contain letterboxes it as a 9:16 picture instead of a full square.

Why

The probe never read sample_aspect_ratio and the frame extraction never applied it. FFmpeg writes the frames on the stored grid, so a 2160x2160 clip with SAR 9:16 came out as 2160x2160 pixels and filled a square composition, while Chrome plays the same file as 9:16. Extraction now scales by the sample aspect ratio and sets it to square (scale=trunc(iw*sar/2)*2:ih,setsar=1 using the filter's own sar, which stays correct after ffmpeg's autorotate), after the frame-rate sampling so only kept frames are scaled. Streams with square pixels, "0:1" or "N/A" are untouched.

Testing

fails without the fix: a clip stored on a non-square pixel grid extracts frames at the shape Chrome displays, not the stored grid gives expected '64,64' to be '32,64' with the extractor change reverted.
A second test, keeps the display shape of a rotated clip, whose autorotate swaps the pixel aspect, fails (expected '32,64' to be '128,64') when the stored-grid ratio is used. With the fix videoFrameExtractor.test.ts and ffprobe.test.ts pass 342 of 342, three runs in a row; tsc --noEmit in packages/engine clean.

What I measured

• Published 0.8.217 on a Linux devbox: a 2160x2160 HEVC clip with SAR 9:16 in a 1080x1080 object-fit: contain composition renders non-black across all 1080 columns in both render and snapshot (expected about 607).

What I did NOT execute

• A before/after render with the branch's built CLI (the unit test covers the extraction; the render check above is on the release). Windows and macOS lanes.

[heygengenesis]

Verdict: REQUEST CHANGES · 1 blocker · 0 important · 1 nit

A rotated phone clip with a non-square sample aspect ratio still comes out the wrong shape (inline). The fix is one line.

Scope

Read the ffprobe.ts and videoFrameExtractor.ts changes. This filter chain is the only frame-extraction -vf site in the engine. Confirmed the red-first claim: with the extractor hunk reverted, the named test fails with '64,64' vs '32,64'. CI was still running when this was posted.

[heygengenesis]

Verdict: REQUEST CHANGES · 1 blocker · 0 important · 0 nits — 2 resolved, 0 open, 1 new · bda534a → c0807e2

The new tests fail the required Producer: unit tests job through ffprobeArgvContract.test.ts (inline).

[github-actions]

Edit accuracy: accurate 271 (base branch 271), smooth 129 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (0)

[heygengenesis]

Verdict: APPROVE · 0 blocker · 0 important · 0 nits — 1 resolved, 0 open, 0 new · c0807e2 → e471ce5

Both ffprobe calls now pass "--" before the frame path. All CI is green on this head, including Producer: unit tests.