[FFmpeg-devel] [PATCH] RoQ video encoder
Sat Jun 2 21:01:52 CEST 2007
Michael Niedermayer wrote:
> its hard to comment on code i dont see ...
> why not post the relevant part of the file?
There are my current changes to it. Converting it back into 4:4:4
hasn't been done yet.
* numCB4==256 forces numCB2=256 to comply with Q3 decoder
* RoQ_ID_MOT is now handled properly
* Possibility sorter replaced with two-step list builder
I'll see if I can get the 4:4:4 conversion done (I think that just
requires changing the eval functions and the common apply code, which
will also fix the decoder), and make reduce_p_lists operate on a target
quality and only use pure CBR if it needs to cap the frame size to meet
the max rate. The pure CBR function might be useful for getting a good
starting lambda too.
> also the lambda factor could be used when deciding the codebook size
I'm not sure this is even possible. Codebook size is a product of which
entries get rejected from the image from other optimizations, it isn't
really controllable or predictable, which is why it's currently not
considered at all when weighting options.
> and last, id like to repeat that pure CBR is a very bad idea
> you could look at lambda as a value which says how much distortion
> you would be willing to trade for 1 bit, so very wildly variing it between
> frames to maintain a constant size per frame is like saying one bit of this
> frame is worth X distortion while 1 bit in the next frame is worth 100*X
> distrortion ...
> also id say libavcodec/ratecontrol.c could be used if you want ratecontrol
> but this can easily be added later, that is after the encoder is in svn ...
ratecontrol.c is laced with MpegEncContext dependencies, so I'll see if
I can learn something from it, but the rate control stuff is probably
gonna have to be done specifically for this the same way the motion
Again, I know nothing about this sort of stuff, so if you have any
advice on an algorithm or approach to use, I'm listening.
More information about the ffmpeg-devel