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