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

[Marc FD]

> > 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'm going to test TOOSMALL_LIMIT = 4. if the quality vs size is still good
(i'm coding HQ anime, so i've got lots of details) i would hold it :)

> 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?

okay, it's on my TestToDo list ;) seems a good idea.
i would try to implement SSD instead of an SAD for the coef-thresholding,
to see if it allows bigger TOOSMALL_LIMIT with more "crispness"

> >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.

yes, it's odd, strange, weird...
i would stick with the best of the 2 interpolations mode for both.
I've some users who seems ready to do lots of tests on a experimental
anime-build of XviD at doom9, so if there is still a bug, we would now.

> > and i gained 4 kbytes over the buggy build ...
>
> Yes, encoder was using bits to code this buggy chroma information.

?!? i was thinking it was due to a lack of chroma info in the bitstream.

> 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 ;-)

-> crispness max
"mpeg quant type"
"mpeg quant type + thresholding"
"h263 quant"
"h263 quant + thresholding"
-> compressibility max

seems ok. but i think we should go further and propose a much easier to
use interface to avoid bad cases like doom9 tests.

did you ever notice the 5th panel in DivX 5.x ?? seems to be for
Beta-testers and devellopers