[XviD-devel] New Trellis Quant

[Radek Czyz]

>> >         /* quality 6 */
>> >         XVID_VOP_DYNAMIC_BFRAMES | XVID_VOP_HALFPEL |
>> >         XVID_VOP_INTER4V | XVID_VOP_MODEDECISION_BITS |
>> >         XVID_VOP_HQACPRED
>> 
>> Allrighty, I found the problem: even if you're doing BITS refinement,
>> you should still do sad-based refinement! 

> Why?

>> The code will work without
>> it, but PSNR _must_ decrease... 

CL> Why? 

K...
1. BITS makes one single check of the vector found by SAD search. If
all luma blocks are zero, it stops. This is important, because at this
point BITS can't do anything better - it can find a vector which is
easier to code, but it will completely ignore quality of this vector
(as cpb == 0 means that distortion is below some value, but you don't
know how low).
If we haven't done SAD refinement, it will end without any refinement.
This is why it was so fast at low bitrate (it's not a big issue at low
quants, because most blocks are coded then).

2. The next step after checking this vector is fullpixel diamond. If
current value is not refined, BITS count might be high, which might
cause the diamond to actually 'work' and wander away from the original
value found. Subsequent halfpel and qpel refinement will never go back
to this spot, so if there was a great value in halfpel (or qpel)
position next to fullpel position found, it will be missed.
SAD is good for gradient-descent, BITS not - sure, it's good to do any
search, but only if SAD gradient-descent failed first.

3. Check for yourself... Most of what I've written above is theory that
just matches my experiments.

> Nooo, not to dev-api-3... this will be a complete desaster, to add new
> features to dev-api-3 _and_ dev-api-4 at the same time.

Heh.... so.. you want me to work on dev-api-3 (because it fully works
on windoze machine) and then port it to dev-api-4 ? Sounds even worse
:/

Radek