On Fri, 24 Nov 2006, Linetec wrote:
> Hmm, then how do you call it when quantization (-q) is chosen too low,
> resulting in mplex reporting buffer underrun errors?
"bit rate too high".
;)
I know I've "lectured" on this before but maybe newer/different
wording will explain the concepts better.
Think of -q as specifying the minimum amount (floor) of compression to
be applied to the video stream. This is the amount of compression
below which the encoder will never go. The encoder can (and will)
use _more_ (higher "-q" values) compression as required to keep the
bitrate close to that given with -b.
"-b N" gives the maximum bitrate. Mpeg2enc will do its best to stay
under this value (by varying the amount of compression applied to each
frame - the effective "-q") but PEAKS/SPIKES will occur periodically.
Mpeg2enc will (quickly) compensate but if the rate spike is too high
or lasts a little too long then later mplex will give an error.
At one extreme ("-q 31" is the max) amount of compression the average
bitrate will be FAR below the maximum bitrate specified by -b. Any
rate spikes that happen will be so far below the max rate that you'll
never ever see a problem. This is the maximum headroom situation -
the average rate is far below the max value allowed. The image quality
is going to be terrible but the bitrate will be very low.
At the other extreme ("-q 2" is the min) the amount of compresssion
being requested is minimal. While you can REQUEST "-q 2" (minimal
compression) that alnost certainly will conflict with the number of
bits/sec available from -b. What happens is that the encoder will be
right at the maximum value specified by "-b" with NO HEADROOM - any
peak/spike in rate will cause the rate to (possibly often) exceed
the max rate value. This is called the "mininal headroom" situation.
A 10% spike in rate if you're at '-b 9600' will quite likely result in
a out of spec stream due to the bitrate being too high.
> > I'm curious why 'yuvcorrect' is being used. DV is always bottom...
>
> Well, as I'm not too experienced yet (did I mention that already? :-), I
Yes, you mentioned it ;)
There is the possibility that the field order was set incorrectly
by Cinelerra (it's happened in the past as I recall) and that you
were correcting it after the rendering.
If the field order is correct you can save some cpu time by not
using yuvcorrect in the pipeline.
> > -M is either useless (no speed gain) or worse (subtle threading
> > race can trigger an assert() error).
>
> I'm working on an AMD64 dual-core machine, and -M 2 (actually the only
> option I came up with myself) results in an overall speed gain of up to 40%.
Almost all of that comes from '-M 1' which uses an I/O readahead thread.
That's why you won't see much (if any) improvement between -M 2 and
-M 3 (I have tested this on quad cpu systems and -M 4 actually ran
slightly slower than -M 1).
The same effect (buffering data so that the encoder does not spend
time waiting for input from the pipeline) can be achieved by using
the 'bfr' program ( ... | bfr | mpeg2enc ...).
http://www.glines.org/wiki/bfr
It's a general purpose buffering program.
Most of the time the speed of the encoder does not matter. If there are
any filters in the pipeline (color correction, noise reduction, etc)
then they are much slower than the encoder - the encoding time could
be 0 and it wouldn't have an effect on the total runtime of the
pipeline.
> ... with render pipe parameters; I'll also involve my spouse in some
> blind(!) tests -
Ah, yes find some blind people and have them judge the differences :) :)
Good Luck and Happy Encoding.
Cheers,
Steven Schultz
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
