On Mon, 2003-12-15 at 20:27, Steven M. Schultz wrote: > 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.
Tried it without any options, same effect. I'm definitely seeing nowhere near 40% speedup, which is what boggles me. I expected at least reasonable gains of 25%. > > 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. Sorry, upon further testing, I actually average around 14fps at DVD quality (720x480, 9800kbit/s). (see all the details of my command lines in the post I sent in responce to Bernhard). > > 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. Yeh, I tried 20 first, then 32, but in the end, it made no difference at all. > > 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. It's interesting that I'm faster with dual 2100s than the dual 2800 (or at least on par). I suppose it really comes down to command line options, but you would need to compare those yourself (since I haven't seen yours). > > 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. According to the docs -I 1 turns on interlacing support, and causes un-needed overhead if it is known progressive material. Hence the -I 0 (plus transcode sets that, though I could override it). > 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. Oh. Son of a... If that's all it is... > 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). I've never even bothered with -M 4 (well, not for a real run, anyway, just as a quick test). > 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. I just enabled that, and that's how I'm hitting 15fps instead of 8, and the quality is good and the size is just fine. > 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. Yup, entirely aware. I do like the minor difference it makes, though. I'm not in it for speed, really, I just want to see both CPUs get used to their potentials and give me the equivalent of a 4200+ ;> If it takes 6 hours to transcode a movie because I set -r32 (I noticed a larger difference with -4 -2 options, btw, than -r16 vs -r32), that's fine, but I feel it could be faster. > 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". Until I upgraded to .92, I didn't have those options. I'm using them now, in combination with -Q, but I find the artifacts are almost never there (I used to do -q 4 and -Q 4.0, and it looked about the same as the 5/3.0). > > 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. And again, son of.... I didn't realize the parallelization was done based on interlacing settings. > > 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. The MPEG decoding doesn't take much, and the pipe overhead is negligble, but I never hit 100%. Graphically, using the little CPU monitor in X, when using -M 0, -M 1, -M 2 and -M 3, they all look the same on the chart. They are all sitting at the same total CPU usage (80%). > First thing I'd try is lowering -r to 24 at most or just defaulting it. Again, speed isn't the problem overall, just the dual speed is the problem. However, if search radius has to do with it's ability to run in parallel, then it's definitely a consideration. (As I write this, I'm still waiting for the -M 2 run to finish, so it'll arrive before the tests results to Bernhard make it out). ------------------------------------------------------- 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
