On 15 Oct 2001, Gerd Knorr wrote: > > > Just use 4:2:2 and skip the chroma scanlines you don't want. > > > > Why is it that the bt848 can't just be programmed to skip the > > appropriate scan lines? That would be more efficient. > > I'd expect the difference is next to nothing. The only penalty is the > slightly larger working set due to some unused scanlines in the image, > thus leading to a few more cache misses. There is also the greater PCI bus bandwith from capturing 4:2:2 only to throw away 25% of the data. It's also often the case that one needs to pass the YUV data to other code, like a codec, that you don't want to re-write or many not even have the source to (like win32 codecs with avifile). That means you have to waste cpu cycles copying the chroma into 4:2:0 planes. > And how exactly the interleave should look like? One chroma scanline is > used for two luma scanlines, one from the even field and one from odd > field. No matter whenever I use the even or odd field for the chroma > scanline, it would match for one of the two luma scanline only. I can > make the bt848 interleave chroma too, but I don't see how this improves > the situation. It is still wrong for 50% of the luma scanlines. Imagine two fields, one that's solid cyan with Cb=235 and Cr=16 and the second field that is solid yellow with Cb=16 and Cr=235. If you record and then play back with 4:2:2, you get a solid cyan followed by a solid yellow field. If you record 4:2:0 with all chroma coming from the first field only, as bttv does now, you get a solid cyan field followed by a solid cyan field. That's very different than the original images. If you instead capture every other chroma scanline from the first field, and every other chroma scanline from the second field, you get a cyan field followed by a yellow field, which is much more correct. I would guess this is in fact why the MPEG standard calls for 4:2:0 data to be captured in this manner.
