[MPlayer-users] mjpeg and mencoder

[Brad Barnett]

On Tue, 7 Jan 2003 18:42:22 -0500
D Richard Felker III <dalias at aerifal.cx> wrote:

> [Automatic answer: RTFM (read DOCS, FAQ), also read
> DOCS/bugreports.html] On Tue, Jan 07, 2003 at 06:29:10PM -0500, Brad
> Barnett wrote:
> > [Automatic answer: RTFM (read DOCS, FAQ), also read
> > DOCS/bugreports.html] On Wed, 8 Jan 2003 00:15:09 +0100
> > Arpi <arpi at thot.banki.hu> wrote:
> > 
> > > [Automatic answer: RTFM (read DOCS, FAQ), also read
> > > DOCS/bugreports.html] Hi,
> > > 
> > > > I've been looking for a way to control the quality of mjpeg lavc
> > > > encoding with mencoder.  So far, the vbitrate option doesn't seem
> > > > to make any significant difference.  If I set it to 600 or to
> > > > 10000, I'm just as likely to get the same size file out, and the
> > > > same image quality.
> > > 
> > > hmm. vbitrate should work. anyway you won't get any enjoyable
> > > quality under 8000...  even mpeg2 requires at least 8000 for good
> > > quality at 720x576
> > > 
> > > also you can try vqscale=[1..31] for constant quality (but variable
> > > bitrate)
> > 
> > 
> > Cool.  I'm trying to basically get as close to lossless compression as
> > I can.  I can't do rawrgb, it's just too large.  However, why does
> > something like:
> > 
> > /usr/bin/mencoder -tv
> > on:driver=v4l:width=640:height=480:input=1:norm=ntsc-ovc lavc
> > -lavcopts vcodec=mjpeg:vhq:vqscale=1  -oac mp3lame -lameopts
> > cbr:br=192 -o /mnt/c/test.avi -endpos 60
> > 
> > use more cpu than something like:
> > 
> > /usr/bin/mencoder -tv
> > on:driver=v4l:width=640:height=480:input=1:norm=ntsc-ovc lavc
> > -lavcopts vcodec=mjpeg:vhq:vqscale=2  -oac mp3lame -lameopts
> > cbr:br=192 -o /mnt/c/test.avi -endpos 60
> > 
> > Shouldn't it be the other way around?!  After all, I'm doing less
> > compression with vqscale=1 than vqscale=2.  Also, what's the best
> > method for deinterlacing?  I've tried lavcdeint, but it seems to add
> > artifacts...
> 
> AFAIK qscale should not affect performance much either way... Perhaps
> it's just the increase in disk io loading down the cpu. You might also
> try something like
> 

I don't think it's the disk io causing that increase in cpu usage.  I have
a dual PIII box, and the SMP should be sharing that disk io load onto the
other CPU.

> -lavcopts vcodec=mpeg4:vme=0:vqscale=1
> 
> That should get about the same quality, using a good bit less disk
> space but slightly more cpu time. You can also add keyint=0 for
> intra-only encoding, that'll speed it up a bit at the cost of less
> compression.
> 
> Rich
> 

Unfortunately, it uses almost double the cpu :(  Way beyond my limit.