[XviD-devel] Re: vfw 2pass stats

peter ross xvid-devel@xvid.org
Mon, 14 Oct 2002 23:21:11 +1000


>Maybe i'm wrong, but wouldn't be better to make ONLY a vbr mode in the 
>core.
>Not a scaler, only the stuff we need to encode vbr like (x-pass).
>
>This way, any scaler could work for 2pass.
>
>for additionnal information, a XVID_ENC_RC structure is a good idea.
>the caller could add specific flags like XVID_CALC_P ( eg for your p-domain
>stuff )
>who will enable the computation of specific data and report in the stats
>file.

XVID_ENC_RC is gonna to store all the tate control data.
it will specify the rate control mode (fixed-quant,cbr,vbr_1st_pass,
vbr_2nd_pass,etc.) and revelant data (filenames,bitrate,etc) stored
in a union.

>i don't like the idea to have the scaler in the core, because i think
>scaling
>is far, far from perfect; and i always thinked it's a pain do a full 2nd
>pass
>to test somme Alt-CC settings (with vfw), to see that you messed up
>something
>after 3 hours of encoding. and the curve was mainly created 1 ms after the
>beginning
>of my first pass !?

so you want the ability to scale the curve, then analyse it before
actually performing the encoding.

>it's why i think scaling should be external. to have the possibility to
>check
>the scaled curve. it would be a very pro approach, with full control of the
>vbr more,
>and 2pass users would need to pray a bit less for each encode ^^
>
>Correct me if i'm wrong.

you're not wrong.
however i reckon the current stats arrangement, which provides
internal _and_ external curve scaling works well. new users can
perform 2pass out of the box, whilst pro users are free to use &
develop alternative stats programs (scalers, analysers, etc.).

-- pete

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com