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 torg...@pobox.com _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
