Diagnosing Frame Sync Issues?

[Stirling Westrup]

On Tue, May 14, 2013 at 4:35 AM, Ian Davidson
<id012c3076 at blueyonder.co.uk>wrote:

> 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.
>
> Alas, this *is* a possible scenario. I know that the X drivers for the
zero clients use a lossy video encoding to compress output frames for
transmission over the wire and the target devices need to decode that and
then display the results. Obviously a simple blue sky is likely to be
easier and faster to encode/decode that a complex scene, but I don't see
what I could do about this that wouldn't be prohibitively expensive.

That said, evidence so far is that this is NOT the ultimate cause of our
issue as we often see the frame sync issue between two scenes of
approximately the same complexity. Then again, that might just be because
one frame of blue sky looks pretty much like another, so one wouldn't be as
likely to notice frame jitter there.


-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130514/3cbfeac1/attachment.html>