[Nouveau] Syncing to vblank for interlaced video modes

[Alistair Buxton]

2009/6/15 Dirk Thierbach <dthierbach at gmx.de>:
> On Mon, Jun 15, 2009 at 08:44:26AM +0100, Alistair Buxton wrote:
>> 2009/6/15 Dirk Thierbach <dthierbach at gmx.de>:
>> > On Sun, Jun 14, 2009 at 11:56:45PM +0100, Alistair Buxton wrote:
>> >> Stupid question: Given the presence of a register which indicates the
>> >> current field, why can't NVWaitVSync simply wait until the end of the
>> >> second field, by doing whatever it does twice iff it is called during
>> >> the first field?
>> >
>> > Because then you'd effectively halve the frame rate in interlaced
>> > modes, unless you somehow queue all the information for the second
>> > half-frame.
>
>> That isn't a problem, because you show both fields at the same time,
>> and let the video card cut them up. You still get 50 fields per
>> second, same as source.
>
> Ok, I think I understand now what you mean.
>
> But that will only work in the very particular case that you're
> displaying a video full-screen, with the *intention* to let the
> hardware do the interlacing. Which doesn't match the usual usage
> of Xv, for example. So you're introducing a special case without
> marking it as a special case explicitely. That's a bad idea in
> my book. KISS.

Yes, that is exactly the intention, for eg a mythtv STB which only
ever plays interlaced video which is the same size as the screen.

>> mplayer and vlc both do it.
>
> But only when displaying video full-screen and they know the card
> is in interlaced mode, I assume? Otherwise, that would be plain stupid,
> because it will generate artifacts for every other use. Like displaying
> the movie in a window.

No, they do it in window mode too, and regardless of display mode.
Unless you specifically specify that you want deinterlacing, they keep
both fields as a single frame. mplayer detects the framerate of an
interlaced mpeg2 as 25 fps. When the vsync is at 50hz (per field)
mplayer is ignoring every other vsync anyway. The problem then is that
it has a 50% chance of ignoring the wrong vsync.

>> They can also split the fields and scale vertically as you describe
>> (vlc calls it bob deinterlacing) but at extra CPU cost.
>
> Not if Xv does the scaling via hardware.
>> > If you just combine two adjacent half-frames, you get the typical
>> > comb-style ragged edges on fast moving objects.
>>
>> That's what happens on a none-interlaced display. On an interlaced
>> display it will look fine of course. So I can't see any problems with
>> this method.
>
> See above. It's a very special case, it behaves different in that special
> case, it will break if the client doesn't know it behaves different and
> wants to use it for other purpose (say, displaying a non-interlaced
> source on an interlaced display).

Good point.

> Why not use a method that works in all cases? Which is to give the
> client explicit knowledge about which half-field is displayed
> currently. Then the client can decide what to do.

I mainly don't like the idea of having to patch all players ever made,
plus the driver side is also more complex. But it does seem the more
flexible solution.

At the moment I can't even get interlaced mode to work because I have
a NV18 card, but I'm working on it.

-- 
Alistair Buxton
a.j.buxton at gmail.com