Video Encoding

Since MPlayer (MEncoder) do not come with RPMs, we compile the binaries from source with no optimizations. We go through the standard ./configure and make commands for the v1.0pre5 source code. Notice that this benchmark has changed since the last time we ran it.

Below is the command that we used to produce a DivX .avi from a 700MB MPEG2.

time mencoder sample.mpg - nosound - ovc lavc vcodec=mpeg4:vpass=2 - o sample.avi

Frames per Second, more are better. Frames per second are not calculated in the program, but taken by dividing the number of frames in the file by the time reported in the console.

MEncoder 3.3.1

Generally, our tolerance for this benchmark was about 1%.

Audio Encoding

Lame was compiled from source without optimizations. We only ran ./configure and make without any flags.

We ran lame on a 700MB .wav file using the command equivalent to the one below:

lame sample.wav -b 192 -m s -h >/dev/null

Encoding time, lower is better.

lame 3.96

Lame shows us that from platform to platform, there is not a significant difference between VIA or NVIDIA. Our tolerance for this test was less than 1% and was extremely replicable.

Index Rendering Tests
Comments Locked

24 Comments

View All Comments

  • MNKyDeth - Monday, July 19, 2004 - link

    10 - Posted on Jul 19, 2004 at 1:23 PM by tfranzese
    "hardcore linux gamer", I'm sad for you. ;)

    Yeah, well, some of us would rather play the games linux has and not have to worry about a blue screen while we play. I won't use wine or wineX either, unless it upports 90% of all windows games and works 100% all the time.
  • RyanVM - Monday, July 19, 2004 - link

    It seems to me that optimizing the binaries would certainly be useful for seeing just how good performance can be. The vast majority of Linux users will be compiling their own code anyway...
  • sprockkets - Monday, July 19, 2004 - link

    Hmmmm, although you say that you didn't optimize using flags during compile of Lame or anything else compiled, doesn't the configure script do this for you automatically, or at least, detect your processor type and compile accordingly?

    Comments on chipset support: It is nice to be able to install SuSE without a floppy, unlike EVERY version of windows out there. Did the SATA work though on the NF3? Sound would work since it's just the usual Intel 8x0 driver, right?
    VIA audio to some extent works on my motherboard with the 8237 SB, and while the codec seems fully supported, which is a SoundMAX, sound only came out once.
    I wouldn't call the fact that the kernel calls the chipset the K8T400 a necessary gotcha. One of the best things I like about linux is the fact that it refers to hardware by either it's real name or codename, unlike stupid windows which refers you your hardware from the marketed name of the product, making you think it really is something unique. For instance, SuSE 9.1 refers to the 964L SB from SIS as having a 963 ATA controller. On the outside it says 964L, but really, it probably uses the same IDE controller from before.
  • KristopherKubicki - Monday, July 19, 2004 - link

    Doom3 get a linux port but probably not right away. You all know we will have benchmarks first :)

    Kristopher
  • tfranzese - Monday, July 19, 2004 - link

    "hardcore linux gamer", I'm sad for you. ;)

    Anyway, there's no need to included UT2K3 when they've got UT2K4 to benchmark. Including Quake3 is old and tired. Is Doom3 getting a Linux port?
  • MNKyDeth - Monday, July 19, 2004 - link

    I am very glad to see linux benches from a reputable site for a change. It's just nice having some hard numbers/facts, that I can use to compare my hardware choices with. I am a hardcore linux gamer and would like to make a suggestion if possible. RTCW:ET and UT2k4 are great benches, but there are many other games you can bench with on linux like Savage and Quake3, UT2k3 and maybe even Medal of Honor:AA. It's just a suggestion to include more games if you do a vid card roundup on linux later on or even if it is just a small comparison.
  • RZaakir - Monday, July 19, 2004 - link

    Javescript links are wacky no matter how you look at it. There are myriad ways to design links to work when Javascript is disabled.

    Anyhow, I echo #5. I am very encouraged by the performance gains that we are starting to see. Around 30% on UT2004 is amazing. Hopefully Microsoft will get their act together so that we'll start seeing similar performance on Win32.
  • Jeff7181 - Monday, July 19, 2004 - link

    It's just too bad a crappy FX5600 was used for the gaming tests. Couldn't at least have dug up a FX5900?

    Oh by the way... I'm writing this using Firefox as well... maybe someone needs to learn how to use Firefox's features that make it a "web browser of choice." :)
  • srMatanza - Monday, July 19, 2004 - link

    Another awesome article in an awesome series. I think it's great that quality linux benchmarking articles are finally starting to show up in reputable forums.

    I can't wait for the linux video comparison. I think a good 64-bit distro review would also serve a purpose, especially if it focused on usability and maturity.

    Keep up the good work.
  • AlexWade - Monday, July 19, 2004 - link

    WOW! Finally, some REAL benchmarks between 32-bit and 64-bit.

    And I must say, if gains were saw across the board with non-64-bit optimized code, imagine what the jump will be with 64-bit optimized code!

Log in

Don't have an account? Sign up now