[Ffmpeg-devel] ratecontrol advice
Fri Jul 29 01:34:24 CEST 2005
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.
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...
> 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
>>> 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
>> 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
>>>> 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
>>> 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.
>> ffmpeg-devel mailing list
>> ffmpeg-devel at mplayerhq.hu
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
More information about the ffmpeg-devel