386SX wrote:Well I always thought that conversion was more a "box feature" than really something to benefit.
Back then it really was an issue...
PCI only has about 120 MB/s bandwidth at most.
Now if you take 1024x768 32-bit, at 50 fps, you get 786KB*4*50 = 153MB/s. It simply isn't physically possible to upload video images to the card that fast.
So you'll want the card to perform scaling, so you can upload less data per frame.
Likewise, YUV can be seen as a form of compression. With RGB you get 24-bit per pixel (in practice videocards usually work with 32-bit, for alignment purposes). YUV in MPEG is stored in a 4:1:1 pattern. So only 1 in every 4 pixels has U and V information. Which means you have 6 bytes for 4 pixels, instead of 12 bytes. So it's 50% compression there.
Having the card perform YUV-to-RGB means you again have to upload less data (in practice it's usually YUY2 on early hardware, which means it's just 4:2:2, so you only have to process it horizontally, not vertically).
Aside from that, YUV-to-RGB is also reasonably CPU-heavy, involving some matrix-vector multiply for every pixel, and doing it the right way is even more expensive.
Most software players would just copy the same U/V pixels to all 4 pixels in the 2x2 block. This results in very blocky red and blue components in the image.
Doing it the right way involves bilinear filtering of the U/V pixels. Basically you take the U/V values as the center of each 2x2 block (subpixel-correct processing), and you 'smear' the values into the neighbouring 2x2 blocks.
Most hardware scalers will do this correctly.
So yes, it really did make a big difference, both in quality and because you can now run at much higher resolutions with little or no difference in performance.