mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-14 18:01:20 +08:00
James
bbd8996728
Two related fixes pulled out of CI failures on the Chrome pin run: 1. **regression-harness PSNR-parse crash on many-cuts.** Container duration includes audio padding past the last video frame (many-cuts: 5.654s container, 5.6s of video at 30fps = 168 frames). At i=99 the raw container duration mapped to time 5.59746s → frame index 168 (round(5.59746 * 30)), which is one past the last frame the stream contains. ffmpeg's `psnr` filter emits no `average:` line for a non-existent frame, so the harness crashed with `Unable to parse PSNR output at 5.59746s`. The fix subtracts one frame interval from the sampling duration so the last checkpoint always lands on a frame the video stream actually contains. PR #918 admin-merged through this same failure on shard-2 (so main is currently red on many-cuts), and Miguel's regen via `--update` didn't catch it because `--update` only writes the snapshot — it doesn't validate. 2. **style-1-prod baseline regen.** Same pattern as style-12-prod: PR #918's regen was done before / between the `refactor: extract shared inlineSubCompositions from bundler and producer` (581e7a7e) and the linkedom-fragment fix (754b0edc), so the committed baseline doesn't match what the compiler now emits. Reproduced locally: frames 14.62s onward fail at PSNR ~10-16 because the graphics sub-composition layer (`#a-roll-frame` overlay) now correctly renders through host duration but was absent in the committed baseline. Regenerated under the Chrome 148.0.7778.167 pin from this PR — now passes at PSNR 53-62 dB across all checkpoints.