Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
HandBrake's High Profile preset enables 2 poorly-threaded filters (decomb, and more importantly detelecine) by default.

Ah, I didn't realize that. So if the filters in play are poorly-threaded, does that mean hyperthreading is having more of an effect vs. if they were turned off and the main encoding process occupied more of the cycles? I was under the impression that if there were no decombing or detelcining needed, the filters would detect this and turn off. That said, if I find myself in an Apple Store with an i7 machine, I'll turn off the decomb and detelecine and see if it makes any difference.

Edit: Also, DV at 60 fps? Are you sure it's not 480i60 (60 fields per second)? That's likely causing some more time spent in the filters vs. actually encoding in x264.

It's 480p60. The original source was indeed 480i60, but I deinterlaced it beforehand with JES Deinterlacer to make it 60 full frames per second. For the source footage I'm working with (video games with a lot of rapid movement), it makes a big difference in quality.
 
Ah, I didn't realize that. So if the filters in play are poorly-threaded, does that mean hyperthreading is having more of an effect vs. if they were turned off and the main encoding process occupied more of the cycles?

The opposite - the filters could be a bottleneck of sorts. Other HandBrake benchmarks I've seen show a 30% advantage to the 2.8 i7 compared to a 2.66 i5. I would still expect a 20-25% advantage for the i7 vs. the new i5.

Note that I asked the developer who integrated the filter to HB and it turns out the detelecine filter is not threaded at all.

Edit: well, I can't find the benchmark where the i7 is 30% faster than the i5, but I found two PC-based benchmarks:

http://www.bit-tech.net/hardware/cpus/2009/09/08/intel-core-i5-and-i7-lynnfield-cpu-review/5

http://www.guru3d.com/article/core-i5-750-core-i7-860-870-processor-review-test/14

Both using HandBrake for Windows, i7-860 is 20% and 26% faster than i5-750. Even adjusting for the 2010 imac i5's 5% higher clock and faster 1333 MHz memory (let's say it's 10% faster), the 2009 i7 should still be 9-14% faster.

All the non-GUI code is the same on both platforms, so relative speed should be the same under OS X.

I was under the impression that if there were no decombing or detelcining needed, the filters would detect this and turn off.

The only reliable way to detect interlacing and hard telecine is to analyze the source - the filters can't just "turn off". Of course, encoding a progressive source will still be much faster (than encoding interlaced or telecined content) since the filters don't need to perform any actual filtering.

It's 480p60. The original source was indeed 480i60, but I deinterlaced it beforehand with JES Deinterlacer to make it 60 full frames per second. For the source footage I'm working with (video games with a lot of rapid movement), it makes a big difference in quality.

I see. I'm not familiar with capturing video games, but it sounds like you should switch to something that captures progressive content. BTW, the HandBrake nightly builds can now re-encode Fraps (there was a bug in 0.9.4 and earlier that prevented this).
 
Thanks Will for this info :)

The opposite - the filters could be a bottleneck of sorts.

I agree that the filters here are likely posing a bottleneck, though I'm still a bit confused as to why this would make the benchmark I ran seem less impressive than the stats you referenced. Isn't it this type of bottleneck where hyperthreading is supposed to excel? I'm envisioning the detelecine filter sitting in one core, but not maxing it out... wouldn't it be an advantage in this case for the i7 to have another thread (something related to the actual x264 encoding perhaps?) right there in the core ready to utilize what the detelecine thread doesn't? I'm probably just conceptualizing it improperly, so if you're able to explain it better, that would help alleviate this confusion.

I don't doubt the benchmarks you posted; it certainly seems like hyperthreading can offer some tangible benefits in some situations. I'm just not sure what those situations are specifically. That said, if the decomb/telecine filters are indeed causing a bottleneck that reduces the i7 performance gains, wouldn't it be safe to say though that people will be running these filters more often than not (encoding DVDs of film/animation)? I'm not sure what the source files were for those other benchmarks (I did notice they were HD, though I'm not sure if that matters).

The only reliable way to detect interlacing and hard telecine is to analyze the source - the filters can't just "turn off". Of course, encoding a progressive source will still be much faster (than encoding interlaced or telecined content) since the filters don't need to perform any actual filtering.

Good to know. I must have misread something from the HB devs a while ago... I thought they had said to just leave it at the default setting, but from now on I will explicitly turn them off when not required and see what happens.

I see. I'm not familiar with capturing video games, but it sounds like you should switch to something that captures progressive content. BTW, the HandBrake nightly builds can now re-encode Fraps (there was a bug in 0.9.4 and earlier that prevented this).

Ideally I should be capturing in progressive, but it would require getting more expensive equipment. I'm capturing SD footage from consoles (Wii/Gamecube mostly), so at the moment it's easy to just use a 15-year old VCR to split the composite stream into a firewire DV bridge :cool:.
 
hey if someone gets a hold of a dual 3.6 i5 then can they please gets some benchs up on here cuz i lust for extremely high clocks.
 
hey if someone gets a hold of a dual 3.6 i5 then can they please gets some benchs up on here cuz i lust for extremely high clocks against the dual 3.2 i3
 
Bit late to bring this thrad to life again, but the 3.6 ghz i5 has hyper threading and NO turbo boost. the 2.8ghz quad core i5 has NO hyper threading but has turbo boost to 3.33 ghz. So the 3.6 ghz has 4 virtual cores while the 2.8 has 4 physical cores. these 4 physical cores when all 4 are used run at 2.8 ghz. In comparison the 3.6ghz i5 when all 4 virtual cores are being used still is running at 3.6 ghz. wouldnt it make sense if the 3.6ghz is techincally as quick or quicker for day to day use?. i mean come on, its clocked 800 mhz higher. Can 2 more physical cores at 800mhz less really be that much more powerful than 2 more virtual cores???
 
Bit late to bring this thrad to life again, but the 3.6 ghz i5 has hyper threading and NO turbo boost. the 2.8ghz quad core i5 has NO hyper threading but has turbo boost to 3.33 ghz. So the 3.6 ghz has 4 virtual cores while the 2.8 has 4 physical cores. these 4 physical cores when all 4 are used run at 2.8 ghz. In comparison the 3.6ghz i5 when all 4 virtual cores are being used still is running at 3.6 ghz. wouldnt it make sense if the 3.6ghz is techincally as quick or quicker for day to day use?. i mean come on, its clocked 800 mhz higher. Can 2 more physical cores at 800mhz less really be that much more powerful than 2 more virtual cores???
All Core i5 processors have Turbo Boost. ;)
 
ah ok, my bad, true, apple website is misleading :p

still its a 800mhz difference at base clocks if system is used 100%. for the standard user woudlnt the 3.6 be of much greater performance than the 2.8. tasks where all 4 virtual cores are used, woudlnt hey be completed faster with 3.6ghz incomparison to 2.8 ghz with 4 physical cores

Also single threaded tasks would definetly be completed much quicker on the 3.6 right?? (3.86ghz turbo vs 3.33ghz turbo = 530mhz quicker)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.