[Mesa-dev] reworking pipe_video_decoder / pipe_video_buffer

[Christian König]

On 26.11.2011 22:23, Maarten Lankhorst wrote:
> Hey Andy,
>
> On 11/26/2011 01:44 PM, Andy Furniss wrote:
>> Maarten Lankhorst wrote:
>>
>>>>>>> Testing interlaced  videos that decode correctly with nvidia vdpau would help
>>>>>>> a lot to figure out what the proper way to handle interlacing would be, so if
>>>>>>> someone has a bunch that play with nvidia accelerated vdpau&     mplayer correctly,
>>>>>>> could you please link them? ;)
>> I don't have any nvidia hw but these are interlaced mpeg2.
>>
>> HD
>>
>> http://www.w6rz.net/newmobcal1920.ts
>> http://www.w6rz.net/parkrun1920_23mbps.ts
>>
>> There are smaller and lower bitrate versions on http://www.w6rz.net
>>
>> SD
>>
>> ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/mobl_060.m2v
>> ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/bbc3_060.m2v
>> ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/cact_060.m2v
>>
>> I can easily get broadcast dvb-t SD much of which is interlaced.
> For some reason mplayer handles all the above images as progressive with vdpau,
> and it sets picture_structure to 3. I can see the interlacing on movement, but it
> doesn't seem like mplayer tells vdpau it is interlaced, sigh. :/
>>>> And it is a complete different thing to have a internal memory layout of separated top and bottom lines, because this layout is hardware specific, for example you could have all top lines first (luma and chroma) and the the bottom lines, or you can have luma top, then luma bottom, then chroma top then chroma bottom etc... Paired with different tilling modes that gives you probably a couple of hundred different memory layouts. It doesn't make sense to export this to a state tracker.
>>> Well, it depends. I read up a bit more, vdpau interlaced mode requires both fields to
>>> be decoded to the same surface. I've researched interlaced a bit more, so what I said
>>> about top/bottom field earlier can be ignored. I do think it makes sense to allow support
>>> for separate top/bottom fields though, if only because of deinterlacing algorithms and
>>> handling inverse telecine in a sane way.. to handle those you can't think of progressive
>>> frames any more.
>> IIRC it says in the vdpau headers/somewhere that nvidia keep fields separate internally.
> Doesn't look like it says it in the headers, but it doesn't really surprise me..
>
>>> I think if you want to handle things like deinterlacing and inverse telecine sanely, you
>>> would have to change your approach from handling in full frames to separate fields.
>>> You're right that memory layouts shouldn't be part of the state tracker. I think having
>>> support for separate field views that get merged in the video mixer renderer would
>>> be required to handle deinterlacing sanely, though. Nouveau could then just ask for
>>> simple weave deinterlacing on a progressive frame, while other deinterlacing
>>> algorithms could be used for interlaced videos. For example bobbing could just be
>>> done by stretching a field, and that algorithm is required to have for vdpau,
>>> according to the vdpau header.
>> It's really cool you are working on this.
>>
>> One thing to maybe condider early on is the mpeg chroma interlaced issue, which is covered here -
>>
>> http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html
>>
>> It actually initially describes the opposite case (treat progressive as interlaced) to what xv/gl/vdpau does(treat interlaced as progressive), but does explain the issues well.
>>
>> This sample shows the issue -
>>
>> http://www.andyqos.ukfsn.org/snooker-short.ts
>>
>> If you pause when the ball is bouncing around the pocket you can see that the chroma tears have bled between fields so look worse when decoded as progressive.
>>
>> I used -vo x11 for these without zoom to avoid an extra scale - all hw csc I know of will look like this one.
>>
>> http://www.andyqos.ukfsn.org/snooker-prog.png
>>
>> For the next one interlaced sw csc is used but without a filter so the tears are correct but the stationary red balls have artifacts.
>>
>> mplayer -vo x11 -vf scale=::1
>> or
>> mplayer -vo x11 -vf ilpack=0
>>
>> http://www.andyqos.ukfsn.org/snooker-interlac.png
>>
>> The only way to get this to look good is use ilpack which by default does interlaced properly plus filters.
>>
>> It actually converts to 4:2:2 so -vo x11 or xv will work (R600).
>>
>> mplayer -vo x11 -vf ilpack
>>
>> http://www.andyqos.ukfsn.org/snooker-interlac-filtered.png
>>
> Sadly mplayer tells vdpau to have all videos decoded as progressive so
> I can't really do anything. :-(
>
Oh, crap! That explains why I couldn't find any interlaced videos, 
sounds like mplayer just tells vdpau that it is progressive even if it 
isn't.

Maybe somebody should dig into the mplayer code and fix this. Any 
volunteers?

Christian.