[XviD-devel] Request for ideas/comments about 2pass

[Edouard Gomez]

Edouard Gomez (ed.gomez at free.fr) wrote:

> 1/ some scaling (valid for all frame types)
> 2/ if(frame type == bframe) frame length *= avg_pframe_length/avg_bframe_length;
> 3/ apply old algorithm for pframes
> 4/ if(frame type == bframe) frame length *= avg_bframe_length/avg_pframe_length;
> 5/ compute quant from scaled length in 4 and original quant.
>
> [...]
>
> I  think  the adaptation  of  bframes length  is  the  culprit in  our
> algorithm. I  suspect it to be the  one that makes the  bquants are so
> high.

I removed these  2/ and 4/ steps  and adapted 3/ so it  uses s->type for
gathering info for its scaling.

> In the first pass, we had this formula:
> (1) bquant = ((quant + ref_quant)*ratio/2) + offset (ratio and offset in %)
> 
> Our 2pass code uses:
> (2) scaled_quant/scaled_length = pass1_quant/pass1_length;
> 
> And  then  the  encoder loop  applies  (1)  again.  This is  the  most
> noticeable bug, but i suspect the step 2/ in the algorithm hurts too.
> 
> I'm currently trying to apply (1)^-1 before returning the quant to the
> encoder. This way we would apply (1) only once. I keep you informed of
> my progress.

I also applied (1)^-1

Now the results (snipet from a larger debug output):


...
[982] type:p quant:5 stats1:433 scaled:194 actual:730 overflow:4712
[983] type:b quant:9 stats1:434 scaled:195 actual:200 overflow:4690
[984] type:b quant:7 stats1:1571 scaled:706 actual:321 overflow:5058
    [986] orig_bquant:8 bquant:5 ref_quant:4
    [988] orig_bquant:8 bquant:5 ref_quant:4
[985] type:p quant:6 stats1:459 scaled:206 actual:738 overflow:4509
[986] type:b quant:10 stats1:503 scaled:226 actual:202 overflow:4516
[987] type:b quant:8 stats1:2526 scaled:1136 actual:279 overflow:5356
[988] type:p quant:6 stats1:569 scaled:256 actual:1057 overflow:4538

How to read that:

lines  beginning at  position 0  are real  results  (from plugin_after),
lines beggining  at position  4, are corrections  that come  from (1)^-1
orig_bquant is the  scaled quantizer, bquant is then  the quant computed
from (1)^-1, ref_quant is taken from rc->last_quant[XVID_TYPE_PVOP-1] (i
know i should search for the nearest IFrame or PFrame, it's just mean to
be a temporary hack)


So what can we see there:

1. Because of  the encoder loop,  even if we  specify a quant,  they are
nearly always changed. why? because of 2 things:
 - the dynamic frame type decision.   Sometimes we have a pframe that is
   changed to  a bquant by the  encoder loop ([987], the  lack of bquant
   correction output shows  2pass was treating it as  a pframe).  But we
   have also the opposite, a bframe  becoming a pframe ([988], we have a
   bquant correction but it appears finaly that it is coded as pframe). 
 - The encoder loop is interfering too much with our quant calculation. 
   And  because  of the  first  point,  it is  very  hard  to provide  a
   quantizer that  will not be  misinterpreted by the encoder.  A bquant
   being applied  (1) twice. or  a corrected bquant being  applied (1)¯1
   twice (only when using closed_gops)... 

Conclusions:

1. in  my   very  humble  (but  rationale)   opinion,  bquant_ratio  and
bquant_offset should  be part of RC  plugins.  RC plugins  should be the
only ones which have to know about these parameters. This is logic if we
think about RC plugins as "best quantizer finding" plugins.

2. Another remark,  min/max_quant[] arrays have been moved  from each RC
to the xvid_enc_create_t structure. But  encoder is never using them, it
only serves  them to _all_  RC plugins. I  think the reason  behind this
move  is that  these max_min_quant[]  arrays have  to be  shared  by all
plugins (tell me if i did not get the point). But imo, they are not part
of the encoder. I have a nicer way to manage the sharing problem.
 - put back quant limitations in _each_ plugin. 
 - plugins are responsible  of updating the data>max/min_quants arrays
   with more restrictive values during plugin creation. (max{min_quants}
   and min{max_quants})

This way, we don't pollute the encoder creation API with parameters that
are not really part of it.

3.we should add a NO_DYNAMIC_FRAMETYPE_DECISION flag so two pass algorithms
work as expected and are not fooled by the encoder internals.

It's now time to close this long mail.

PS: i will have not much time for XviD in the next weeks because of lot
of school work.  So i throw my ideas/opinions now, just  in case i could
not  turn them  into real  code so  someone could  always see  if  i was
telling bullshit or else implement them. 

-- 
Edouard Gomez-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030525/55587736/attachment.bin