Problem with file length in editing in FCPX

[David Roth weiss]

This is the FCP legacy forum, not the FCP X forum. However, your issue is more than likely related to hard drive throughput, not anything else. Your editors need at least two or more drives configured as a RAID.

David Roth Weiss
Director/Editor/Colorist
David Weiss Productions

David is a Creative COW contributing editor and a forum host of the Apple Final Cut Pro forum.

[Shane Ross]

[Joel Porter] “What ends up happening in the end is they have to take the files into Wondershare converter and convert them to a smaller size.”

Boy did they do the WRONG thing. I’m no FCX expert, but I do know that if you are having issues editing full res, you simply have FCP optimize the footage as PROXY, and edit that. Much lighter, FCP is tracking the footage, and when you are done, relink to the master files for the final export. Using Wondershare breaks any and all connection to the original files.

Shane
Little Frog Post
Read my blog, Little Frog in High Def

[Joel Porter]

Should I move this to the Final Cut Pro X forum then? Sorry, just new here.

1. So it has to be a raided drive for best results? They’ve even taken the files direct to desktop SSD and still had those issues. I thought an SSD would be just as quick as a RAID. Maybe not?

2. I’ll check on the proxy option. To be clear, they export first to Wondershare simply to reduce file size and make it work, then use those files from scratch to edit. Which yes, it is not so great as the quality loss is evident.

[Shane Ross]

[Joel Porter] ” Should I move this to the Final Cut Pro X forum then? Sorry, just new here.”

I moved it for you.

[Joel Porter] “1. So it has to be a raided drive for best results? They’ve even taken the files direct to desktop SSD and still had those issues. I thought an SSD would be just as quick as a RAID. Maybe not?”

SSDs are fast, but two RAIDed drives are faster.

[Joel Porter] “2. I’ll check on the proxy option. To be clear, they export first to Wondershare simply to reduce file size and make it work, then use those files from scratch to edit. Which yes, it is not so great as the quality loss is evident.”

It was clear…and is still the wrong thing to do. If you need to edit lighter, convert to Proxy to edit, then relink to the masters when you go to output the final. Quality will be MUCH better, and it’s just a better workflow.

Shane
Little Frog Post
Read my blog, Little Frog in High Def

[Bill Davis]

Joel,

How much formal training in X operations do your shops editor have?

I ask because sometimes, folks relatively new to X misunderstand the basic workflow process of it’s referential system.

Particularly about how X creates the working files it needs during footage import. The way X uses metadata links to point to the original files, often tricks folks into thinking that in X, imported clips arrive “instantly” you’re ready to edit. And you are, KINDA. X actually uses instant initial clip representations UNTIL it has better media set up and in place. The system is designed so that you can start making edit decisions and even doing color work and audio editing fast, BUT – under the hood, there’s still a LOT of work the software needs to do in many cases.

This includes any transcoding you’ve set up. That can be “optimizing” your media into ProRes, making Proxies for better performance, or just calculating the very detailed graphic representations of the audio waveforms X presents to the user to allow audio editing at subframe accuracy.

Remember I said you “can” get to work instantly? It’s true, but it’s also true that unless you turn off “background rendering”, X is set up so that every time you move the mouse or type, the program STOPS the background processes.

If you need to work instantly, try turing OFF background rendering so the program isn’t constantly interrupting itself. BUT – if you do that, you need to manually re-start the background processes when there”s time, or the behind the scenes work will NEVER get done and everything will take forever to output.

With long takes and multiple cameras – and of course depending on the original recording format and how much transcoding X has to do to get the footage into shape for editing – there might be quite a bit of heavy processor work needed.

It’s up to your workflow needs whether you stop ALL non-essential processes and just live with “on the fly” calculation of playback and interface representations, or whether it’s smarter to let X run for a few hours when things are first imported to allow it to transcode and do it’s waveform rendering and the like.

Have you taught all your X editors to watch the Background Processes menu, invoked by clicking on the circular percent gauge in the dashboard? Until everything is finished there, your import process isn’t actually finished.

If X is processing stuff, then you should either leave it alone until it’s finished – OR stop it with intent, live with the lower rez displays and slower interface representations to get your cutting and basic editing done – then just render out your finals.

Hopefully, I haven’t mis-read your issues, but I see a LOT of shops that have editors who have learned by simply “kicking the tires” with X, and never learned this type of background stuff.

If you have and you’re truly facing a different issue, then ignore all this with my apologies for presuming too much. If you keep having trouble, post more details and let the “hive mind” try to figure it out. There are now lots of shops running X in situations like yours and some of us here can likely connect you to folks to chat with who are very skilled at multi-seat X systems similar to yours.

Good luck.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Bret Williams]

It sounds as if you think the background rendering preference has something to do with background processes like creating proxies or transcoding. It doesn’t. Background rendering only applies to rendering in the timeline. Two completely different things. I turned off that horrible checkbox 3+ years ago myself. Proxies and optimizing are created just fine.

[Bill Davis]

[Bret Williams] “It sounds as if you think the background rendering preference has something to do with background processes like creating proxies or transcoding. It doesn’t.”

Bret,

Are you saying that each of these has entirely separate calculation pipelines, perhaps one using the CPU and the other the GPU? I haven’t ever heard that. My understanding is that the GPU has to process ALL the content in the rendering pipeline no matter what else is going on (or not.) So if you have either background process in action, the processor will be interrupted at least to the extent that the queue has to run the math for the other stream.

Maybe I’m incorrect about that, but it’s always seemed to me that if I’m working furiously to edit, most all the background processing gets significantly delayed, whether that’s transcoding to proxies or calculating a user specified color change for timeline display.

Pehaps it’s just an issue of us having different hardware setups?

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Bret Williams]

Yes. You are correct. Whenever you’re doing something background processes get delayed. Some seemingly more than others. But the background render preference only affects one process. Rendering. It doesn’t affect optimizing or waveforms or thumbnails or exports or proxies. If you turn that checkbox off it only disables background rendering. I don’t know of anyone that leaves that checkbox on. You suggested that if he didn’t want proxies and optimizing to occur, then he should turn that off. And that he’d have to restart those processes manually. That checkbox wouldn’t turn off any of those processes.

[Bill Davis]

[Bret Williams] “I don’t know of anyone that leaves that checkbox on.”

Actually, Brett, this is what I was trying to get to (clearly in a very ham handed way.) I’ve seen lots of folks new to X who haven’t learned this very basic step, so they’re constantly annoyed when every time they go to do anything, the background rendering takes a second to stop and for the UI to kick back in.

Mea Culpa on once again over explaining something that’s actually very simple.

And also, he needs to learn that he CAN disengage the background rendering processes if he’s in a HUGE hurry – by using the Render Manager.

For such a simple cheap little program (; )), as you well know, X does have it’s complexities, doesn’t it?

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Bret Williams]

Not that it really matters, but that still doesn’t make any sense. Here’s what you said

[Bill Davis] “Particularly about how X creates the working files it needs during footage import. The way X uses metadata links to point to the original files, often tricks folks into thinking that in X, imported clips arrive “instantly” you’re ready to edit. And you are, KINDA. X actually uses instant initial clip representations UNTIL it has better media set up and in place. The system is designed so that you can start making edit decisions and even doing color work and audio editing fast, BUT – under the hood, there’s still a LOT of work the software needs to do in many cases.

This includes any transcoding you’ve set up. That can be “optimizing” your media into ProRes, making Proxies for better performance, or just calculating the very detailed graphic representations of the audio waveforms X presents to the user to allow audio editing at subframe accuracy.

Remember I said you “can” get to work instantly? It’s true, but it’s also true that unless you turn off “background rendering”, X is set up so that every time you move the mouse or type, the program STOPS the background processes.

If you need to work instantly, try turing OFF background rendering so the program isn’t constantly interrupting itself. BUT – if you do that, you need to manually re-start the background processes when there”s time, or the behind the scenes work will NEVER get done and everything will take forever to output. “

Nowhere in there do you even mention rendering. You discuss at length optimizing and proxies and waveforms and then say that you should turn off background rendering so that the app doesn’t interrupt itself with those processes. Which isn’t even a remotely accurate statement. Turning off background rendering won’t keep the app from interrupting itself with waveforms, proxies & optimizing or thumbnails. You just have to wait.