need help interpreting crash report

[Patrick Donegan]

When things like this happen for me, I output half of the pileup to some nice clean spot.

If this compression task gets done, I know it might be RAM or something …

And then I output the second part.

A few times I had to cut an hour into 3 sections to output.

[Gary Huggins]

What do you use to stitch the parts back together after export?

[Dennis Couzin]

Sorry I can’t interpret the Crash Report but the early references to ‘FCPAudioUnits’ smell like bug.

In general, export from FCP to Compressor is more buggy than taking 2 steps: export from FCP to .mov file; stick .mov file into Compressor. For the first step full render is advised because it will signal if there’s a particular trouble spot.

For RAM testing, there was a small program ‘memtest’ written by Charles Cazabon that worked smoothly in OS 10.6.8. I’ve attached it with some simplified instructions.

Good luck!

memtest-1.zip 54 KB Zip - Click to view

• Copy Download Link

[Gary Huggins]

Thanks for the memtest, Dennis.

Regarding export, if I export the project as a .mov file and then stick that file in Compressor, won’t I be compressing the project twice? Would that detract from the video quality, especially as the file will be compressed again when I upload it to Vimeo?

[Dennis Couzin]

Gary,

You don’t reduce the number of compressions by sending directly from FCP to Compressor. There are two ways you could imagine that to happen. Either (1) FCP could send all clips in the timeline to Compressor in their original codecs, or (2) FCP could send all clips to Compressor uncompressed. Neither of these things happen. Simple experiments prove this.

How could (1) work when clips in different codecs overlap, e.g., in a dissolve? FCP must make the overlap; Compressor can’t. Likewise for (2), the editor needs to see how each FCP effect looks, and many effects, although performed decompressed, depend on the codec of the sequence setting for their final appearance. Thus we render out many FCP effects not just for smoothness of playback, but for accuracy. It is only where some non-effected clips are in codecs different from the sequence settings that there would be advantage to FCP sending them uncompressed to Compressor. But we can prove that FCP doesn’t work that way.

What must be appreciated is that in absence of effects, when the sequence settings match a clip’s codec, the .mov export is a passthrough with no recompression. This can be confirmed by the speed of the export process, as well as by examining details. FCP export offers a “Recompress All Frames” option which should almost never be selected. See Creative Cow discussion from 12 years ago with that title.

What FCP sends to Compressor depends on the FCP sequence settings. A simple experiment. Make sequence settings for 960×540. Drop in a 1920×1080 clip having alternating 1 pixel green and magenta lines. Of course it looks grey in the canvas. Send to Compressor. Ask for 1920×1080. Yup, it’s now 1080 grey lines. You can try other experiments involving codec differences instead of size differences. I think you will confirm that Compressor gets video as-if compressed according to the FCP sequence settings. Whether Compressor receives the video in codec or decompressed from that codec is immaterial.

Dennis