> Produces this (approximately 1010 frames), encoding times (real time / > user time, gives a bit of a view as to how busy the CPUs were during the > real time, optimal should be 1m realtime, 2m user time, right? and > average system time was 3.0s, with +/- 0.2s for all tests): ...
Yep. You should (in theory) get a lot closer to that with the current MPEG_DEVEL branch mpeg2enc. However, your scaling is really remarkably bad as even the -R 2 values where two CPUs should be fairly busy are unusually bad. I've never heard of worse than 70% utilisation on dual CPU machines. Here's a fairly typical snapshot of mpeg2enc -M 2 -I 1 -R 2 in action on my dual P-III machine... PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 12620 as 18 0 46464 45M 768 R 80.9 24.3 0:18 lt-mpeg2enc 12621 as 18 0 46464 45M 768 R 70.8 24.3 0:18 lt-mpeg2enc 12619 as 9 0 46464 45M 768 S 3.9 24.3 0:01 lt-mpeg2enc You're getting very very symmetrical CPU loads and very very poor utilisation. What kernel are you using... I vaugely recall 2.6.x series radically changed the threading libs. It could be something pathological is happening in the scheduling. The 2100+ is of course a lot faster than the P-III but: I doubt the balance between the motion estimation and the rest of the code is hugely shifted. Cerainly, the approximate proportions of time spent in each are quite similar on my 2100+ single-CPU machine and a P-III. > Also, encoding with one B frame is a touch faster in -I 1 mode than > encoding without them, but it is slower when you encode two B frames > instead of just one. I find this interesting.. I would have expected a > single B frame to take a bit longer than none at all, and that is the > case when -I 0 is on, but not when it's -I 1. Any ideas on that one? Not really. However: I would expect going to two B frames to greatly increase your CPU utilisation without much wall-clock time increase due the increased scope for parallel computation. > In the end -M 3 is not reasonably faster in -I 0 -R 0, but flys along at > -I 0 -R 2 compared to baseline, and gets fair gains at -I 0 -R 1, while > dropping encoding time by another 14 seconds for the same frameset. This is what you'd expect: -R 2 offers much more scope for the 3 worker threads of -M 3 to do something useful. > The numbers on -M 3 -I 1 -R 2 show a 54 second improvement over the > tests with -M 0, but it takes almost 50% longer than -M 3 -I 0 -R 1. The > file size of 3-1-2 is 13,807,067 and the file size of 3-0-1 is > 13,402,673. The file is smaller, and is encoded faster, and viewing them > now, the quality is at least on par (3-0-1 looked a tad better). The usefulness of B frames depends a *lot* on the type of material. For captured stuff they rarely buy you much apart from free room heating from your CPU. Hence the provision of -R 0 ;-). They should get a little more useful when I add dynamic frame type selection to mpeg2enc in the new year. > > - There is also a parallel read-ahead thread but this rarely soaks much > > CPU on modern CPUs. Weirdly enough on your machine the reader thread is exceedingly busy > > The MPEG_DEVEL branch encoder stripes all encoding phases to allow much > > more scalable parallelisation. You might want to give it a go - I'd be > > interested in the results! > > I'd love to, but I couldn't find it in CVS. I found everything else in > the SF CVS branch, but not mjpegtools itself. cvs co -d :ext:[EMAIL PROTECTED]:/cvsroot/mjpeg mjpeg_play cd mjpeg_play cvs update -r MPEG_DEVEL mpeg2enc The 'mjpeg_play' is a bit of a historical oddity but it is momumentally painful to change directory names in CVS... Andrew ------------------------------------------------------- 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
