[RFC] wl_surface video protocol extension

[James Courtier-Dutton]

The key point I was trying to make is that the media player needs to be
able to predict when frames will be displayed.

All its prediction calculations will be based on a fixed scanout rate.
If the scanout rate changes, all bets are off, and we have to start again
from scratch trying to predict the scanouts again.
So, with regards to the scanout rate changing, we will need an event to
tell us that so we can redo the prediction calculations.

So, if the scanouts are T=100 and then T=200, we would have to have somehow
predicted that, and as a result set the
buffer1, T=100
buffer2, T=200
or in actual fact, to allow for inaccuracy the media player would set:
buffer1, T = 80
buffer2, T = 180
This will then ensure that buffer1 would be displayed at T=100, and buffer2
would be displayed at T=200.

But we would only know to set T=80 for buffer1 if we had been able to
predict when the actual frame will be.
So, I guess I am still asking for an API that would return these predicted
values from the graphics driver.

Also, If buffer2 has T=200. What is the 200 being compared to in order to
decide to display the buffer or not?
This will not be the timestamp on the presentation callback will it?

There is also the matter of clock sync. Is T=100 referenced to the system
monotonic clock or some other clock.
Video and Audio sync is not achieved by comparing Video and Audio time
stamps.
You have a global system monotonic clock, and sync Video to the system
clock, and sync Audio to the system clock.
A good side effect of this is that Audio and Video are then in sync.
The advantage of this syncing to the system monotonic clock is that you can
then run Video and Audio in separate thread, different CPUs, whenever, but
they will always be in sync.

Kind Regards

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131017/a82b551d/attachment.html>