[Ffmpeg-devel] ratecontrol advice

Fri Jul 29 02:38:11 CEST 2005

Hi Matthew,

My settings are set dynamically but tend to be like this:
         gop_size =  60
         bit_rate = 118000
         time_base.num = 1
         time_base.den = 30
         bit_rate_tolerance = 118000/5
         qmin = 3
         qmax = 10
         mb_lmin = FF_QP2LAMBDA * qmin
         mb_lmax = FF_QP2LAMBDA * qmax

Other values were left at default values.  I'm not sure what you mean by 
i_q_factor and strict VBV ratecontrol-- can you explain?

With these settings I get I frames of around 8K bytes and P frames of about 
50 -> 1000 bytes depending on the motion.   Also, I find that the bit_rate 
varies a lot -- it might be quite a bit higher than 118000.

What I'm trying to achieve is an encoding that keeps the quality to a 
certain level with the frame rate at or below a certain size.

Dan

At 04:34 PM 7/28/2005, Matthew Hodgson wrote:
>Hi Dan,
>
>Thanks for responding... on re-reading my original mail, I realise that it 
>may have been a bit confused^Wverbose; for the end problem I have is 
>ironically *not* that static images take a long time to resolve, but the 
>opposite - my ffmpeg tends towards single large keyframes, which don't 
>subsequently get updated at all by any predictive frames!  Instead, I 
>actually want the blur-convergence behaviour, in the hope that it'll 
>reduce the average size of the frames :)
>
>What settings are you using to get the blur-convergence behaviour?
>
>When avoiding it, I've been using qmin=3, i_q_factor=2.0, and qdiff=15 
>without strict VBV ratecontrol, which gives me huge I-frames every GOP, 
>and empty P-frames in between.  I'm trying to find a way of reducing the 
>size of those I-frames whilst not compromising the minimum quantisation of 
>I & P frames for normal talking-head style content.
>
>thanks;
>
>Matthew.
>
>On Thu, 28 Jul 2005, Dan Finkelstein wrote:
>
>>Hi --
>>
>>I have also noticed the same phenomena where the h263 encoder will take a 
>>number of seconds to converge to a sharp image.  My observation is that 
>>when a quick movement is made, the image becomes quite blurry and will 
>>slowly converge.  I've also had trouble picking parameters in the encoder 
>>so that the frames are encoded up to a desired maximum data rate and the 
>>quality remains decent.  (I'm using ffmpeg from cvs a couple of weeks back.)
>>
>>If you happen across a solution to this, could you please pass it my way 
>>! I'll be glad to test it...
>>
>>Thanks,
>>Dan
>>
>>
>>At 07:12 PM 7/25/2005, Matthew Hodgson wrote:
>>>Hi folks,
>>>After a bit of a hiatus, I finally got 'round to trying to cap frame sizes
>>>generated by ffmpeg in 1-pass h.263 encoding.  Unfortunately, things did
>>>not go smoothly - I tried Loren's advice of:
>>>Loren Merrit wrote:
>>>>But if you don't mind modifying a few lines of code, look in
>>>>modify_qscale() line 435 or so. Currently that limits per-frame bits
>>>>based on the number of bits left in the VBV buffer; you could put in your
>>>>own cap similarly. (Warning: anything done by a 1pass encode will be an
>>>>approximate/soft limit, since you don't know in advance excatly how many
>>>>bits a given QP will take. So you'll need to fudge the limit a little if
>>>>you care about strict compliance.)
>>>...but unfortunately the predicted size of a frame given by qp2bits(rce, 
>>>q) in modify_qscale seems even more inaccurate than I feared.  The 
>>>problem seems to be that the estimate of the frame size has to converge 
>>>over time - which is fine for a longish talking-head style video; after 
>>>~60 frames it gets pretty accurate and you can detect potential large 
>>>framesizes and clobber their QP.
>>>However, when a video is made up of a series of different still images 
>>>(e.g. non-scrolling credits) it takes much longer (~120 frames or so). 
>>>And whilst it's converging, it guesses the framesize pretty badly - 32 
>>>bits rather than the actual 14296 for the first frame, 500 bits rather 
>>>than 25480 for the 30th frame, 153315 bits rather than 74776 for the 
>>>77th frame, etc. (However, frame 91 is almost right (30767 v. 26312), 
>>>and by frame 121 it's pretty close (30546 v. 30144)).
>>>Am I using the wrong metric for estimating the end frame size in 1-pass 
>>>encoding?   And does anyone know which of the various counters & 
>>>predictors starts off initialised incorrectly, causing this convergence effect?
>>>Alternatively, I need a way to tell the ratecontrol to encode a sudden 
>>>change in static image as a small I + several incremental P frames - 
>>>rather a single huge monolithic I frame and a subsequent string of 
>>>'empty' P frames.  Is there any way to force ffmpeg to encode in this way?
>>>Rich Felker wrote:
>>>>On Tue, May 10, 2005 at 12:55:44AM -0700, Loren Merritt wrote:
>>>>>(Warning: anything done by a 1pass encode will be an approximate/soft 
>>>>>limit, since you don't know in advance excatly how many bits a given QP
>>>>>  will take. So you'll need to fudge the limit a little if you care
>>>>>about strict compliance.)
>>>>While true, this isn't an inherent limitation, just a flaw in lavc's rate
>>>>control engine. It's easy to implement strict limits in 1pass encoding:
>>>>just repeatedly reencode the frame at different values of qp until you
>>>>find one that gives the size you want. With binary search it shouldn't
>>>>even be that slow...
>>>I've also tried going down this line of attack, but it seems that ffmpeg 
>>>doesn't make multiple executions of the encode_thread for a given frame 
>>>very easy - all the rtp callbacks and bitstream output happen directly 
>>>from within the thread.  I take this to mean that I have to completely 
>>>isolate the encode_thread and buffer all its sideeffects in order to run 
>>>it in a sandbox to see how big its output is going to be, and then 
>>>re-run it with a higher QP as needed.  This seems relatively tricky - is 
>>>there a better way of doing it, or is this the only way to go?
>>>I've also tried doing a two-pass encode and fiddling the stats file 
>>>between passes by boosting the perceived i_tex/p_tex/var on frames which 
>>>were too big, hoping that the next pass would overcompensate and shrink 
>>>them down. This doesn't seem to work at all - i'm assuming that some 
>>>kind of blurring or smoothing is annihilating my hacky tweaks, or I'm 
>>>completely misunderstanding how the multipass encoding is mean to work.
>>>any suggestions would be enormously appreciated.
>>>cheers;
>>>M.
>>>_______________________________________________
>>>ffmpeg-devel mailing list
>>>ffmpeg-devel at mplayerhq.hu
>>>http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>>
>>
>>_______________________________________________
>>ffmpeg-devel mailing list
>>ffmpeg-devel at mplayerhq.hu
>>http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
>_______________________________________________
>ffmpeg-devel mailing list
>ffmpeg-devel at mplayerhq.hu
>http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>