How Fulldive VR Plays 360 and 3D Video on Android

Written by the Fulldive product engineering team, based on direct inspection of the repositories listed below.

A 360 video player on Android and a 3D VR video app do more than drop a video texture onto a sphere. They have to fetch sources that were built for desktop clients, keep the in-app browser and the video player in sync, handle brightness in a shader because the user is inside the render, and present Cinerama-style flat content when the source is not immersive. This post walks through how Fulldive VR approaches 360 and 3D video playback on Android, using commits from the fulldiveVR/fulldive-unity repository as evidence.

Fulldive VR (package in.fulldive.shell) is built in Unity. The repository history runs from April 2017 through late 2024 across roughly 2,220 commits, which is enough to see how the playback pipeline grew.

Fetching video that was never meant for a phone

A large share of 360 and stereoscopic 3D video on the open web is served by platforms that branch on user agent. If a mobile VR app identifies itself as Android, it often gets the small mobile stream, a paywall, or an HTML fallback that is useless inside a VR headset shell.

Fulldive VR handled this by requesting video URLs with a desktop user agent (commit 3a208241). The same pattern shows up in the player wiring for YouTube-style links, which were routed to open inside the in-app video player rather than bouncing to the system browser (commit 62c1fd92).

Framed historically: the codebase has carried YouTube-style link handling and desktop-UA fetching logic. We are not claiming any current provider is supported. Video source availability on the open web changes frequently, and the fulldive-unity history shows repeated repairs in response to exactly that kind of change.

Cinerama mode: giving flat video a place in VR

Not every video worth watching in a headset is 360 or stereoscopic. Trailers, tutorials, and most long-form catalog content are ordinary 2D video. A mobile VR app still has to display those, because asking a user to exit VR every time they want to watch something is a terrible experience.

Fulldive VR’s answer is Cinerama mode (commit 7a7f56f9), which renders flat video onto a large curved virtual screen inside the VR scene. The concept maps directly to the Google VR “video360” sample language around flat, mono, and stereo formats: 360 sphere for immersive video, flat screen for traditional 2D, and separate left/right eye projection for stereoscopic 3D. Google documents these formats in its VR Video360 sample, which remains a useful reference for how mobile VR renderers think about video meshes.

The in-app browser is part of the video pipeline

A mobile VR app often discovers video before it plays it. That means the VR browser and the VR player are one product, not two. In fulldive-unity, playback controls for video inside the browser surface are their own engineering line (commit f04087ba), and the browser gets a dedicated brightness shader (commit 92e73443) so pages and embedded media can be dimmed or warmed without touching the phone’s backlight.

The shader detail is easy to miss but important: the user is inside the rendered scene. A flat-screen brightness slider does not help. The renderer has to adjust the emitted value per fragment, and that only lives in a shader.

3D VR video versus 360 video

For a new reader, the difference is worth stating plainly. 360 video is monoscopic or stereoscopic footage that surrounds the viewer; they can look in any direction. 3D VR video is stereoscopic footage with separate left- and right-eye images, which can be framed as a flat 3D screen, a 180 dome, or a full 360 stereo sphere.

A mobile VR app has to pick the correct projection per source, or the viewer gets a warped scene and eye strain. The Google VR Video360 sample documents the mono/stereo formats Android players typically handle. In practice, a 3D VR video app for Android has to look at the source metadata or a user-chosen mode and configure the mesh and eye textures accordingly.

What this does not do

Several things are worth being explicit about. The Fulldive VR repository history shows YouTube-style link handling, desktop user-agent fetching, and in-app browser playback, but we are not claiming current support for any specific third-party video provider. Availability depends on what is reachable from the device, the store version installed, and what each provider chooses to serve. Similarly, the Fulldive VR app does not bundle a content catalog; it is a player and browser shell, not a streaming service. Headset behavior depends on the device sensors, the headset type, and the Android build — which is the subject of a separate post on headset-specific work.

What a mobile VR app can and cannot do in 2026 walks through the honest state of Android VR today.
Rebuilding Fulldive VR: Unity migration and legacy repairs covers the build and engine-side history behind the player.
VR media discovery: reactions, comments, and bookmarks explains how the player fits into a social media layer.
The Fulldive company story traces how the VR app became a family of Android apps.
The Fulldive apps page lists every current app.

Sources

Repository evidence: fulldiveVR/fulldive-unity, commits 3a208241, 62c1fd92, 7a7f56f9, f04087ba, 92e73443; history inspected 2026-04-13.
External reference: Google VR Video360 Android sample for 360/3D video format concepts.
External reference: Unity XR documentation for the Unity-side rendering model.

Last updated: 2026-04-16. Commit hashes and version numbers are drawn from Fulldive repositories inspected on 2026-04-13.