| Front | Info | Lists | Newsfeeds | Study Guide | What is BSD? | |
|
Performance testing building DivX and MPEG-2
By Steven M. Schultz A couple weeks ago, I performed some performance testing using several different operating systems that may be of interest to those evaluating other systems for future use. The system used is a dual Athlon MP-2800 system (1GB memory, ATA100 disk drive). Removable IDE discs were used so that all testing was done using the same system and disc type. Two tests each using a different program were done. Both programs are rather compute bound with I/O mixed in (the 1.5GB of data has to come from somewhere ;)). All the software (programs and dependent libraries) was freshly "cvs update"d and configured/built before the tests were run. Basically as even a playing field as possible was set up. One program is not threaded while the other is threaded and can use multiple cpus (where the underlying OS can schedule threads across cpus).
Non-threaded testThe non-threaded case used mencoder+ffmpeg+mpeg4ip to create MPEG-4 (aka 'DivX') content from an approximately 1.5GB DV file (captured via IEEE1394 and an analog -> DV converter).
The goal was to encode:
-r--r--r-- 1 sms staff 1555440000 Sep 7 08:53 redhotridinghood.dvinto a 320x240 Quicktime/Mpeg-4 movie. Using the 2 pass encoding method of 'mencoder' with many (if not all) of the high quality settings enabled the timing results look like this (times are in 'time' format - user, system, elapsed ). The flow was (I'll omit all the options since they'd probably be meaningless at this point):
First up was BSD/OS 4.3.1 BSD/OS 4.3.1 : 1743u 48s 33:35 Not bad but how does FreeBSD do (I hear you ask)? FreeBSD 5.1 : 2185u 46s 40:18 Hmmm -- interesting. BSD/OS 5.0 : 2416u 70s 43:59 Not what was expected but moving on to the last system looked at... SuSE 8.2 : 1235u 27s 22:37 Looks like the definite winner in that round is Linux/SuSE-8.2 and by quite a margin at that. The resulting file by the way is: -rw-r--r-- 1 sms staff 35328750 Sep 14 21:56 red.mp4an average bitrate of 640 Kbits/sec (including audio) and it looks amazingly good (and Apple's Quicktime player accepts it as input which says the file is correctly formed -- MPlayer also plays it). The MPlayer folks are quite vehement about not using threads (can't blame them over much since that does introduce portability problems) so I figured the single program grinding away would produce similar results. Quite surprising to find the reverse was true.
Threaded testNext up was taking the same input file and encoding to DVD quality/size MPEG-2 using the mjpegtools and smilutils:
The encoder in this case is threaded and can take advantage of dual cpus. A buffering stage was used in from of the encoder so as to keep the encoder from waiting for data. Flow was decode the raw DV file into 4:2:0 | buffering program | encoder And it's off to the races... BSD/OS 4.3.1 : 1596u 780s 31:18 (6.90 frames/sec) Not bad I thought -- not quite up to 1/4 real time though. Next up ... FreeBSD 5.1 : 2061u 811s 32:05 (6.73 frames/sec) It's catching up to 4.3.1 but still lags behind a little. BSD/OS 5.0 : 1614u 1975s 42:06 (5.13 frames/sec) For whatever reason 5.0 spent about 50-percent of its time in kernel mode which really ate into the amount of time available for user programs. And lastly in presentation (but not in elapsed time):
SuSE 8.2 : 15383u 238s 19:30 (11.08 frames/sec)Slightly faster than 1/3 real time -- that's quite good for DVD resolution encoding. The BSD systems weren't even close in this case -- the best showing came from a BSD/OS 4.3.1 system and that was a distant second place showing. It's also evident that neither FreeBSD nor BSD/OS threads take advantage of multiple cpus. There's another thread package (not built/installed by default) for FreeBSD 5.1 which will schedule threads between cpus. That would help the 2nd (MPEG-2) encoding run faster but would not do anything for the first case which was a single non-threaded program. The goal was to run a standard out-of-the-box system not one with non-default/experimental libraries. All in all the big surprise was the gap between first place and the next system. The expectation was that on identical hardware running the same versions of the software the timings would be closer together, not identical but close. In the Linux world, video capture and processing is more or less taken for granted and is an active area of development. In the BSD world, it's the opposite -- relatively little is being done that I have seen in the area of video capture, editing and encoding. Video capture for example appears to be limited to the Hauppauge WinTV card (mediocre quality compared to a IEEE1394 analog->DV converter) and the 'fxtv' application on BSD systems (FreeBSD's bktr driver driver was ported and appeared in BSD/OS 4.2 and disappeared in 5.0). The FreeBSD 5.1 system didn't appear to have support for IEEE1394 video capture but I didn't go exploring in depth -- it might well be there (but the API would probably make it incompatible with Kino or dvgrab - http://kino.schirmacher.de). Which probably explains why it's more or less taken most of my free time to get stuff ported/built on non-Linux systems ;) Even then the capture's done using SuSE 8.2. If someone has all the bits and pieces and wants to run the tests on another system, I still have the scripts and the input data.
Steven M. Schultz has been hacking around UNIX since the 6th edition (aka V6) circa 1978/79 and running BSD/OS at home personally since it was BSD/386 at the 0.94 release. He introduced BSD/386 1.0 at work for two systems and have grown ever since. Schultz said he enjoys coercing programs into building on BSD/OS -- "keeps me off the streets at night ;)".
Do you know of any editing or capture tools that are developed on BSD systems (and not just ported to BSD)? Please share your feedback below.
RELATED INFO
DiscussionDiscuss this article below.
MPEG encoding on open source platforms - Hal Hanson
MPEG encoding on open source platforms
Cheers,
Thomas
|
BSD Links · Advocacy· Drivers · Events · Flavours · FAQs · Guides · Programming · Security · Software · User Groups |