[Ffmpeg-devel-old] Re: [Ffmpeg-devel] Some tweaks to better respect max bitrate
Sun Dec 25 17:03:08 CET 2005
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
> 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 ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2771 bytes
Desc: not available
More information about the ffmpeg-devel