mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-11-05 05:37:09 +00:00
James
61880cdc0a
The Docker render path pinned `--platform linux/amd64` for both build and run, which on Apple Silicon / Graviton forced qemu emulation of chrome-headless-shell. The emulated chrome process either SEGV'd or hung on page navigation, producing the failures reported in #1193 / #1194 / #1195. Derive the platform from `process.arch` instead. On arm64 hosts: - The image builds natively (no qemu). - The Dockerfile skips the chrome-headless-shell install because Chrome for Testing only publishes a `linux64` build (verified against the known-good-versions manifest). - The wrapper script leaves `PRODUCER_HEADLESS_SHELL_PATH` unset when no headless-shell binary is present, so the engine falls back to the system chromium that the Dockerfile already installs from apt and points at via `PUPPETEER_EXECUTABLE_PATH`. `TARGETARCH` is forwarded as an explicit `--build-arg` instead of relying on BuildKit's automatic platform args — the legacy builder (and some BuildKit configs, including colima on macOS) leaves it unset, which would silently bypass the arch conditional in the Dockerfile. Image tags are now suffixed with `-arm64` on arm64 hosts so amd64 and arm64 images of the same hyperframes version can coexist in the local cache. The arm64 path renders correctly but loses byte-for-byte parity with amd64 (system chromium uses screenshot capture, not HeadlessExperimental.beginFrame). The CLI prints a one-line warning so users comparing against amd64 baselines know. Verified on macOS 26.5 / M4 Max: - Before: `qemu: unknown option 'type=gpu-process'` followed by a chrome-headless-shell SIGSEGV after ~4 minutes. - After: 300/300 frames captured in ~18s of render time (1m18s wallclock including a one-time image build), MP4 produced. Closes #1193 Closes #1194 Closes #1195