[Mesa-dev] Status update of XvMC on R600

[Andy Furniss]

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.