mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-11-14 13:27:13 +00:00
Vance IngallsandClaude Opus 5
17542513ae
The whole track crossed in one `page.evaluate` pair — ~184 MB of base64 for a 3-minute stereo 48 kHz clip, in a single WebSocket frame each way. puppeteer-core caps its frames at 256 MB (NodeWebSocketTransport, verified in the installed copy) and the browser pool does not pass `pipe: true`, so stereo 48 kHz past ~8.7 minutes raised AudioFxRenderError and failed the render. V8's max string length is a second wall not much beyond it. Both were fatal: an FX failure takes the whole mix down rather than dropping one track. Input and output now move 8 MiB at a time, staying separate byte arrays page-side rather than being concatenated into one string, so neither the frame cap nor the string limit ever sees the whole track. That also bounds the peak Node-side allocation: `processCompositionAudio` renders tracks through an unbounded `Promise.all`, so every track's payload used to be live at once. The page drops the input chunks before the render allocates its buffers, so it no longer holds two copies of the track. Also drops the `Array.from(u8.subarray(...))` in the encoder, which boxed every byte of each 32 KiB window into a JS array for nothing — `apply` takes array-likes. The 8.7-minute ceiling itself has no test: reproducing it needs a 256 MB payload. What is tested is the assembly, which is where chunking actually goes wrong — a 45 s stereo ramp spanning two chunks per plane, checked for length, for values at the seam, and for monotonicity across all 2.16 M frames. Falsified against three mutations: chunks reassembled in reverse (1.75 off at the seam), the trailing partial chunk dropped (short by 125,696 frames), and an unbounded input subarray (long by 125,696). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>