Michel Dänzer <mic...@daenzer.net> writes: > I assume 2. refers to the case of a single late frame, where the next > frame hitting the original absolute target would result in a second > visible stutter. While writing > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/22#note_548234 > , it occurred to me that although a relative target time may avoid > that second stutter, the audio stream needs to adapt to the visual > delay, likely producing audible artifacts instead? It's not obvious to > me that would be an overall win. (The only other way I can think of is > to re-synchronize later frames to the audio stream, but it's not clear > that this is possible without either producing visible stutter again, > or de-synced audio/video for a noticeable period of time)
I think the idea is that the application would interpolate time values in the video stream to bring it back in sync with the expected time over a couple of frames. I think we could easily construct a demo which shows the difference and see what we think. I think we could ignore the audio stream as a 16ms lag between audio and video shouldn't be a big deal; we handle that in real life quite easily as that's the lag you get at a distance of about 5m. > P.S. Have you more formally proposed a Vulkan extension in the > meantime? If so, could you provide a reference to that here? No. If I had, the IP restrictions with Khronos would prevent me from discussing it here in any technical detail. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
