mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-01 19:42:03 +00:00
Vance IngallsandClaude Opus 5
9e275423e2
Three issues in runFfprobe's process and stream handling. A filePath of exactly "-" hung for 30 seconds. `--` stops option parsing, so "-intro.mp4" is safe, but ffprobe rewrites "-" to `fd:` AFTER option parsing and reads stdin — and stdin was an inherited pipe the parent never writes to and never ends. The probe ran to the deadline and failed with an empty diagnostic, because ffprobe never errored so stderr was blank: 30010 ms and no message, against 28 ms for a normal missing-file error. Rejected up front, and the child now gets stdio ["ignore", ...] so no future invocation can block on stdin either. stdout was decoded per chunk. `stdout += data.toString()` decodes each 64 KiB pipe chunk independently, so a multi-byte character straddling a boundary became U+FFFD on both sides — verified: 200 KB of 3-byte characters produced 15 replacements and a string 9 characters longer than the source. -show_format output above ~64 KiB with non-ASCII tag text returns silently mangled values, since JSON.parse still succeeds. Now accumulated through StringDecoder. Note on testing that one: U+FFFD is valid JSON string content, and nothing on extractMediaMetadata's public surface exposes a tag value, so there is no assertion that fails against the old implementation. Rather than add a test that cannot fail, it is stated here and the bound below is what the new test covers. stdout was unbounded. stderr is capped by ManagedChildProcess but stdout was not, and analyzeKeyframeIntervals emits one line per frame — an all-intra ProRes proxy can produce an arbitrarily large string. Capped at 8M characters, which real -show_streams JSON is nowhere near. Tests: "-" rejected without spawning, the stdio shape, and the size bound. Reverting the stdin guards fails 1. The first draft of the bound checked before appending, so a single oversized chunk passed — the test caught it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>