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

[Radoslaw 'sysKin' Czyz]

> does TOOSMALL_LIMIT = 3 gives impressive size improvements ??
> because even with sp4, my build gives me a 21 Mb file
> at const quant 2 vs 22,5 for koepi's.
> visally checked quality (no PSNR test) and i couldn't tell any
> differences...

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?

>was already disabled with a comment. block based chroma interpolation caused
>the bug

It was disabled for inter mode, but enabled for inter4v. Gruel was
completely right when he assumed that noone will disable halfpel
search but enable inter4v, so he left inter4v with faster function
which doesn't work without halfpel.

>but now, when i disable the comments, and use the image-based interpolation
>(image based interpolation = halfpel, right ???)
>??!!?? THE BUG IS GONE ??!!??
>Strange and weird that doing exactly the opposite of what you said fixed
>this bug.

It's even stranger. The point is not that block-based or picture-based
interpolation caused the bug. The point is, that the same kind of
interpolation must be used for inter4v AND inter macroblocks. It
doesn't matter if you choose block-based (which allows you to use
non-halfpel motion search modes) or picture based (which is faster).
This obviously doesn't make any sense and I think there is a
completely diffrent bug, somewhere. 

> and i gained 4 kbytes over the buggy build ...

Yes, encoder was using bits to code this buggy chroma information.

Milos wrote:
> It would be best if
> this could be user selectable but it would just do more harm than good
> for regular users.

I have an idea. There should be some (only some) very easy controls for
'regular user'. There should be one that says "smooth/crisp picture"
like in old divx3. It would have 4 positions, which would correspond
to "mpeg quant type + thresholding"; "mpeg quant type"; "h263 quant +
thresholding", "h263 quant". Of course user would never see this API
terms, he would only choose if he wants details+blocks or he doesn't
want them.
But it's just an idea, for VfW developers. I might have mixed quant
types here - I always mix them ;-)

Radek