[XviD-devel] [TODOLIST ITEM] Bit rate controler module

[Edouard Gomez]

--YToU2i3Vx8H2dn7O
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Marc FD (marcfd@free.fr) wrote:
> hi ^^

hi


> since you're just doing the stuff, i've a request.
> surrent vbr mode is, IMHO, not very flexible.
> and the way bframes are handled is not very clean too.

I did not look at the bframe new code of the vfw 2pass module... but i
agree as it was already a mess (sorry Foxer, but i must admit i do not
understand half the code in it, even having used it myself for the lib
port)

> i've got the following idea, say if it makes sense.
>=20
> first, divide encoder_encode_bframes in 2 parts :
> encoder_encode_bframes and encoder_scan.
> the first one is a blind version of the encoder, you need to say him
> everything (vop, quants, ect... all globals) and when you code
> a iframe, you can give him vop based info.
> the second version is based on syskin's MEanalysis. you request
> info with a stats structure, and it'll fill the fields you need.
> we can expand it to do various checks, even full ME if wanted.
> the goal is to have estimations for the RC module to work with
> (choose vops/quant/ect...)

That's ... hmmm you started from a wrong point of view... RC is not
controling the encoder functions... encoder_encode_bframes will call rc
to know what type of frame it has to encode (replaces current if
statements with MEanalysis for 1pass, or retrieve information about
frame type during 1st pass for the 2pass RC) and the quantizer. It's
also possible, like with old core to tel the encoder to code it P and if
motion is too high, code it as late intra (syskin tell me if your new ME
forbids such a possibility)

Anyway, the gettype function was introduced mainly for the 2pass RC, i'm
trying to use it with 1pass RC as well, but i think it will be difficult
as decision is made by the MEanalysis function which uses frame data to
determine what it decides for this next frame.

> the RC module will be updated 2 time per frame :
> between scan and encode, and after encding.

No. Update must be done once a frame, after the so called scan (which is
in fact getquant()+gettype() in my design) the RC has not to be updated,
we already know what we are expecting, then update() updates the
correction for the next frame (display order).
=20
> RC module could be asked how many frames he wants to scan
> in advance (for exemple, it would be max_bframes in current implementatio=
n)
> for bframes, we'll of course need to support unsequential RC.

That's the problem i'm now facing at... bframes are difficult to handle
because RC does the job in display order, and bframes break this
postula.

> BTW, i don't understand why you speak of 2pass stats format. it's the task
> of
> the 2pass RC module, not of the api. all 2pass RCs can have a different
> format.

I was talking about the parameters in the function prototype so _it's_ the
API. Stats file is something totally different.

> i know the API will be harder to code this way, but RC is a crucial part =
of
> encoding,
> and there is not only 1pass ABR, 2pass VBR and 1pass const quantizer mode=
s.
> this way you can implement various RCs, like :
> 1pass hybrid 2pass, 3pass, 1/2pass cluster mode, ect...

1pass hybrid 2pass ? (explain me what it is)
3 pass is no problem.
cluster mode is not core level... it's an application layer problem
(cluster is network...) and if you were talking about SMP chunking then
i would answer exactly the same... the application cuts the source
stream into smaller parts, creates various encoder instances (and if we
solve the last problems with reentrancy) and then merges the stats files
together so the curve would be treated fine as a whole.
=20
> i don't know if it possible, but if it's possible, we'll need to do it a
> day, no ?

I invite you to read my current code (actually an external lib, API is
still not fixed because of a possible problem with 1pass and MEanalysis
that could need the Encoder structure)=20

Look at the code and read the ToDos... i think we have first to sort out
how we can handle bframes before considering some higher problems... we
have first make the code consistent for todays use before writing the
"universal killer" RC.

http://ed.gomez.free.fr/files/libxvidrc.tar.bz2

Perhaps VC users would have to change the int64_t define so it uses the
VC type instead of the ISO C99 long long keyword(s).

PS: it's late, perhaps i told you something not very precise... sorry
but i'm tired.

--=20
Edouard Gomez

--YToU2i3Vx8H2dn7O
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE99TqSR5dTYz5sWMcRAjqxAJwJ71h1+Yh7onRUy0ITBJIWh5UESgCgqotn
2YIY4wMzkaqm/0MohdlEJQ8=
=gCM6
-----END PGP SIGNATURE-----

--YToU2i3Vx8H2dn7O--