Diagnosing Frame Sync Issues?

[Edward Hervey]

Hi,

On Tue, 2013-05-14 at 09:35 +0100, Ian Davidson wrote:
> On 14/05/2013 08:37, Edward Hervey wrote:
> > The current synchronization model in video sinks (and all other sink 
> > element that use the standard GstBaseSink synchronization model) is 
> > "wait-then-render". When a buffer comes in, GstBaseSink will figure 
> > out a target clock running time, wait for that moment and then call 
> > your sink's "render" method (which does the actual 
> > display/output/...). And this is where it gets tricky.
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> Just a thought.  Does the time taken to render depend on what is being 
> rendered?  For example, if one 'nth' of the total picture happened to be 
> 'clear blue sky', it would (possibly) be quicker to render than another 
> 'nth' which contained lots of detail.  Since both pieces start to be 
> rendered at about the same time (remembering that the computer only has 
> so many CPUs actually available), that could allow the 'easy' pieces to 
> be displayed before the 'complicated' bits - and sometimes that might be 
> noticeable.

  When I talk about render, I only mean the display side of things, not
the decoding part.

  The fact that some frames might be faster than others to decode
(before display) is smoothed out by having a small queue between decoder
and sink. So as long as you can decode (on average) N frames over N/fps
duration, that will be handled by the queues. And each decoder works in
separate threads, so the kernel scheduler should also take care of
load-balancing the work being done by multiple decoders.

> 
> I could be totally wrong.