[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