Christian König wrote:
We currently only support 4:2:0 and deinterlace the luma channel very
early when copying to video buffers and to be honest, I have no idea how
interlacing is handled on chroma channels when there is only one chroma
value per four result pixels. I have read the section in the mpeg
standard about "DCT coding types" multiple times and still didn't
understand it completely.
But getting a proper deinterlace filter is priority B or even C. Getting
the picture to look "right" (get rid of all block artefacts) is far more
important then getting it to look "good".
Looking (for the first time) at iso13818-2 I think the chroma handling
would be part of display rather than decode, though the iso does specify
how chroma is laid out for fields in 6.1.1.8.
An article that describes the issues (it actually starts describing the
opposite problem of progressive treated as interlaced) is here.
http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html
Do you have any idea what is causing the remaining block artefacts? I
have the strong feeling that it has something to do with ignoring the
"motion_vertical_field_selection", but I haven't figured out what
exactly is going wrong here.
Not a clue :-)
My understanding of mpeg2 is a bit too high level, though I've no excuse
not to try and read the detailed spec.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
