Re: Re[4]: [XviD-devel] motion compensation->inter4v->BFRAMES->chroma bug?

["Marc FD" <marcfd@xxxxxxx>]

> Yes, coeff thresholding (which is a bit more then TOOSMALL_LIMIT = 3 )
> gives impressive size improvements and totaly unimpressive detail
> degradation.
> As Milos wrote, it's very possible that it is not visible with anime.
> You might even try TOOSMALL_LIMIT = 4 ? I'd be gratefull for the test.
> I wouldn't mind if someone tested TOOSMALL_LIMIT = 2 (with movie, not
> anime).
>
> I also have another idea - variable TOOSMALL_LIMIT, based on the lengh
> of motion vector. The faster the motion, the bigger 'cutoff'. Something
> like TOOSMALL_LIMIT = 1 + (ABS(mv.x) + ABS(mv.y))/4. Any comments
> about this?

i've tested coeff thresholding on anime, and the results are really
amazing...
but maybe i use a too low quantizer (constant quant2) to see the blurring.
(but i tried with VDub's sharpen(64)  and 2x zoom !! )

observations:
- i saw a bug when i used motion-dependant CT, but i think it can be avoided
by clipping the result under a defined value
(TOOBIG_TOOSMALL_LIMIT ^_____^ )

-i couldn't use TOOSMALL_LIMIT = 0,
XviD coded the first I-frame and simply stopped to work. like an
infinite loop...

-TOOSMALL_LIMIT = 1 gived _exactly_ the same bitstream than
TOOSMALL_LIMIT = 2.

but i think there is no bugs here. it seems more or less logical when i see
the code.

i attached a file with the result of a PSNR test on 3190 frames of an anime.
take a look. i would make a real-life encode (not dumb const quant2 test)
this morning.

dreaming of unbelivable good XviD anime encodes,
MarcFD  marc.fd@xxxxxxxxxxxxxx