New Video Decode and Presentation API

[Torgeir Veimo]

On 20 Nov 2008, at 09:31, Andy Ritger wrote:

> On Tue, 18 Nov 2008, Torgeir Veimo wrote:
>
>> Is field parity observed when outputting interlaced material? I  
>> think it's equally important to have good support for baseline  
>> mpeg2 in addition to other codecs, and this would imply that  
>> interlaced, field parity correct mpeg2 output on standard s-video /  
>> rgb should be fully working.
>
> If the application takes advantage of VDPAU's de-interlacing (the  
> current
> mplayer patches to use VDPAU do _not_ yet enable VDPAU's  
> deinterlacing), then the end result of VDPAU's presentation queue is  
> a progressive frame.
>
> If the application doesn't enable de-interlacing, NVIDIA's VDPAU
> implementation will currently copy the weaved frame to the  
> "progressive"
> surface, and whether it will come out correctly will depend whether  
> the
> window's offset from the start of the screen is odd or even.


Consider the following scenario; the screen is set to the dimensions  
of a PAL picture, 720x576, and the source material is interlaced, but  
with a different native pixel size than the screen, eg 540x480.

Are the even and odd frames scaled individually before applied to the  
resulting surface, or are they applied to the screen, then scaled?

If the latter is the case, I cannot see how this setup will be able to  
provide proper interlaced output without doing any intermedia  
deinterlace. Even frames will "bleed" into odd frames due to the  
scaling, causing a double (or ghost) picture effect. This seems  
consistent with what I'm experimenting trying out a vdpau setting with  
interlaced mpeg2 TV material.

-- 
Torgeir Veimo
torgeir at pobox.com