C300MKIII footage - clunky playback in FCP?

chris f

Veteran
I'm a Premiere user and my C300MKIII footage (compressed, not raw) has always played back flawlessly on my MBP, but now I'm mainly working with editors who use FCP and they are complaining that the footage is playing back so poorly its almost impossible to edit without transcoding or creating proxies (different editors, different computers). Is this a common problem? I know that both are trying to edit off of a single spinning drive (one an external drive, one an internal drive in a stab station) on their iMacs and my hunch is that's what's causing the issue since I edit off a SSD or a faster RAID of 5 spinning drives.....BUT they also edit RED raw off those same drives and it works perfectly in FCP.

Any advice or guesses why this is?
 
Maybe the spinning drive, if they still make those - or something else is happening with the computer/footage. I would have said poor specs but wouldn't be the case if they are working flawlessly with RED footage.

FCP has many proxy options - and a better performance playback mode - which they should use (which will immediately solve the issue).

Did they actually try that or just aware of creating proxies?
 
By the way: If you'd like to upload an original file of something, I can tell you how it plays on a loaded Intel MBP and a M1 for reference (although both naturally have SSDs).
 
Chris - is it HEVC (h.265 compression) files maybe in UHD? And agree with you & NorBro that the culprit is most likely the drives they are using. I haven't edited C300mkIII footage specifically, but am a regular FCP user and have not run into this kind of issue. But I'm also amazed that lots of editors don't simply "optimize" (ie transcode) footage on the import since FCP makes it so easy to do so.
Also happy to try out a clip for you on my 2019 iMac if you want to share one of the files.
 
I'd also be happy to try out a clip in fcp on my Intel mbp and m1 mini. Doesn't sound like a spinning drive issue because I imagine that the red footage is a similar bitrate or higher? Thus the data should be moving off the drive fast enough?

I agree with mark that it sounds like the difference between hardware accelerated and not. But I dont think it should be doing any worse than in Premiere on your setup... what year is your MBP from?
 
Don't think the C300 Mark III shipped with HEVC (not sure if it came via FW).

Would 99.9% be the case if H.265 is being used.

If not, wouldn't be the formats as XF-AVC and CRL haven't changed from other models, which were handled reasonably.

___

Would also add - and this is obvious, but just in case - that adding LUTs/effects or heavy grading would slow down the playback.
 
Intel MBP plays it flawlessly so didn't even bother trying on the M1.

Most likely their drives.

Older iMacs had the option of having a "hybrid" drive which were terrible. Not sure if that may be the case but they constantly locked up, especially when failing.

P.S. Gorgeous Canon color and texture.
 
it plays back real-time flawlessly in FCP on my 2019 iMac (3.6 GHz 8-Core Intel Core i9). I put that test clip on my oldest spinning hard drive - which is USB 3.0 7200rpm drive I think - and did not experience any hiccups even after applying a light grade to the clip on a 3840 x 2160 23.98 timeline.
Perhaps these editors aren't super experienced? Or maybe they are doing something odd with the timeline?
 
It seems the problem may be with their version of FCP or something. From one of the editors:

"The problem is during the import - usually we can check a box that says "leave files in place" so FCP is referencing the original location of the files, but for some reason that box is greyed out. Instead our only option is to "copy to library" which means it's making high res ProRes versions inside the library on the drive (basically the project file). So that part takes a really long time and bogs everything down"

I recently started giving them the in-camera proxies along with the source files and those are playing perfectly so I guess they'll just use a proxy workflow for now....
 
"Copy to library" is common for almost all proprietary media besides ProRes and H.264/5 .movs and mp4s, which you could leave or copy.

They must usually be working with the latter and not Canon's or Sony's formats.

And it just hit me...and it actually makes perfect sense now:
They are trying to edit while FCP's background transcoding is taking place! :banned:
 
Seriously could make their own proxies in minutes...FCP is so advanced and useful with proxy options.

Just user error, unawareness like 90% of people working in this business, which is why I've come to resent it, ha.

The remaining 10% are amazing though.
 
It seems the problem may be with their version of FCP or something. From one of the editors:

"The problem is during the import - usually we can check a box that says "leave files in place" so FCP is referencing the original location of the files, but for some reason that box is greyed out. Instead our only option is to "copy to library" which means it's making high res ProRes versions inside the library on the drive (basically the project file). So that part takes a really long time and bogs everything down"

I recently started giving them the in-camera proxies along with the source files and those are playing perfectly so I guess they'll just use a proxy workflow for now....

As far as I know (very high level of confidence): if you import an intact card structure into FCPX, then the program babies you by assuming that you are importing footage from a camera card and not a back up from a drive. And it will not let you edit from a camera card, so it forces you to copy the footage into the library. (But I don't think that copying the footage necessitates transcoding to ProRes.)

(When I say intact card structure, I mean with "DCIM" folder and metadata, etc)

The way to get around copying footage into the library is to move all of the video files (.MXFs or .MOVs, etc) into a new folder by themselves on the hard drive. Then when you try to import that folder, you will have the option to leave the files in place and just begin editing. I do this ALL THE TIME. Transcoding proxies or full-quality ProRes versions is a separate decision that you can still make even if you leave the files in place.

Lastly, the transcoding that the program does is in the background and should be paused during playback and editing. So it really shouldn't slow down their playback unless maybe their hard drives slow down after sustained continuous use. So that's a little odd. But it will definitely slow the computer down if they try to use another program while FCPX is transcoding.

If I'm wrong and they're not importing your footage with the original folder tree intact, then I apologize to them. But that's what it sounds like to me
 
Last edited:
The transcoding does pause but you'd have to be constantly clicking around otherwise it's starting and stopping.

If you leave the computer idle for a few minutes, you can check the activity monitor and see the CPU/GPU (IDR which one) working hard (with a lot of high-spec footage) and then if you come back and try to play the footage along with a questionable drive, and possibly on the "Better Performance" setting, it's going to affect the playback.

P.S. You used to lose metadata when you copied your files off the card and imported them that way. Not sure how it is now though although most people don't even look at it so it doesn't matter anyway.
 
I've never noticed any missing metadata from doing it this way, though it might cause a problem with another camera or format. I copy the entire card onto a drive and then move the video files into a folder by themselves. So all the original files are there somewhere just in case.
 
Last edited:
The way to get around copying footage into the library is to move all of the video files (.MXFs or .MOVs, etc) into a new folder by themselves on the hard drive. Then when you try to import that folder, you will have the option to leave the files in place and just begin editing. I do this ALL THE TIME. Transcoding proxies or full-quality ProRes versions is a separate decision that you can still make even if you leave the files in place.

Very interesting, I’ll have them try this today!
 
Very interesting, I’ll have them try this today!

And it has to be outside the card folder tree. It can't just be a folder of clips next to the original folder it was in. So if I have a folder that contains DCIM and MISC, the footage has to be outside that folder or the program will still recognize the card structure
 
It seems the problem may be with their version of FCP or something. From one of the editors:

"The problem is during the import - usually we can check a box that says "leave files in place" so FCP is referencing the original location of the files, but for some reason that box is greyed out. Instead our only option is to "copy to library" which means it's making high res ProRes versions inside the library on the drive (basically the project file). So that part takes a really long time and bogs everything down"

I recently started giving them the in-camera proxies along with the source files and those are playing perfectly so I guess they'll just use a proxy workflow for now....

I'm not sure I'm following Abe's point in his recent posts after yours Chris... but perhaps they are using a non up-to-date version of FCP. I downloaded that mxf file you linked, put it in a folder on an old external drive, then went to FCP and imported using "keep files in place". No problems. Very quick import and then very seamless playback.
 
Abe is saying what you are basically saying. You downloaded only the file which was separated from the rest of the structured folder(s) so it's the same thing.

Not all formats used to work like this in FCP, but many were updated to do so over the years. I've lost track, but back in 2011-ish the handling of random files was archaic.

People used to constantly say separating the files like this from the structure would corrupt the footage but IDK; never happened to me the very few times I did it since I always like to keep everything in a self-contained library that I can move around (but the other way is perfectly fine too if you need to just share the files with someone).
 
Back
Top