[Ffmpeg-devel] upsampling of subsampled video data

[Rich Felker]

On Tue, Sep 12, 2006 at 09:02:35PM +0200, Attila Kinali wrote:
> On Sun, 10 Sep 2006 23:39:04 -0400
> Rich Felker <dalias at aerifal.cx> wrote:
> 
> > Also, it's ideal for the YUV->RGB to be done at the DAC level, not
> > into a quantized RGB framebuffer. 
> 
> Sorry, DACs eat RGB, you cannot feed them YUV. The only thing
> you can do is convert it with as much precission as possible
> and feed as many bits as possible to the DAC.

Obviously this is what I meant. The point is not to use the
framebuffer because it only has 8 bits per channel, at best (and 5/6
in the common case of 16bpp video mode).

> But the primary objective of the card will be LCD monitors
> which have their DAC on board and can only take 8bit/pixel/colour.
> (Not to mention that most LCDs have still 6bit/pixel/colour resolution).

*puke* so it's made for people who want horrid video quality? LCD just
plain sucks...

> > The reason is that the quantization
> > levels for YUV are different from RGB and requantizing the Y as RGB
> > will introduce ugly banding. 
> 
> What does banding mean? I quick google didnt show up anything
> relevant.

It means rougly that the gap between intensity A and A+1 might be 1
RGB unit, but the gap between intensity A+1 and A+2 might be 2 RGB
units. Ideally up to 2 RGB units should not be visually distinct to
the eye (for this very reason), but LCDs are not ideal and reproduce
the distinction very sharply especially at low intensities. This is
why they all suck.

> > I dunno if existing cards work around
> > this or not, but it's yet another reason why YUV should be done as
> > overlay and not blitter.
> 
> Somewhen YUV has to be converted to RGB. It does not
> matter when and how you do it. If you do it wrong, it will
> look wrong, no matter whether it was blitting or overlay.

But it's difficult (usually impossible) to do it right with a blitter.
You need at least 10-bit-per-channel RGB video mode for nice results.

Rich