[Ffmpeg-devel] ratecontrol advice

Fri Jul 29 01:34:24 CEST 2005

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
>