[Mesa-dev] reworking pipe_video_decoder / pipe_video_buffer

[Andy Furniss]

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.


>> 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.


> 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