Recent slowdown in encode FPS

HandBrake for Mac support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Post Reply
snizzzake01
Posts: 2
Joined: Tue Nov 17, 2009 3:58 am

Recent slowdown in encode FPS

Post by snizzzake01 »

I'm running on a first-gen Macbook CoreDuo 2.0 GHz, 2GB ram, 10.6.2...

I've been getting encode speeds of around 50 fps until a couple of days ago, when it dropped to about 15-20 fps. Using the Normal presest, x264 and m4v extension. Tried reinstalling HandBrake, compiling from latest SVN, did a clean install on my system.. nothing has helped. CPU is showing ~50% to 80% processor use, but I hadn't paid attention before.

Any ideas? Anyone else have this problem? From what I've read, 20 fps is about normal for my unit, but I'm not sure why I would have been getting higher rates before.
TedJ
Veteran User
Posts: 5388
Joined: Wed Feb 20, 2008 11:25 pm

Re: Recent slowdown in encode FPS

Post by TedJ »

It's hard to be certain without an activity log, but the only two things I can think of that would have that large an effect on encoding speed are either switching from ffmpeg to x264 encoding, or you're now using filters you weren't previously.

While the core encoders are multi-core optimised, many of the filters are not as yet.
snizzzake01
Posts: 2
Joined: Tue Nov 17, 2009 3:58 am

Re: Recent slowdown in encode FPS

Post by snizzzake01 »

I've always used the x264 and haven't changed any settings or filters since I started using HandBrake.. its just very strange. Guess I'll just do the encodes overnight from now on.
tlindgren
Bright Spark User
Posts: 260
Joined: Sun May 03, 2009 2:14 pm

Re: Recent slowdown in encode FPS

Post by tlindgren »

snizzzake01 wrote:I've been getting encode speeds of around 50 fps until a couple of days ago, when it dropped to about 15-20 fps. Using the Normal presest, x264 and m4v extension. Tried reinstalling HandBrake, compiling from latest SVN, did a clean install on my system.. nothing has helped. CPU is showing ~50% to 80% processor use, but I hadn't paid attention before.
I think I saw someone who saw a noticeable speed decrease from the new weightp code, introduced in SVN2922, but nowhere near as big as you describe. But it's worth trying with forcing weightp=0 (disables most but not all of it) and then a build before 2922 just to diagnose if this is the cause. I suspect there's some other setting you've changed such as subme, merange or search algorithm, could be that the x264 built-in defaults has changed (didn't see it in the change log but I only skimmed it).

weightp looks really promising but I'm a bit surprised they enabled it by default, both x264 and Handbrake developers, but it's just in SVN and may have stabilized before a snapshot or release is done. The reason is that it seems they're patching bugs in it all the time at the moment so personally I'd probably leave it off for a little while until it's stabilized a bit more. However, even with weightp disabled it still runs the new fade detection code which improves fades.

I'd recommend trying the 2907 snapshot, IF it's a lot faster it's time to provide compare encode logs from different versions (also remember that the compiler used to build it with CAN matter, so that also has to be explored). If it's not much faster, either something in the machine/OS has changed, you've changed some settings or ???...
rhester
Veteran User
Posts: 2888
Joined: Tue Apr 18, 2006 10:24 pm

Re: Recent slowdown in encode FPS

Post by rhester »

I think the main reason it was mainlined was to expose issues with decoders so they can be addressed quickly - there's nothing like a thousand users with pitchforks to get a company's attention. :)

Rodney
jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: Recent slowdown in encode FPS

Post by jbrjake »

Indeed -- I've seen D_S on IRC practically cackling with glee over forcing the hands of the decoder writers.

As far as leaving it on in HB -- we talked it over and decided that since the damage is mostly just limited to the ATV (as far as HB's userbase is concerned) it's not a big deal. It will just be disabled for that preset.
Post Reply