Some real quick info. I'm running my set up on a MacBook Pro 5,5 with 2.53GHz processor 4GB, Snow Leopard, MacPorts 1.9.1, Kdenlive 0.7.8_0.
After finally getting kdenlive installed through macports I have finally been able to use it. However after loading clips and just testing out the playback on the clip and project monitor I've noticed that the audio and video are a bit choppy and my fans start roaring. I popped open Activity Manager and found that the application guilty of +170% CPU usage is kdenlive. I have Kdenlive 0.7.8_0 on my Ubuntu partition and works fine (minus having to make my background black in order to use the project monitor) and it only does that for a brief second or when I go to render a project. Does anyone have any advice, other than to use Kdenlive on my ubuntu partition, on how to fix this? Any help is appreciated.

Oh also, if this a question that is better addressed for the Macports community please let me know. I thought this would be the more appropriate one to ask first.

Please make sure the color scopes are not set to auto-refresh or that they are otherwise not visible. Recalculating them takes quite some CPU time and should only be enabled when color correcting.

Nah, MacPorts community will not be able to help out. Ditto what Granjow wrote. :-)
Also, it probably helps if your mlt was built with mmx enabled, which is only enabled on OS X 10.6 x86-64. Is your MacBook 64 bit? ffmpeg has a no_mmx variant - make sure you aren't using it. Finally, HD H.264 is going to be particularly slow especially if in a TS file such as AVCHD.

I did some testing last night on my MacBook Pro: 2.4 GHz Core 2 Duo with 4 GB RAM. I tested mainly with a H264 1080p29.97 MOV. I get about the same CPU usage as you reported, and Quicktime X gives about 95% (but fails to play the frames in correct order). Try playing the clip with ffplay. On my clip I get about 160% usage in the beginning and it smoothly ramps down to 110%. It appears choppy even though I did not use the -framedrop option. I guess it is just playing each frame slowly; it does appear to go slow the more it goes. So, I guess ffmpeg h264 decoder it not particularly fast on this platform. Then, consider MLT is nowhere near as simple as ffplay; it's support for advanced features like multitrack and automatic deintlerace, scaling, padding to support mixed media on the timeline does add considerable overhead.

Oh, one more thing when comparing performance, also check to make sure the project setting matches the clip. It would not be fair to compare a software scaler in MLT to no scaling in ffplay or the addition of a deinterlace operation in MLT because the project is progressive and the clip is interlaced.

Where do I go to change the setting of the color scope? Also yes my MacBook Pro is EIF64 reading. I'm currently using the 32bit kernel but it shows kdenlive running as a 64bit app (which is awesome).
I'm assuming I want to deactivate mlt before building that mmx variant or should I clean all my kdenlive dependencies and rebuild just to get that variant for mlt?

I currently have no need for color correction (which btw is that new in kdenlive, I haven't noticed it until this version) but what I did was go to the View menu and selected each color correction panel at a time and right clicked the window and uncheck Auto Refresh. The audio plays slightly less choppy, a noticeable improvement but only for a few seconds and the CPU usage jumps between 100 and 180 now. Also should I boot into 64bit mode, while I most likely see a noticeable difference after resolving the variant mlt build? One more thing, I went to go see if a mmx variant was available and there was only a no_x11 variant available for mlt. There is a no_mmx variant available for ffmpeg however.

Can anyone explain why i don't have the option to build mlt with the mmx variant?

there is no mmx variant for mlt. If you are running arch x86-64 on OS X 10.6 then mmx is enabled, otherwise not. It sounds like you are already 64 bit and have mmx. I gave info about my tests for your comparison. Did you compare with ffplay? Basically, it is what it is, and on OS X it is not great. We were just happy to get it going on there.

I tried to see if I could use ffplay and Finder shows a unix executable file but I'm not quite sure how to test my video out. i tried man ffplay and it doesn't list an option to just play/display my selected video input. Do you happen to know what you have to use in the Terminal to play videos or is there a GUI alternative maybe?
The original settings I had at the time of the initial post for my rendering output was 720HD avi and I experimented and no matter the quality and format I choose I still get slow, choppy playback and excessive use of the processors.
I'm definitely pretty impressed on being able to use this BSD port, I'm just sorta bummed because I've seen videos of a mac user using a slightly older version of kdenlive with what seemed to be no issues and the video is over a year old. I'm looking forward to it becoming fully functional since the new macbook pro track pads are hard to click-and-drag within linux.

ffplay usage is just, in a terminal window: ffplay thefile

Do not try to resize its window. When you are done viewing, press 'q'.

It plays amazingly well on ffplay, barely any ram is used and the CPU usage never goes above 20% which is roughly what kdenlive in ubuntu uses when I do just regular playback.

I'm starting to think that it has something to do with color correction plug-ins like Granjaw suggested, the color of the video seems a bit more saturated in kdenlive than when i view the clip on ffplay or VLC. Is there anyway I can turn them off other than choosing them under the View menu and then right clicking it and unchecking Auto-render?

The color scopes only render if

• at least one of them is visible (i.e. not hidden by another widget) AND


• auto-refresh (right-click) is enabled in at least one visible scope.

If this is not the case, then they should not affect the performance.

An interesting development! I went through and unchecked a number of things for the color scope, dropped the frame rate from 60 to 30 and didn't switch over to activity monitor to view the CPU usage. If I don't use mutlitouch mouse gestures the audio plays flawlessly. The CPU usage is still at 150% but the fans don't come on. So i guess when I was using four finger gestures to activate Expose so that I could switch to Expose that is what caused the chopping in the audio because even if I do two finger scrolling it causes the audio to be choppy slightly. I also tested out and rendered the file to a different format then it started off on and it plays on ffplay/VLC flawlessly so I suppose this isn't much of any issue anymore. I appreciate the help and cheers to the bug repairing and development of kdenlive. Kdenlive is functional enough for me to use on OSX now.