A side-by-side video already contains two views. An ordinary web player simply shows both of them in one rectangle. I wanted a way to keep using the page's existing video and present each half to the corresponding eye on Apple Vision Pro.
The resulting prototype is a Safari extension that starts an immersive WebXR player from a page with a usable video element. It reuses the playing video as a texture instead of downloading or re-encoding the file. Side-by-side and over-under packing become two ways to select the appropriate region for each eye.
The basic idea is small enough to explain with texture coordinates. For side-by-side material, the left eye samples one horizontal half and the right eye samples the other. For over-under material, the division is vertical. The WebXR view model provides the per-eye views in which the virtual screen is rendered.
The crop alone is not a complete player.
The rectangle has several meanings
A packed video has a stored frame aspect ratio and a different intended aspect ratio for each eye. A half-width or half-height encoding may need to be displayed with a corrected shape. Letterbox bars and a black gap between the views introduce more boundaries. Selecting exactly half of the stored pixels can therefore be a reasonable first guess and still produce a stretched or incorrectly cropped image.
The prototype includes format and eye-swap controls, along with boundary adjustments. Those controls are useful because a video title or visual heuristic cannot identify every encode perfectly. When depth looks inverted, a clear eye-swap option is more helpful than a hidden assumption.
Orientation turned out to be another practical part of the work. The June changes dealt with mirrored images, mirrored button clicks and an upside-down image on a curved screen. Those are related coordinate problems, but fixing one does not automatically fix the others.
A control panel can look correct while its hit targets remain reversed. A texture can be flipped to fix the picture while making interaction harder to reason about. The cleaner solution is to keep the screen, its orientation and its input coordinates consistent, rather than accumulate compensating flips.
The player also changed from continuously facing the viewer to keeping its orientation after it had been aimed. That distinction affects the experience immediately. A screen that follows every head movement feels attached to the viewer. A screen that stays placed feels like an object in the room. Recenter and drag actions provide deliberate ways to change that placement.
The browser still owns playback
Reusing a video element preserves useful parts of the page's existing playback path. It also means the extension inherits browser constraints. In this prototype's visionOS Safari path, native HLS playback keeps the video texture updating in immersive mode; other source paths can freeze.
That limitation matters more than an attractive screenshot of the virtual screen. A player needs a continuously changing texture, not just the first decoded frame. It also needs pause, seek and exit behavior that remains understandable when the page and immersive session are both involved.
The prototype does not bypass access controls or transform protected content into an unrestricted source. It works with a video element the page and browser already make available. That keeps the integration focused on presentation rather than trying to replace the site's entire media stack.
I like this approach because the stereo information is often already there. The missing piece is a viewing context that knows how to interpret it. A small extension can supply that context, but it has to respect geometry, input and playback state at the same time.
The satisfying part is turning a flat packed frame into a screen with depth using the material already playing on the page. The less visible work is making the screen stay where it belongs and making its controls behave the way they look.