[XviD-devel] Forced iframes lost?

[peter ross]

>Hi,
>
>over at doom9 we fell over a small glitch which results in unneccessary 
>"bad" encodes:
>
>We take the iframes from the first pass (-> stats file) and force them in 
>the second pass.
>But reality looks different:
>
>*1st-pass*
>Number Of Intra-Frames (Key-Frames) : 180
>Number Of Inter-Frames (P-Frames)   : 6476
>Total Number Of Frames              : 6656
>
>*2nd-pass*
>Number Of Intra-Frames (Key-Frames) : 173
>Number Of Inter-Frames (P-Frames)   : 6483
>Total Number Of Frames              : 6656
>
>I looked through VFW and couldn't find any false "assigns" there, so I 
>think this is an issue from the core.
>
>This results in some weird things with overflow: at sch a false 
>non-keyframe the overflow jumps to a very high value (well, actually a very 
>low value like -20000 bytes), which then gets redistributed as gracefully 
>as possible, but still resulting in quants +1, +2, +3... where without this 
>"feature" we would continue with the average quantizer we had before.
>
>Ah, this is concerning the "stable" tree btw., with dev-api-3 2pass is 
>totally messed up due to the dynamic I/P/B decision mechanism ;)
>
>Anyone with more insights into this matter?
>

"i-frames are forced when xvid_enc_frame->intra = 1"

the frame decission within 
xvid-stable/xvidcore/src/encoder.c:encoder_encode() looks correct and
i just diff'd encoder.c against code from month ago: very little has
changed.

if its not encoder.c, i wonder what else it could be?

-- pete

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com