On Mon, 15 Dec 2003, Slepp Lukwai wrote:
> faster to begin with. However, in both cases, after multiple tests and
> trying different things, I can't get the SMP modes to be fast at all. In
> fact, they're slower than the non-SMP modes.
I think I see what you're doing that could cause that. I've never
seen the problem - using "-M 2" is not going to be 2x as fast though
if that was the expectation. ~40% speedup or so is what I see
(from about 10fps to 14fps) typically.
> When encoding with the -M 0 with .92, I get around 19fps. When I use -M
That's full sized (720x480) is it? Sounds more like a SVCD
or perhaps "1/2 D1" (bit of a misnomer - D1 is actually a digital
video tape deck) at 352x480. At 1/2 size yes, around 20fps or a bit
more I've seen. But I'm usually tossing in a bit of filtering so
the process is a slower.
> I installed 'buffer', set it up with a 32MB buffer and put it in the
10MB is about all I use - it's just a cushion to prevent the encoder
from having to wait (-M 1 is the default - there's I/O readahead
going on) for input.
> Has anyone found a way around this, or is it time to look at the source
> and see what's up?
> And for reference, it's a dual Athlon MP 2100+, which is below the
> '2600' that the Howto references as fast.
I'm using dual 2800s and around 14-15fps for DVD encoding is what I
usually get.
> The actual command line is:
> mpeg2enc -v 0 -I 0 -f 8 -b 9800 -F 1 -n n -p -a 3 -o test.m2v -S 9999 -M
> 3 -4 2 -2 1 -r 32 -q 5 -Q 3.0 -K kvcd
You have progressive non-interlaced source? If not then "-I 0" is
not the right option.
The speed up from multiple processors comes, I believe (but if I'm
wrong I'm sure someone will tactfully point that out ;)) the speedup
comes from the motion estimation of the 2 fields/frame being done in
parallel.
Try "-I 1" (or just leave out the '-I" and let it default.
Oh, and there's no real benefit from going above -M 2. I had a 4
cpu box and tried "-M 4" and saw no gain over -M 3 (which in turn
was a very minimal increase over -M 2).
If you want to speed things up by a good percentage try encoding
without B frames. Those are computationally a lot more expensive
than I or P frames. "-R 0" will disable B frames.
And do you realize that increasing the search radius (-r) slows
things down? Leave the -r value defaulted to 16 and you should
see encoding speed up.
All in all - the defaults are fairly sane so if you're not certain
about an option, well, let it default.
And drop the -Q unless you want artifacting - especially values over 2.
Under some conditions (it's partly material dependent) the -Q can
generate really obnoxious color blocks and similar artifacts. Much
better results (especially with clean source material) can be obtained
with "-E -8" or perhaps "-E -10".
> Of course the -M 3 changes to 2 and 0 in testing. I also tested it with
> and without the buffer program in the list. Another notable thing, is
> that with the newest version .92, -M3 causes three 33% usage processes
Right, with -I 0 the cpus take turns but there's little parallelism.
> to exist (leaving an entire CPU idle), while M2 causes two 60% processes
> to exist. With .90, -Mx causes 2 50-70% processes and the rest never do
Hmmm, I see 100% use on the two 2800s - but some of that would be
the DV decoding and pipe overhead of course.
First thing I'd try is lowering -r to 24 at most or just defaulting it.
Cheers,
Steven Schultz
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
