[Ffmpeg-devel] upsampling of subsampled video data
Tue Sep 12 21:14:58 CEST 2006
On Tue, 12 Sep 2006 20:54:05 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:
> > Does this mean, that the C samples are inbetween the Y
> > samples and thus have to be interpolated in vertical
> > direction too before converting to RGB?
> > (apart from the missing sample every second line)
> as rich already said yes though i suspect that a 1/2 pixel position error
> will be less noticeable then not interpolating at all, and of course the
> position is just what the spec says, if that really matches the true sample
> locations may or may not be the case, depending on the source ...
Well, we'll have to experiment to see whether this makes
any big difference. And yes, this would make the hardware
much simpler ( a/2 + b/2 is easier to calculate than a/3 + 2b/3 ),
but the real issue here is the memory addressing and read unit.
It might very well turn out that the arithmetic logic is so
much smaller than the memory logic that doing the right
correction adds only very little overall complexity.
> also even though ive no clue about hw design, somehow i think that a
> optional prefilter which shifts the chroma samples by 1/4 pixel could be
> helpfull for the complexity of the interpolating stuff
I don't know. I haven't had a look at how this could be designed
yet. As i mentioned above, the memory subsystem is much more
complex and thus the arithmetic has to be adjusted in a way
so that the memory logic is as simple as possible.
Currently i'm thinking about doing a horizontal upsampling
during image upload from host memory (data arrives in full
lines with increasing x). Then, when the data is read, read
it in vertical direction and perform if necessary vertical
upsampling. But i have no idea whether this is feasible
(i'm far from being a graphics card expert)
> > BTW: while we are at it, how important is it to have a
> > YUV->RGB converter that supports different standards?
> > Ie, IIRC there are 3 different coefficients for YUV<->RGB
> > conversion by different standards groups. Is it important
> > to have a programmable converter to select one of these,
> > or would be one constant enough without too much quality
> > los for the others?
> my guess would be that a single one will be ok if complexity is an issue and
> it sounds like that is the case
Which one would you choose, if you had to choose one?
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
-- reeler in +kaosu
More information about the ffmpeg-devel