[MPlayer-dev-eng] mencoder problem

[D Richard Felker III]

On Fri, May 17, 2002 at 05:04:32PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Friday 17 May 2002 16:47, D Richard Felker III wrote:
> [...]
> > > i guess all frames are encoded with qscale=3
> >
> > It seems there are several issues at hand. AFAIK, lavc always enforces
> > the qscale min/max unless the caller has specified fixed qscale, as
> > the second pass of mencoder's external 2pass (-pass 2) does. This
> > could be a good or a bad thing, but right now, lavc's handling of this
> > situation is broken.
> >
> > For example, suppose I encode a file with lavc's internal 2pass and
> > request qmin=3, qmax=12, bitrate=1000. On the first pass, the file
> > comes out a lot smaller than it should, because lavc is "too good" and
> > doesn't need that many bits for qscale=3 in most frames. Then, when it
> > comes time for the second pass, lavc rescales the qscales to make more
> > efficient use of the available bits. BUT, when it scales down the
> > qscale for a frame below qmin, it seems to just truncate the scaledown
> > to qmin, rather than going lower, and it doesn't return the excess
> > bits gained by this truncation to be distributed over the more
> > complicated frames that could benefit from these extra bits!
> it does redistribute the bits, otherwise its a bug ...

Well then why do I have a file encoded by lavc 2pass that's 100+ megs
smaller than I requested, but not all the frames are qscale=3? It
seems something is amis. Someone familiar with lavc 2pass control
should probably check this, but I'm pretty sure there's some bug in
there...

> > At least in the meantime until lavc's 2pass code is improved to deal
> > with this situation, and perhaps in the longterm as well, it's
> > probably desirable NOT to use qmin/max in the second pass of encoding.
> > I propose the following possible solution, although I don't know if
> > it's the best or most intuitive:
> >
> > In mencoder, have the default values for vqmin/vqmax be 0, which will
> > mean initialize defaults based on pass number. For vpass 1, it would
> > just initialize them with the old defaults that exist now. For vpass
> > 2, it would initialize them to 1 and 31.
> i doubt that would be good, why dont u just set vqmin=1 vqmax=31 for both 
> pass 1 and 2 ?

I was under the impression that letting the qscale vary too widely in
pass1 would be bad for estimating relative bitrate requirements,
unless the bitrate tolerance is set really high. Right now, with
vqmin=3 on the first pass, average bitrate often stays well below the
requested bitrate on low motion scenes, leaving plenty of bits for the
high motion scenes to get at least a decent qscale later. I would
expect that if high motion scenes get *really* high qscales on the
first pass, it would be harder to estimate what qscale should be used
for them on the second pass. Of course I might just have no idea what
I'm talking about, however.

Rich