[M4IF Technotes] Chroma components in inter4v mode

[Gary Sullivan]

+> -----Original Message-----
+> From: Christoph Lampert [mailto:chl   math.uni-bonn.de] 
[...]
+> But in YUV 4:2:0 chroma is 1/3 of total uncompressed data, lumi
+> is 2/3. 
+> If vectors are chosen such that lumi is compressed better, 
+> but chroma isn't (maybe even worse), I can't estimate which ration 
+> of the resulting compressed data chroma is. I'd guess it's more 
+> than 1/3, because vectors are chosen to minize bits for lumi, not
+> for chroma. 
It's normally less than 1/3.  What matters is not the
number of samples to code, it is the statistics of the
input samples and what you do with them (this is a very
important point that is often neglected in people's thinking).
My understanding is that chroma usually takes 10-20%.
+> 
+> I'm not worried about image quality getting worse, because 
+> it's true that chroma quality is much less important that lumi.
+> But I'm worried that at a given quantizer the bitstream gets larger 
+> than necessary, because chroma is motion compensated using a 
+> vector that
+> was never checked to be a good choice for anything. 
Actually it is normally better for chroma to be quantized
more finely than luma in 4:2:0 content (as for example in
the H.263 Annex T and JVT codec designs).
But chroma tends to be statistically lower amplitude / more
correlated than chroma, so it consumes fewer bits per sample
at a given step size.
Note that also a little sloppiness in the chroma motion comp
can be fixed up by the quantizer.
The resulting fidelity is dominated by the quantization
step size, not the quality of the motion estimator.
Best Regards,
Gary Sullivan