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. :-( _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
