Zhuowei Zhang on Nostr: Tetsuo Milk npub14ly3s…ja6kq forcing software encoding on the server fixed it ...
Tetsuo Milk (npub1g6x…4rvz) npub14ly3sdvez025eln623a3t35c0tc8vyset9sqg30ed2x6alvyuvvsxja6kq (npub14ly…a6kq)
forcing software encoding on the server fixed it
Probably because my crappy NAL parser is broken: it’s possible to have NALs beginning with either 00 00 00 01 or just 00 00 01. On software encoding, the setup packets always use 00 00 00 01, and the rest always use 00 00 01, so I didn’t bother handling the other cases.
https://github.com/zhuowei/VisionOSALVRClient/blob/34384e1e3d7d644dc473e2cf2a7bb5465c33f794/ALVRClient/ALVRClientApp.swift#L99
Fix is probably simple (check the first 4 bytes to see if they’re 00 00 00 01 or 00 00 01 xx; see NalParsing.cpp in Alvr). Do you happen to have a video capture from Nvenc (Alvr->Debug->Start Recording)?
though it appears to be rendering the same texture for both eyes
ugh, sigh. I’ll take a look. Is it showing the same eye on the video recording as well?
forcing software encoding on the server fixed it
Probably because my crappy NAL parser is broken: it’s possible to have NALs beginning with either 00 00 00 01 or just 00 00 01. On software encoding, the setup packets always use 00 00 00 01, and the rest always use 00 00 01, so I didn’t bother handling the other cases.
https://github.com/zhuowei/VisionOSALVRClient/blob/34384e1e3d7d644dc473e2cf2a7bb5465c33f794/ALVRClient/ALVRClientApp.swift#L99
Fix is probably simple (check the first 4 bytes to see if they’re 00 00 00 01 or 00 00 01 xx; see NalParsing.cpp in Alvr). Do you happen to have a video capture from Nvenc (Alvr->Debug->Start Recording)?
though it appears to be rendering the same texture for both eyes
ugh, sigh. I’ll take a look. Is it showing the same eye on the video recording as well?