[XviD-devel] zig-zag

Christoph Lampert chl at math.uni-bonn.de
Wed Mar 12 11:27:00 CET 2003


On 12 Mar 2003, skal wrote:
> 	For intra-mb, in I-frame, the AC-prediction direction is
> 	used to choose between horizontal/vertical scan. But in
> 	interlaced mode, if the Alternate-vertical-flag is on,
> 	it's always the vertical mode.

Yes, that's logical. I don't use interlace at the moment,
so I'll forget that for now. 

> 	for intra-mb in a P-frame, with the flag off, it's the
> 	"regular" order that is used.

Okay. 

> 	For inter-mb, "regular" or "vertical" scan is chosen
> 	according to the Alternate-vertical-flag...

And that's part of frame header, too bad. 

Thanks!

It's because I just tested calc_cbp() with gcov and it seems that 
chroma blocks have completely different distribution of nonzero DCT
coefficients than luma. 
After running several sequences with and without Qpel/Bframes 
there is a big peak of non-zero coefficients at coefficient 
56 = 7*8+0 (more than 50% of chroma blocks are nonzero there!). There are
also peaks at 1 and the other multiples of 8 (40 is strong, too) which
seem rather logical if chroma changes more vertically than horizontally, 
but DCT[56] is by far the strongest and I have no idea why. 

Either I am doing something wrong, or it's a chromainterpolation/DCT/quant
problem, or it's simply that _if_ chroma is present it has many
high frequencies. DCT[0] is not checked in calc_cbp, btw. it would of
course peak, too. 

Anyway, neither zigzag, nor alternate, nor "linear" order differ between
chroma and lumi, so this is not handled correctly, but at least in cbp I'd
like to test if there is a speedup from checking some positions early. 

Oh, and after that I'll check with ME_CHROMA, maybe the peak is one reason
why that performs well. 

gruel 



More information about the XviD-devel mailing list