[vlc-devel] Another stutter issue

[Juha Jeronen]

Hi,

On 03/05/2011 07:19 PM, Rémi Denis-Courmont wrote:
> Le samedi 5 mars 2011 19:11:59 Juha Jeronen, vous avez écrit :
>> a) Maybe the processing chain is not aligned to vsync? Framerate doubler
>> = 60Hz, LCD display, also 60Hz. There should be exactly one output frame
>> rendered at each vsync, and there is no room for any misses. This may
>> set limits on acceptable times when the decoding of the next frame
>> should begin (so that all output frames can be rendered in time for the
>> next vsync).
> I believe we cannot synchronize with the vertical refresh using plain X11. 
> This issue is quite evident when resizing a video.

Yeah, can't expect too much for video playback from plain X11 ;)

(And generally speaking, a system that doesn't align display updates to
vsync is broken, regardless of what it's used for. I can't think of a
use case where the tearing phenomenon would actually be useful, and I'm
not aware of any display technologies that don't operate on a
regular-interval polling basis. It makes one want to ask, what were the
original designers thinking?)


> With XVideo, the driver will do it automatically... or not. You can check with 
> 'xvinfo' if XV_SYNC_TO_VBLANK is set to 1 (good), 0 (bad) or missing (probably 
> bad).

Thanks for the tip, as always :)

Automatic drivers FTW. Checked - it's 1 as it should. (Indeed, I haven't
seen any tearing artifacts.)


> With OpenGL, I think we have to do it by hand from the video output plugin, 
> and I'm not sure we actually do.

This may be worth checking, but maybe later...

...though on second thought, the OS X version uses OpenGL? Maybe I'll
see if I can figure out anything about it after I'm done with the
deinterlacer :)


For now, thinking this through, this time correctly (bear with me for
the rather elementary stuff - I think more clearly when making
everything explicit :) ):


Legend:

----- ... = time axis
+ = vsync
= = processing
_ = idle
deco = decoder
dint = deinterlacer
blit = renderer


Case 1: peachy, 1x

Displaying frame 1  Displaying frame 2  Displaying frame 3  Dis ...
+------------------ +------------------ +------------------ +-- ...
====== ==== == ____ ====== ==== == ____ ====== ==== == ____ === ...
deco   dint blit    deco   dint blit    deco   dint blit    dec ...
=================== =================== =================== === ...
Processing frame 2  Processing frame 3  Processing frame 4

=> Each output frame arrives to the renderer in time for the next vsync.

In the diagram, it was assumed that decoding starts at the vsync, but
obviously the same argument works for an arbitrary offset.


Case 2: not ok, 1x

Displaying frame 1  Displaying frame 1! Displaying frame 2! Displaying  ...
+------------------ +------------------ +------------------ +---------- ...
====== ============= == ====== ============= == ====== ============= == ...
  deco dint          blit deco dint          blit deco dint          blit .
                     miss
======================= ======================= ======================= ...
   Processing frame 2      Processing frame 3      Processing frame 4   ...

=> The output gets left behind. Duplicate output (and eventual frame
dropping to correct the A/V sync) cause the playback to stutter.


Now, let's replace the 1x deinterlacer with a framerate doubler:

Case 3: peachy, 2x - something like this?

Displaying frame 1b Displaying frame 2a Displaying frame 2b Displaying
frame 3a ...
+------------------ +------------------ +------------------
+------------------ ...
==== ===== ===== == __ == _____________ ==== ===== ===== == __ ==
_____________ ...
deco dint  dint blit  blit              deco dint  dint blit 
blit              ...
  2   2a    2b   2a    2b                  3   3a   3b   3a   
3b               ...
=======================================
======================================= ...
          Processing frame 2                      Processing frame 3

Note that both deinterlaces are done as one block (as per how VLC operates).

Basically, the only difference seems to be that the deinterlacer must
process two output frames, and then the renderer needs to time them
correctly.


So, as long as the complete processing chain is fast enough, the
renderer should take care of not displaying anything too early (by using
the PTSs). If the chain takes longer, then obviously there will be a
problem, and some frames must be dropped.

So this is not a likely cause for the stutter.

To find out whether it's dropping frames, maybe we need to number them
somehow, and then add a debug print into the renderer...

 -J