mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-01 19:42:03 +00:00
Three defects in the PNG metadata fallback, all introduced when the cICP early return became an accumulator. Corrupt trailing chunk nulls a good result. cICP must precede IDAT, so continuing past it only visits chunks this parser ignores — while making whole-file integrity a precondition for returning anything. A truncated or bad-CRC chunk after cICP in an otherwise-good HDR PNG returned null, and extractMediaMetadata then re-throws the ffprobe error it had swallowed instead of using the fallback it just computed: the render dies on a host without FFmpeg, or grades SDR on a build that does not decode cICP. Now stops once dimensions and colour are known. A second IHDR overwrote the dimensions. PNG permits exactly one, first, but nothing enforced that here — a trailing [IHDR 1x1] replaced a real 3840x2160 and the producer laid out a one-pixel image. Anchored to the first. The length guard was also `>= 8` against a spec length of 13, which accepted a truncated header and read height out of the CRC bytes. crc32 was hand-rolled bit-at-a-time and fed a Buffer.concat per chunk. Since the walk no longer stops early it CRC'd whole files: 210 ms on a 12 MiB PNG, 647 ms on a 35 MiB 4K one, synchronously on the event loop, plus ~11 MB of garbage per parse from concatenating a 4-byte type tag onto every chunk. node:zlib's crc32 is native and takes a running seed, so type and data hash in sequence with no copy. 210.28 ms -> 1.291 ms. Tests: 5 regressions — corrupt-after-cICP, truncation after cICP, second IHDR, short IHDR, and that a corrupt IHDR/cICP still rejects. Reverting the break or the anchor fails 3. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>