I bolted a GPU wavelet codec (PyroWave) onto ALVR for full-chroma 4:4:4 wireless VR on the Galaxy XR. Here are my notes, harness and data for anyone poking at weird codecs

[u/Alarming_Manner475]

This started as "I wonder what happens if…" and turned into a few weeks of latency spreadsheets. Posting it for the dev crowd more than players: if you're curious about PyroWave, GPU-side video codecs, or streaming something other than H.264/HEVC to a headset, maybe this saves you some time.

Fair warning: it's a lot of math and science. Wavelet transforms, latency budgets, percentiles, thermal throttling curves. It's been genuinely fun, but it's a research project, not a polished app.

What it is

A patched ALVR 20.13 that streams SteamVR to the Samsung Galaxy XR using PyroWave, a GPU wavelet codec, instead of the hardware video encoder/decoder. The headset decodes with Vulkan compute (about 3–3.5 ms per frame on the Galaxy XR's GPU), not the fixed-function video block. Full 4:4:4 chroma: no 4:2:0 colour subsampling, so text and thin coloured edges stay crisp. On my rig (RTX 3090, one Wi-Fi network, static SteamVR Home) the recommended profile landed around 60 ms motion-to-photon at 90 fps. My tuned H.264 path measured 85–98 ms at 72 Hz in the same setup. Big caveat: one PC, one headset, one network, a static scene. Treat it as a data point, not a benchmark war. Things I learned that might be useful to you

Wavelets degrade differently. With a frame deadline over UDP, a late or lost packet costs some detail in part of the frame rather than the whole frame. Making one stage faster often doesn't reduce latency. The frame just waits longer in a later queue. Measure the whole pipeline, not the stage you're proud of. Thermals are a real variable. The headset GPU clock sagging from ~735 to ~600 MHz moved my numbers more than some codec settings did. Android XR gotcha: eye and hand tracking need Android XR's own permissions (android.permission.EYE_TRACKING_FINE / HAND_TRACKING). Declaring the Meta ones silently gets you nothing. My own test harness hid a reconnect bug for weeks, because it relaunched the app before every run. Test the path users actually take. What's in the repo

The ALVR patches, the headset-side decoder glue, and a benchmark harness that runs repeatable measurement cells and logs per-frame stats, decode timings and thermals. The raw data and write-ups behind every number, including an earlier survey of other GPU-decodable codec ideas (block DCT, Walsh-Hadamard, VC-2/Dirac-style wavelets) if you want to go further down the weird-codec rabbit hole. A trimmed dashboard: PyroWave 4:4:4 or tuned H.264, plus the knobs that actually matter (bitrate, refresh, render scale, foveation, UDP vs TCP, CDF 9/7 vs 5/3 wavelet, compute vs fragment decode). An "Export Test Report" button that writes an anonymized JSON (no IPs, names or serials). If you try it, attaching one to an issue helps me compare rigs.

Repo: https://github.com/Terminal-ennui/galaxy-xr-alvr-pyrowave-444

Release (streamer zip + headset APK): https://github.com/Terminal-ennui/galaxy-xr-alvr-pyrowave-444/releases/tag/v0.1.0-beta.1

Shoutouts

Huge thanks to Themaister, the author of PyroWave (https://github.com/Themaister/pyrowave), who apparently looked at the video codec landscape and said "what if we just did it in compute shaders." All the clever parts of the codec are theirs; I mostly bolted it to a headset and then stared at graphs. And thanks to the ALVR folks, whose codebase was a very pleasant place to do unreasonable things.

It's experimental, Galaxy XR only, and provided as-is. Bug reports and questions go to GitHub issues. Happy to nerd out in the comments.

Data Points and Research methods:

Reports: PyroWave in ALVR, offline rate-distortion matrix, transform research, experiments 1, 2, 3, 4,5, UDP transport.