Talk:Video codec

From Wikipedia, the free encyclopedia

Video Codec Benchmarking is span isn't it? Shouldn't it be removed. —Preceding unsigned comment added by 84.64.1.148 (talk) 12:25, 27 January 2008 (UTC)

Hi all, while a lot of the very technical, math-heavy details that are in this article are beyond the scope of my knowledge, I am pretty familiar with video codec use in the real world, particularly in professional editing applications, and some details of the following little paragraph rang untrue to me:

A typical digital video codec design starts with conversion of camera-input video from RGB color format to YCbCr color format, and often also chroma subsampling to produce a 4:2:0 (or sometimes 4:2:2 in the case of interlaced video) sampling grid pattern. The conversion to YCbCr provides two benefits: first, it improves compressibility by providing decorrelation of the color signals; and second, it separates the luma signal, which is perceptually much more important, from the chroma signal, which is less perceptually important and which can be represented at lower resolution (hence the 4:2:0 or 4:2:2 sampling grid use).

First of all, there are to my knowledge video codecs that claim to be RGB, and not YUV or YCbCr (e.g. Kona's 10-bit RGB uncompressed codec, which I am rendering to right now, or Apple's Animation codec, which also supports an alpha channel). Are these all going back to YCbCr internally? I've never read anything to suggest this, but perhaps I'm wrong on this point? Also, the camera input as RGB strikes me as a little iffy as well but I know too little to feel OK changing that. What about the bayer-pattern data stored in RAW files/codecs? This isn't quite RGB yet, is it?

However what really rang strange to me was the statement about 4:2:0 and 4:2:2. While it's true that these are common, I feel the language to be misleading; these are simply two out of many choices of chroma sampling algorithms, right? While I have tried to make this less misleading, I also acknowledge that my knowledge of how the x:y:z figures for different video compression schemes are produced is not entirely accurate and that there is more here to be done by someone like Grame Nattress who actually writes these things. What are billed as 4:2:2 HD video codecs, for example, I think are supposed to be like 22:11:11, not 4:2:2, I think due to the numbers being related to data rates?

Anyway, here's what I left it with:

Video codecs seek to represent a fundamentally analog data set in a digital way. Because of the design of analog video signals, which represent luma and color information seperately, a common first step in image compression in codec design is to represent and store the image in a YCbCr color space. The conversion to YCbCr provides two benefits: first, it improves compressibility by providing decorrelation of the color signals; and second, it separates the luma signal, which is perceptually much more important, from the chroma signal, which is less perceptually important and which can be represented at lower resolution to achieve more efficent data compression. It is common to represent the ratios of information stored in these different channels in the following way Y:Cb:Cr. Refer to the following article for more information about Chroma subsampling.

Different codecs will use different ratios as appropriate to their compression needs. Video compression schemes for Web and DVD use make use of a 4:2:0 color sampling pattern, and the DV standard uses 4:1:1 sampling ratios. Professional video codecs designed to function at much higher bitrates and to record a greater amount of color information for post-production manipulation sample in 3:1:1 (uncommon), 4:2:2 and 4:4:4 ratios. Examples of these codecs include Panasonic's DVCPRO50 and DVCPROHD codecs (4:2:2), and then Sony's HDCAM-SR (4:4:4) or Panasonic's D5 (4:4:4). Apple's new Prores HQ 422 codec also samples in 4:2:2 color space. More codecs that sample in 4:4:4 patterns exist as well, but are less common, and tend to be used internally in post-production houses. It is also worth noting that video codecs can operate in RGB space as well. These codecs tend not to sample the red, green, and blue channels in different ratios, since there is no perceptual motivation for doing so.

I also added a little bit about wavelet transforms since I know Cineform uses that and I think it's what REDcode is too, so it's worth mentioning I think.

-Evan

thank you —Preceding unsigned comment added by 192.197.166.162 (talk) 14:13, 6 September 2007 (UTC)