[VDPAU] Weave de-interlacing

[Andy Furniss]

Stephen Warren wrote:
> Andy Furniss wrote at Tuesday, April 24, 2012 11:25 AM:
>> Stephen Warren wrote:
>>> Andy Furniss wrote at Monday, April 23, 2012 5:40 PM:
>>>> Looking at the spec on line I see that Weave de-interlacing is the same
>>>> as no de-interlacing, which makes me wonder what the point of it is.
>>>>
>>>> Where there at any time other plans for it?
>>>
>>> No there weren't any other plans; weave de-interlacing is no de-interlacing.
>>
>> Ok.
>>
>>>
>>>> I ask because it seems it could have some use -
>>>>
>>>> If it were allowed to be called at field rate then it would possibly be
>>>> better looking than frame rate weave.
>>>
>>> Weave by definition takes pairs of fields and weaves them into a frame, so
>>> it doesn't make sense to use it at field rate.
>>
>> Yea, OK - I've never seen any different.
>>
>> I don't know what you would call what I describe - the frames would be
>> weaved but only half the lines would be updated at a time, so not
>> loosing as much temporal resolution.
>
> That sounds almost like bob de-interlacing, although the field is stretched
> to form a frame rather than being overlaid on top of the previous content.
>
> I doubt a TV (or any) de-interlacer would do very well if it received a
> progressive image where alternate sets of lines were updated; that's probably
> not something remotely common.

My TV example was in some ways separate from this - but it doesn't 
actually matter because it only de-interlaces when in an interlaced 
mode. So whether it's normal weave or "my weave" will be transparent to 
it as my (AMD) card will just be scanning out every other line of the 
framebuffer anyway.

I can with a convoluted test using -vo gl get yadif=1 quality 
de-interlacing to work now - the only trouble is (ignoring mplayer 
sync/sound/fps=framerate issues) is that it takes human 
intervention/luck to sync with the right field.

If by chance/design weave had been able to be called like bob is - per 
field then the human intervention could (driver permitting) not be 
needed as the caller knows the field order from the codec and the 
hardware could use this info to field sync - but as you say this is not 
the case.