[Mesa-dev] Playing with display timing -- VK_MESA_present_period

[Keith Packard]

Michel Dänzer <michel at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20200624/d10e81ad/attachment.sig>