[Bug 703348] Add support for synchronizing the video sink to VSYNC

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=703348
  GStreamer | gst-plugins-gl | git

Edward Hervey <bilboed> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bilboed at gmail.com

--- Comment #1 from Edward Hervey <bilboed at gmail.com> 2013-07-01 05:30:13 UTC ---
Might be good mentioning the existing/future elements that could benefit from
that. The ones that come to mind are all the gl-based ones and wayland. Maybe
some fb based ones also ? Any other ones come to mind ? Specific hardware sinks
? v4l2 ?

Also note that for this to work efficiently you need some kind of time
reference. "on each VSync" is very vague. Is it before ? Just in time ? When it
happens (so what you return will be on the next vsync) ? etc...

The bare minimum would be to have feedback from the system on when a certain
frame was actually displayed (Frame F1 that was given at time T1 was displayed
at time P1, F2 from T2 at P2, ...). Based on that you can calculate an average
latency between T:time_when_callback_asks_for_frame and
P:time_when_frame_is_actually_presented. This is vaguely similar to the
audiosink segment latency.

If you do not have the above ... the presentation will always be off by a
certain unknown/variable latency (and therefore doesn't bring any advantage
against the current "push-based" video sink systems).

Bonus points on the underlying system giving you the *actual* rate at which
frames will be presented (from the hardware). This allows you to fine-tune what
frame you will be presenting at a given time (and also adjust the
afore-mentionned latency more consistently). Note that you could estimate this
from the rate at which your "vsync" callback happens, but it's not as accurate
(can block/delay?) as getting the actual rate.
Would be awesome to finally display 24000/1001 progressive (film) on a 60/1
display "spot on" :)

Other notes:
* it would be great to have a generic clock extrapolated from all those info
(just like the audiosink clocks), that can be slaved or can be master. 
* Make sure the "prepare" vmethod still gets called before a buffer enters the
queue, and drop ones you know will be not rendered (because they arrive too
late). For this new audio-like system to work, the action called in that
separate thread needs to be almost-instantaneous.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.