radeon textured video chroma shift?
rscheidegger_lists at hispeed.ch
Wed Dec 21 11:48:57 PST 2011
I think that the textured video code doesn't quite handle the chroma
values right. It uses the same texture coords for luminance and
chrominance values. mpeg2 however actually defines the chroma samples to
be vertically between two lines (for non-interlaced content anyway, I
won't go into the mess that is 4:2:0 interlaced which is fundamentally
broken by design), and horizontally they are located at the first pixel.
So when using the same texture coords, this should result in a
half-pixel horizontal chroma shift (vertically it should be fine).
As far as I can tell this is true for all radeon textured video code,
for planar as well as packed formats (I don't know how the hw handles
the fixed yuv formats some of the older hw has).
Overlays may or may not be affected, I'm quite sure these could be
programmed either way, but the magic involved in setting them up
properly is astonishing, I really can't tell which way it's done :-).
I'm wondering if this should be fixed or if it's even considered a bug.
Cause I could not actually figure out if these formats (YV12, YUY2 and
friends) really have well defined chroma positioning (just to mention,
this is a real issue, mpeg1 defines chroma horizontally between two
points too for instance).
In any case, these formats are likely used most often with data coming
from mpeg2 (or h264 which hopefully should be the same there) content.
Though if the formats really have well-defined chroma positioning, we
should of course adhere to that.
More information about the xorg-driver-ati