[MPlayer-cvslog] CVS: main/libmpcodecs ve_lavc.c,1.111,1.112

D Richard Felker III dalias at aerifal.cx
Wed Mar 2 22:54:30 CET 2005


On Wed, Mar 02, 2005 at 10:28:34PM +0100, Guillaume Poirier wrote:
> Hi,
> 
> On Wed, 2 Mar 2005 15:08:45 -0500, D Richard Felker III
> <dalias at aerifal.cx> wrote:
> > On Wed, Mar 02, 2005 at 08:28:45PM +0100, Guillaume Poirier CVS wrote:
> > > CVS change done by Guillaume Poirier CVS
> > >
> > > Update of /cvsroot/mplayer/main/libmpcodecs
> > > In directory mail:/var2/tmp/cvs-serv21224/libmpcodecs
> > >
> > > Modified Files:
> > >       ve_lavc.c
> > > Log Message:
> > > 35% faster turbo mode with 0.01dB drop. Based Loren Merritt's suggestions.
> > > Next step would be to make turbo mode accept a "quality" argument to control the
> > > speed vs quality tradeoff.
> > 
> > If you're experimenting with this, could you see what happens if you
> > encode pass1 by scaling way down (e.g. 1/2 width and height) with
> > vf_scale, and then encode pass2 at full size? i.e. does the psnr
> > significantly drop? It might be necessary to do some renormalization
> > of the data in the log file for such a hack to work, but I suspect if
> > done correctly it might, and of course it would make another 50%
> > speedup or something...
> 
> That's a nice idea that you've got here... Well, I'd say that my
> understanding of MPlayer's code makes me wonder how it might be
> possible to scale down the video with parameters given in ve_lavc, but
> I have to admit the idea is appealing...

It can't be done in ve_lavc, but it could be done separately by users.
If renormalization is needed, a feature to do it automatically could
be put in ve_lavc or lavc itself.

> As far as the renormalization is concerned, I guess a constant-quant
> (like vqscale=2) encode for the first pass could do the trick,
> couldn't it?

No. The problem, if anything, is that the numbers of bits needed will
be scaled down to on the first pass, and this might lead to
excessively low quantizers being chosen on the second hires pass.

> Well, reading x264's section of the manpages, it kind of states that
> should a first pass be done with constant quants, it's better if the
> constant quant used is close to average quants in the resulting video,
> so I don't know what I should do...

For lavc it's recommended not to use constant quant.

Rich




More information about the MPlayer-cvslog mailing list