Export Times horrendous with repeat crashes

Damn. I knew it was too good to be true. When the first version of FCPX came about I was looking at overnight rendering/exports for 15 minute clips and it seems that it's back. AGAIN. To be fair, rendering in the timeline is quicker but on Share_Export Master (i.e. no effin' changes), it's ridiculously slow and crashes. I'm trying to export via compressor at the moment and it's telling me over four hours for a clip that's already rendered on the timeline. I've closed both FCPX and compressor and have nothing else running but the share monitor.

This SUCKS.

Sequence is about 18 minutes long, completely rendered on timeline - this would have been pretty much realtime in .5

The first 5 minutes or so is motion graphics templates but, like I said, these have been rendered already.

Suggestions greatly appreciated.

I'm on a 2010 iMac 3.06 Core 2 Duo, 12GB RAM with 10.0.6 and 10.8.2

I always export as a movie file and then bring that clip into Compressor. Going via Compressor has never worked for me.

Agreed, always export self contained quicktime movies from FCP (6/7/X) and then compress them.

And if you are making h264 files, use Handbrake, avoid compressor.

I tried that - it's what I would normally do - with no compression, just as a master QT. It's taking forever to export the movie (even though it's rendered) and then crashing anyway. I'm hoping compressor doesn't crash or I don't know what I'm going to do. It's now saying 3:30 hours for an HD ProRes, exactly the same as the timeline codec.

I've deleted prefs with Preference Manager, disk utilitied and rebooted. Footage is on external firewire 800 and that's what I'm exporting back to. That's not been a problem before, anyway.

That doesn't sound right at all. I've created hour-long pieces with pictures/music, etc. Not very complex stuff, but complex enough. It takes a while to export & then to compress, but never more than 20-30 minutes. Maybe extensive Motion work would cause this, but I don't do a lot of work in Motion. It strikes me as unlikely. I'm not sure if this is helpful advice though.

Just finished exporting using Compressor. So that was about 2 hours. Way longer than it was before. It looks like exporting is re-rendering which is irritating.

Likely you need to reset the preferences of FCP X, you can use preference manager from digital Rebellion. I find that once FCP X crashes a few times or is force quite a few times, FCP X will begin to lag and falter, you need to reset the prefs to speed up FCP X.

Or else it some other conflict, which compressor is very sensitive to as well. (especially after updates).

Just did some quick tests, on some Red 4K files. So big files, long render times. Working in proxy mode:

1. File > Share > Master File (pro res proxy) 567MB : 1 minute to export
2. File > Send to Compressor with ProRes Proxy Setting : I let it run for 5 minutes and then it estimated 45 minutes to complete
3. Created a New Share Destination with the Compressor ProRes Proxy Setting and did a Share in FCP X. 5 minutes to export. 564 MB.

From the looks of this it is better to create a Share Destination based on a Compressor setting and bypass Compressor. However, judging by the file size difference it still looks like some rerendering is occurring using the compressor settings in FCP X, rather than just collecting all the render files.

I used to be all over creating a master prores file and then compressing in Compressor too. However, I find little reason to do that with 10.0.6.

I used to be all over creating a master prores file and then compressing in Compressor too. However, I find little reason to do that with 10.0.6.

Agreed. Big time. When you send to Compressor it doesn't matter if your timeline is rendered or not. Compressor takes the video as it is on your timeline and crunches through it, disregarding render files. This was the case in legacy FCP as well.

With the new Sharing technology you can now add Compressor presets, but unlike the Send to Compressor option this workflow uses your GPU for assisted rendering. Which explains the much faster render times.

Still it is absolutely not normal that you get these long compression times when sharing as a Master File from a rendered timeline. Something else must be wrong. Have you checked your FiWi drive? Have you tried deleting all render files and render fresh prior to exporting? Mind you, Motion templates can be extreme render hogs.

The benefits of exporting a quicktime still apply.

Firstly, you can tell what the machine is doing, and what stages are working properly in the encoding process.

Secondly, there are much better encoders out there for many tasks.

Thirdly and most importantly you have a master file.
You don't have to reimport your event and project just to do another encode in the future.
Or sit and wait for FCPX if you decide to do another encode in the same session.

I cannot see any benefit to any other method.
All they do is save a few seconds of user intervention between encoding stages and a few mouse clicks.

The test below seems to suggest that exporting a QT took 1 min and exporting to a Share Destination took 5 mins.

Hi Duncan,

The benefits of exporting a quicktime still apply.

I entirely agree, for all the reasons you have mentioned.

But sometimes (many times in our case) an attending client wants to take a quick copy of the finished (or progressing) job with him. The picture quality of this copy is often not the most imperative requirement for him, as long as he doesn't have to wait too long for it. Being able to export such a file straight from the timeline while you are reviewing the work that has been done or while you are preparing the next session with him is a good thing. And that's possible now when you share over a Compressor preset that runs in the background and uses GPU acceleration. I have found this a very fast and easy method and for us it's a very good addition.

Sure, as long as we understand the implications of the workflow.
Reduced quality and less flexibility in terms of bite rates etc.

It looks like a good idea for a quick low-ish quality viewing copy.

For the record, are you sure Compressor is using the GPU?
I thought it was only FCPX doing that new trick in FCPX .6?

If so you could set up x264 in compressor and get better faster results.
At least you could in the old compressor...

Yes since 10.0.6 this feature works in the background and it uses GPU acceleration. It's pretty straightforward and fast, actually.

I have created a number of H.264 and WMV Compressor presets and added them to the Share > Destinations list on our systems for creating quick viewing copies. You can set the bitrates as low or high as you wish while making the presets. In fact you can export fairly high quality client views in a relatively short time because file size is not that much of an issue when you deliver the viewing copy on a stick.

I just tried this and it worked really well. I'm in the middle of a long slide show - about 6 minutes so far. I shared to Vimeo (720p clip) and went on working. I didn't notice any drop-off in performance in X while this export was going on. It took about 20 minutes or so. Maybe that's a little longer than exporting the clip and compressing it separately - maybe not - but it freed me up to work while it was happening. It's also a nice, easy interface.

The original OP question, I've not seen 10.0.6 take longer or crash more. I'd reinstall FCP X first.

I've never seen Handbreak out perform Compressor in final product image fidelity. In fact, I've seen Compressor give better image fidelity quit often.

But something is wrong with a system that takes that long to export and crashes that much. Most users of 10.0.6 are not seeing that.

What hardware specs?

If I'm not mistaken your graphics card has 256MB of RAM and is at the lower end of specs for FCP X. Now that exports go directly onto the GPU instead of the CPU that probably is where you're seeing performance differences in 10.0.6. So while a good bit of housekeeping is wise, I'd guess you're ultimately in need of some hardware upgrades.

x264 is proven to be the best h264 encoder available.
It's so good it's used by some major Hollywood studios to create commercial BluRays.

Duncan Craig wrote: x264 is proven to be the best h264 encoder available.

Really? The absolute best of all possible products? This is documented?

compression.ru/video/codec_comparison/h264_2012/

For example

Thanks for all the replies - been a useful thread. Yeah, I know I'm due for an upgrade. I'm in that delightful position of doing the work on the system I have to afford it, though

I think what's caused problems is the fact that the job was an old one I revisited and the timeline was made up of old motion templates for a third of it. I did wonder whether it was best to reopen the templates in the new motion and re-export them first but I thought I could get away with it as the timeline rendered. I'll do some tests before the next one of these template heavy jobs comes up in a couple of weeks. If it's looking iffy still, I'll re-install FCPX. I'm sure I exported a more regular edit without the problems - I'm in backup city today so I can't test things. I will report back in case anyone else has similar difficulties.

If I'm understanding you guys, the best approach is to build compressor export templates within FCPX and export there. I've not used Handbrake - my default app for encoding from masters is Episode which I've had as a legacy from an old project and is mainly used for WMVs which most of my clients need - alternatives to that would be interesting to know too. I also haven't found compressor to be great with graphics such as logos when compressing MP4s - feedback on that from others would be interesting.