[XviD-devel] [WISH] Statistics and frame type returning

suxen_drol xvid-devel@xvid.org
Tue, 14 Jan 2003 21:18:35 +1100


On Tue, 14 Jan 2003 00:58:31 +0100 Edouard Gomez <ed.gomez@free.fr> wrote:

> Last mail before going to continue my training report...
> 
> I commited a patch to fix some but not all errors when returning wrong
> statistics from encoder_encode_bframes.
> 
> Changes:
>  - introduced frame->intra = 3 == S_VOP for GMC frames (the 3 number
>     seemed to be free) 
>  - Added lot of stats filling all over the code. Not hard to guess that
>    i added them where it seemd logical to put them. BUT this does not
>    mean the places were good ! this code is still a mess :-)

imho frame->intra is an ugly hack for ratecontrol.
intra was originaly intended to instruct the encoding
application/container when the current frame was a keyframe. 
not for frame type.

> Bugs:
>  - bframes do not report correctly header bits
>  - nvops fill the stats->quant with a value of 31, using 0 is impossible
>    because transcode and mencoder use my vbr lib and stores statistics
>    using code like this debug_quant[quant-1]++; 32 is not possible too
>    because we would be out of meory boundaries in similar pieces of
>    code.
> 
> My wish is:
>  - Could it be possible to fix bframe reporting ? thx

bframe reporting is difficult. we need to break the current api to do it
properly. the new api is ready, but if i commit it the existing 2-pass
becomes unuable... ive had no time to work on my new 2pass algo. besides
it needs more testing.

anyway, in the new api i have a encoder.c::set_stats() function which
gets called in display-order from encoder_encode_bframes(). this sets
the stats (XVID_ENC_STATS) structure. each FRAMEINFO struct stores the
length of the frame, header bits, etc.


-- pete; life is like a box of ammo