[Nouveau] Syncing to vblank for interlaced video modes

[Alistair Buxton]

On 9 February 2010 18:21, Younes Manton <younes.m at gmail.com> wrote:
> On Tue, Feb 9, 2010 at 12:50 PM, Alistair Buxton <a.j.buxton at gmail.com> wrote:
>> On 15 June 2009 14:14, Jamie Smith <hutts at internode.on.net> wrote:
>>> Hi Again,
>>>
>>> It seems I've triggered off much more discussion than I originally thought I would provoke.  I forgot to actually state what I was proposing to do, but it appears that people have worked it out.
>>>
>>>> >> > 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?
>>>
>>> Yes, this is what I'm proposing.  A server option that modifies the behaviour of the sync code so that if a) the option is set and b) the current video mode is interlaced, then wait until after the second field has been drawn before flipping pages/updating buffers etc.
>>
>> [snip debate about whether this is a good idea]
>>
>> I have been thinking about this problem recently and I have come to
>> the conclusion that it isn't necessary to change the vblank interrupt
>> frequency or add any special hooks to let the player know which field
>> is being shown. No drivers changes should be needed at all. It only
>> requires that players are more smart about how they display interlaced
>> content to the screen.
>>
>> At the moment, every player I know of, when interlacing is disabled,
>> just does simple weaving. This is bad as when you display it on an
>> interlaced screen there is no way to know which field will get
>> displayed first. But there is a better way. If, each time the player
>> receives a vblank interrupt, it draws the next field into the display
>> (ie updating every other line on the framebuffer, and leaving the
>> other lines alone) then each field is in the framebuffer for 1 whole
>> frame, and no matter which framebuffer field is currently shown, the
>> next one will always contain the correct next field.
>>
>> Effectively it is weaving, but instead of weaving each frame's field
>> pair, the frame rate is doubled by weaving every sequential field pair
>> even if they belong to different frames. So, assuming lower-field
>> first, it would produce frames composed like:
>> (1L,nothing),(1L,1U),(2L,1U),(2L,2U),(3L,2U),(3L,3U)...
>>
>> Why it works is kind of hard to explain without a diagram so I have made one:
>>
>> http://al.robotfuzz.com/~al/nouveau/path7109.png
>>
>> Anyway, since no driver changes are needed, this is now offtopic. But
>> does anyone know a player that can do what I am describing? Or maybe
>> this method of playback has a special name I am not aware of?
>
> The problem with that is that the player is typically not copying to
> the actual frame buffer, or even the same buffer that was copied to in
> previous frames. It's copying to some buffer that's not guaranteed to
> contain anything specific, let alone the previously copied content.
>

I was talking about a hypothetical logical framebuffer inside the
player, not the real hardware.

The operation I described is sometimes called "double weave":

http://avisynth.org/mediawiki/DoubleWeave

It is very close to what mplayer's "tfields" filter does in mode 1.
Close enough that I was able to implement it and test it, and the
results are very good. No more juddering / out of order fields and no
deinterlacing artifacts. It was only necessary to duplicate the mode 1
functionality and comment the deint() calls. It should be easy enough
to implement this in any other player.

Here is my patch against the mplayer package from ubuntu:

http://al.robotfuzz.com/~al/nouveau/99-double-weave.patch

It adds a new mode to tfields. Use it like: "mplayer -vf tfields=5 yourfile.mpg"

So, in conclusion, no vblank hacks or other driver changes are needed
to support interlace-on-interlace.

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