• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

"Poor" encoding performance of the i5 2500k under Linux

J

justinmiller61

Junior Member
I'm running Ubuntu 11.04 (Natty), with an i5 2500k (not overclocked) and a z68 board.

I'm trying to encode DVD quality VOB files to the iPhone preset in Handbrake, but in mkv format. I'm currently getting about 105 fps average and it takes me somewhere between 15 and 20 minutes to complete. This definitely isn't bad performance, but based on these reviews and benchmarks:

http://www.servethehome.com/intel-core-i5-2500k-review-sandy-bridge-home-server/

http://www.legitreviews.com/article/1501/14/

I should be getting twice what I see. I tried duplicating their tests as closely as possible, the only exception may be that they're using Windows and I'm using Linux.

Both reviews are using Handbrake for their tests, as am I. Because Handbrake doesn't support QuickSync/GPU encoding, it's of no consequence that there is no QuickSync support in Linux.

Can anyone think of reasons why I'm see "degraded" performance?

Thanks, Justin
 
ICC shouldn't make much of a difference

Q7: I've heard the Intel compiler (ICL) produces faster binaries than GCC, why don't you use it for your builds?
A: The ICL would be faster only if the DSP routines (the ones that eat CPU cycles) weren't written in assembly language. So compiling x264 with ICL wouldn't produce any noticeably faster x264 binaries. Also ICL for windows is payware.
Click to expand...

http://forum.doom9.org/showthread.php?p=696689#post696689
 
Perhaps you should re-check your operating system (re-compile?). Its possible Turbo modes didn't kick in (under your current Linux build). :hmm:
 
justinmiller61 said:
I'm running Ubuntu 11.04 (Natty), with an i5 2500k (not overclocked) and a z68 board.

I'm trying to encode DVD quality VOB files to the iPhone preset in Handbrake, but in mkv format. I'm currently getting about 105 fps average and it takes me somewhere between 15 and 20 minutes to complete.

I should be getting twice what I see. I tried duplicating their tests as closely as possible, the only exception may be that they're using Windows and I'm using Linux.
Click to expand...

x264 should actually be faster on linux than it is on windows. There are a couple things that could be slowing you down:

1.) You're using different and slower encoding settings than whatever they used to test it with. The rule generally is use the slowest preset that you can handle (at least from a command line point of view, I have no idea what options handbrake presents to the user).

2.) Source decoding is the bottleneck. Since your source is a mpeg2 dvd, I really doubt that it's the problem, but you can play around with feeding x264 a different kind of source (some random h264 mkv or something maybe?) to see if there's any speed difference.

3.) Their x264 build is old/retarded (e.g. gentoo disables the hand written assembly because they're retarded but I guess that's to be expected from them (e.g. fPIC on x86)).

x264 isn't hard to use from the command line so you should take a look at it (it's the best way to use it). Also you should definitely look to building it yourself if you haven't already. I don't know what version of x264 handbrake uses or if it's kept up to date. I also highly doubt that the version that comes with ubuntu is kept up to date either. I've never used handbrake so I can't really comment at all on it specifically.

Check CPU usage and speed, see what's going on there and make sure it's actually eating up all the cores/logical threads.

justinmiller61 said:
Because Handbrake doesn't support QuickSync/GPU encoding, it's of no consequence that there is no QuickSync support in Linux.
Click to expand...

I'm not sure why anyone would want to use quicksync or any hardware encoding for that matter, it all pretty much sucks.

jhu said:
Try recompiling with icc.
Click to expand...

Well at least on linux it might actually be faster than gcc (it actually can do 16 byte stack alignment) but it wouldn't account for such a large difference in speed. On Windows with ICL too much stuff is disabled because it requires 16 byte stack alignment which ICL can't do so the benefits of using ICL go away. But even on linux the speed difference probably isn't that great. x264 has a bunch of hand written assembly so the compiler you use doesn't have a big effect on the final speed of the resulting binary (probably no more than a few % at best).

jhu said:
Handbrake of course. Recompiling the kernel won't do much.
Click to expand...

Recompiling the kernel with icc might actually net a larger speedup than recompiling x264 with it (disclaimer: I have no idea what I'm talking about here).
 
Last edited:
TheRyuu said:
x264 should actually be faster on linux than it is on windows. There are a couple things that could be slowing you down:

1.) You're using different and slower encoding settings than whatever they used to test it with. The rule generally is use the slowest preset that you can handle (at least from a command line point of view, I have no idea what options handbrake presents to the user).
Click to expand...

The tests said that they used the iPhone preset in handbrake, which is what I used. It's possible that they tweaked the settings further and dropped the quality.

2.) Source decoding is the bottleneck. Since your source is a mpeg2 dvd, I really doubt that it's the problem, but you can play around with feeding x264 a different kind of source (some random h264 mkv or something maybe?) to see if there's any speed difference.
Click to expand...

Yeah, I've done that. There is definitely a speed difference when I feed it an h.264 source, but that's to be expected. Those results don't help me too much because I have no basis for comparison.

3.) Their x264 build is old/retarded (e.g. gentoo disables the hand written assembly because they're retarded but I guess that's to be expected from them (e.g. fPIC on x86)).

x264 isn't hard to use from the command line so you should take a look at it (it's the best way to use it). Also you should definitely look to building it yourself if you haven't already. I don't know what version of x264 handbrake uses or if it's kept up to date. I also highly doubt that the version that comes with ubuntu is kept up to date either. I've never used handbrake so I can't really comment at all on it specifically.
Click to expand...

Interesting. I'll have to compile from source when I get home and try that out.

Check CPU usage and speed, see what's going on there and make sure it's actually eating up all the cores/logical threads.
Click to expand...

All 4 cores are definitely engaged and working at 90%+. I've also checked their clock speed with a quick cat /proc/cpuinfo (I think that was the file) and it appears turbo mode is working -- they're all generally clocked at around 3.6GHz. Note: when I try and run i7z while I'm encoding, it reads "Garbage Values" for all four cores. When I stop encoding, I get normal values. Don't understand that one. Is there a better way to check the clock speed, or is /proc/cpuinfo accurate enough?

Is it possible that my disk speed could be a factor? I'm using a 7200 rpm SATA 6Gb/s mechanical drive. In their tests, they were using SSDs. If this is the case, I don't know that I feel like spending the money on an SSD, even a small one. Would I get better speeds if I used a striped raid array of 3 drives? Are there any benchmarks for video encoding to/from an SSD vs. a magnetic drive?

Thanks,
Justin
 
justinmiller61 said:
All 4 cores are definitely engaged and working at 90%+.
Is it possible that my disk speed could be a factor? I'm using a 7200 rpm SATA 6Gb/s mechanical drive. In their tests, they were using SSDs.
Click to expand...
If there weren't any cores pinned at 100%, then yes, I would say that disk speed could be your issue.
 
I remember being I/O-limited using DVDshrink on a high-clocked dual-core C2D chip, trying to encode two DVDs at once. That might have just been due to HD contention, I guess.
 
VirtualLarry said:
I remember being I/O-limited using DVDshrink on a high-clocked dual-core C2D chip, trying to encode two DVDs at once. That might have just been due to HD contention, I guess.
Click to expand...

DVDShrink would have been doing mpeg2 encoding which should be even faster than what we're talking about in this thread (I don't remember dvdshrink having a very good mpeg2 encoder so it was probably shit but fast). And since you're doing 2 at once I'm not really surprised at the i/o limitation.
 
Last edited:
So I didn't realize that x264 was the same encoder that the 'x264 HD Benchmarks*' were using. I downloaded that test suite, which is windows-only, and converted their .bat file to a bash script.

It fails to run though because it says that x264 was compiled w/o AVS support. I believe that means avisynth? I tried to get avisynth to compile last night, but it was a major PITA. The website has some binaries which I'll try and download tonight and then retry my test.

If I can get this working, the good thing is that the test suite comes with sample input. So I should be able to compare my numbers directly to the tests. The only difference will be OS and the disk.

While I'm doing all that, are there any other things I can check? BIOS settings, OS settings, etc.?

Justin
 
justinmiller61 said:
So I didn't realize that x264 was the same encoder that the 'x264 HD Benchmarks*' were using. I downloaded that test suite, which is windows-only, and converted their .bat file to a bash script.

It fails to run though because it says that x264 was compiled w/o AVS support. I believe that means avisynth? I tried to get avisynth to compile last night, but it was a major PITA. The website has some binaries which I'll try and download tonight and then retry my test.

If I can get this working, the good thing is that the test suite comes with sample input. So I should be able to compare my numbers directly to the tests. The only difference will be OS and the disk.

While I'm doing all that, are there any other things I can check? BIOS settings, OS settings, etc.?

Justin
Click to expand...

You don't need avisynth to compile it with avisynth support. It comes with everything needed to compile with avisynth support and is enabled by default on windows.
 
It was definitely AVS.

I'm just trying to get results that I can compare to benchmarks that are out there. This is driving me a little nuts.
 
Ok, so it looks like I am getting the proper performance.

I finally got the x264 Benchmark suite to work under Linux. I'll post a follow up with how I finally did it because it was a pain and hopefully it'll help others.

I'm now getting the same numbers that the anandtech review got: ~100 fps on the first pass and about ~30 fps on the second pass.

Thanks all for the help.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top