[Ffmpeg-devel-old] Re: [Ffmpeg-devel] Some tweaks to better respect max bitrate

[Rich Felker]

On Sun, Dec 25, 2005 at 05:03:08PM +0100, Erik Slagter wrote:
> On Sat, 2005-12-24 at 08:56 +0000, Mean wrote:
> > Michael Niedermayer wrote:
> > > ok, i tried this patch, it lowers PSNR by 0.06 increases filesize and doesnt
> > > get rid of a single buffer underflow (12 before 12 after this patch)
> > >
> > > rejected
> > >
> > > command line used 
> > > ffmpeg -i ~/videos/xXx_DivX.avi -cmp 2 -subcmp 2 -mbd 2 -an -pass 2 -b 300 -maxrate 400 -bufsize 60 -psnr test2.avi
> > >
> > Hello,
> >     on typical SVCD type video it helped a bit, but without the "look in 
> > the future" part it is not enough
> > to get rid of the underflows, because in case a large intra comes in, it 
> > is too late to compensate.
> > 
> >    The "look ahead" part is used in a slightly modified xvid ratecontrol 
> > engine which glued to libavcodec
> > mpeg2 encoder works mostly (not 100 % perfect but much much better).
> > 
> >    The algorythm is to do predictors for I/P/B frames, compute a "shrink 
> > factor" compared to pass1
> > and project to the next half gop to see if we will run into trouble. If 
> > so increase quant until the
> > projection is safe (+ some tweak to reserve more space for the 1st intra).
> > 
> > It is a bit like what i done in lavcodec , before doing the 2nd pass, 
> > but it is done on the fly rather than
> > before doing the actual encoding.
> > 
> > The other way to do it would be, IMHO, to use a gop based ratecontrol in 
> > addition to the global ratecontrol, but it would work for mpeg1/2, 
> > probably not for mpeg4/...
> 
> On the subject but possibly complete bogus, but you can never know ;-)
> 
> Someone in transcode-devel had the following idea. The noise reduction
> function may achieve a large improvement in compression ratio, although
> you obviously don't want to use it too extensive because finer details
> will get lost. The idea is to change the noise reduction strength
> dynamically, controlled by the rate control function. If the rate
> control must fall back to a significant larger q because the buffer is
> almost full, it might try again with a higher noise reduction strength,
> and hopefully achieve a better compression thus avoiding the need to use
> a (very) large q.
> 
> In the end it will come down to trading in some blockyness for less
> detail, which, it seems, is less ugly to the eye.
> 
> Just a thought ;-)

I like the idea a lot. Care to try submitting a patch to demonstrate
and see if it works well?

Rich