[XviD-devel] [BUG] The encoder loop fix is a bigger bug :-)

[Edouard Gomez]

All is in the topic.

Your fix is very similar to one of my hacks. But i realized this was not
a fix  as it breaks  lot of more  usefull stuff like stats  and probably
max_bframes respect (always less than allowed maximum).

The problem is  you base stat report on the bframe  queue position == 0,
but when  dynamic bframe is on,  sometimes you have a  bframe queue with
this configuration:
 bframe_head = bframe_tail = x (with x < max_bframes)

So the  usual ststas output  does not apply.  Then when we  feed another
frame, bframe_tail  will be increased.  This leads to the  not respected
max_bframes setting, as  it was previously set to  1, we'll have "random
size" < max_bframes GOPs.

Btw when i experimented this fix (probably before my "i'm mad about this
bug" mails) i  succeeded in having right stats  with something like that
(sorry i gave up and erased all  my working trees, i was too fed up with
the code):

In encoder.c
@1258@
-    if ((pEnc->mbParam.global_flags & XVID_GLOBAL_PACKED) || pEnc->mbParam.max_bframes == 0) {
+    if ((pEnc->mbParam.global_flags & XVID_GLOBAL_PACKED) ||
+        (pEnc->mbParam.max_bframes != 0 && pEnc->bframenum_head == pEnc->bframenum_tail) ||
+        (pEnc->mbParam.max_bframes == 0)) {

Btw this was not fixing the varying <max_bframes problem. Of course this
impacts not only stats but also the call to the plugin system...

Glad to see i'm  not the only one to fail miserably  at this bug hunting
;-) Indeed it was a nice try pete :)

PS: just run xvid_encraw to observe the bug action:

   12: key=0, time= 82, length= 846 | type=P, quant=  15, length= 984, psnr y = 33.09, psnr u = 39.92, psnr v = 41.65
   13: key=0, time= 111, length= 189 | type=B,  quant= 27, length= 189, psnr y = 40.53, psnr u = 54.00, psnr v = 55.24
   14: key=0, time= 78, length= 688
   15: key=0, time= 71, length= 707 <-- begins to bug  here, the delay should not be > 1==max_bframes
   16: key=0, time= 75, length= 683
   17: key=0, time= 71, length= 700
   18: key=0, time= 67, length= 673
   19: key=0, time= 70, length= 539
   20: key=0, time= 68,  length= 576 <--  then the dynamic  decision is still perturbing the old code.

And the jump from  quant 15 to quant 27 is probably  caused by a missing
call to the  plugin system. The CBR code is always  forcing a +/-1, here
it's not the case. 

-- 
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/20030516/fdd9dfe6/attachment.bin