fix: main video invisible in editor (CORS) + webcam recording truncated (encoder contention) - #20
Merged
Alfredoalv13 merged 1 commit intoJul 25, 2026
Conversation
…ated (encoder contention) Two independent, previously-undiagnosed bugs found by instrumenting the actual recording/playback lifecycle end-to-end: 1. The main screen recording never appeared in the editor preview (only the background layer showed, with none of the zoom/pan effects) - not because it failed to load, but because feeding it to Pixi as a WebGL texture threw `SecurityError: Failed to execute 'texImage2D'... cross- origin data`. mediaServer.ts and rendererServer.ts each listen on a separate random localhost port, so the video is cross-origin from the page's perspective. The media server already sends Access-Control-Allow-Origin, but a <video> element only makes the CORS-mode request that permission depends on if crossOrigin is set on the element itself - without it, the video plays back fine directly but still taints any canvas/WebGL texture created from it. The webcam preview was unaffected because it's rendered as a plain <video> tag, never uploaded to a WebGL texture. 2. The recorded webcam file was always truncated to a fraction of a second regardless of actual recording length. Traced via direct instrumentation of the MediaRecorder lifecycle: with MP4/H.264 selected (first in the webcam preference list), ondataavailable never fired during recording at all - only once, at stop(), with a couple of small chunks. Switching preference to VP9/VP8 (software-encoded, WebM) fixed it immediately: ondataavailable now fires every ~267ms for the entire recording as expected. The likely cause is macOS's VideoToolbox supporting only a small number of concurrent hardware H.264 encode sessions - the screen recording's native ScreenCaptureKit helper already holds one, and the webcam's MP4 MediaRecorder was competing for hardware encoder time it couldn't get. Verified directly: 786 -> 819 passing tests (one test updated for the new mime type preference, split into two cases), tsc clean, and a real end-to-end recording (screen + webcam + audio, ~31s) played back correctly in the editor afterward with zoom effects intact.
Alfredoalv13
deleted the
fix/main-video-cors-and-webcam-encoder-contention
branch
July 25, 2026 01:52
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two independent, core-functionality bugs, both root-caused by directly instrumenting the actual recording/playback lifecycle rather than guessing:
Main screen recording never appeared in the editor preview. Loaded fine (correct dimensions/duration, no decode error) but throwing
SecurityErrorontexImage2Dwhen Pixi tried to use it as a WebGL texture, becausemediaServer.tsandrendererServer.tseach listen on separate random localhost ports, making the video cross-origin from the page. The server already sendsAccess-Control-Allow-Origin, but the<video>element needscrossOriginset to actually make the CORS-mode request that permission depends on. Fix: addcrossOrigin="anonymous"to the main video element.Webcam recording always truncated to a fraction of a second. Traced via direct MediaRecorder instrumentation: with MP4/H.264 preferred,
ondataavailablenever fired during recording - only once, atstop(). Likely cause: macOS VideoToolbox only supports a small number of concurrent hardware H.264 encode sessions, and the screen recording's native ScreenCaptureKit helper already holds one. Reordering the webcam MIME type preference to try VP9/VP8 (software-encoded) first fixed it immediately - verifiedondataavailablefiring every ~267ms for a full 31s recording afterward.Test plan
tsc --noEmitcleannpm test- 94/94 files, 819/819 tests passing (one test updated for the new MIME preference order, split into two cases)