FORUMS: list search recent posts

Problem with file length in editing in FCPX

COW Forums : Apple Final Cut Pro X

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Joel Porter
Problem with file length in editing in FCPX
on Feb 23, 2015 at 10:06:52 pm

I'm wondering if anyone can shed some light about file length in Final Cut Pro X and what computers handle what file sizes.

Our workflow is like this: 3 cameras recording 1080i on KiPro decks at 422LT, each about 2.5 hours in length. (Approx 100gb each - size varies exactly), then taken to the editing stage. We have a few editors with newer MacBook Pros (2014, i7, 16gb ram, SSD, Thunderbolt drives) and when they try to edit these 3 files in FCPX they simply can't do it. The work flow is so slow and spinning colour balls everywhere, it doesn't work. What ends up happening in the end is they have to take the files into Wondershare converter and convert them to a smaller size. Then it works. (it ends up being converted to 3x 10gb H264 files, which looks ok for our purposes, but is still a work around initially.)

I guess I'm wondering: Do we simply need to get different computers such as a mac pro to handle longer files at larger file size? or is there something we're missing? Is it a multi-core thing vs just raw processor speed?

Thanks,


Return to posts index

David Roth Weiss
Re: Problem with file length in editing in FCPX
on Feb 23, 2015 at 10:26:35 pm

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.


Return to posts index

Shane Ross
Re: Problem with file length in editing in FCPX
on Feb 23, 2015 at 10:53:29 pm

[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


Return to posts index


Joel Porter
Re: Problem with file length in editing in FCPX
on Feb 23, 2015 at 11:56:55 pm

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.


Return to posts index

Shane Ross
Re: Problem with file length in editing in FCPX
on Feb 24, 2015 at 12:32:43 am

[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


Return to posts index

Bill Davis
Re: Problem with file length in editing in FCPX
on Feb 24, 2015 at 7:28:53 am

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.


Return to posts index


Bret Williams
Re: Problem with file length in editing in FCPX
on Feb 25, 2015 at 3:31:26 am

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.


Return to posts index

Bill Davis
Re: Problem with file length in editing in FCPX
on Feb 25, 2015 at 8:23:41 pm

[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.


Return to posts index

Bret Williams
Re: Problem with file length in editing in FCPX
on Feb 25, 2015 at 9:43:24 pm

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.


Return to posts index


Bill Davis
Re: Problem with file length in editing in FCPX
on Feb 25, 2015 at 9:48:22 pm
Last Edited By Bill Davis on Feb 25, 2015 at 9:50:48 pm

[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.


Return to posts index

Bret Williams
Re: Problem with file length in editing in FCPX
on Feb 25, 2015 at 9:58:31 pm

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.


Return to posts index

Bill Davis
Re: Problem with file length in editing in FCPX
on Feb 25, 2015 at 10:22:13 pm
Last Edited By Bill Davis on Feb 25, 2015 at 10:24:21 pm

[Bret Williams] "Turning off background rendering won't keep the app from interrupting itself with waveforms, proxies & optimizing or thumbnails. You just have to wait."

Arrrrrgh. No you do not. You can simply pause the background rendering processes here.




Every one of these, if they're in process, can be paused or dismissed outright and re-started later.



So the idea that "you just have to wait" is simply incorrect.

We're arguing semantics (and my poor phrasing choices) but the bottom line for the OP is that he wanted to GET TO WORK in a tight deadline environment. One strategy for that, is to DISABLE the up front processes, work with the low rez initial files to get the work done that you need to do editing and getting your program done - and only THEN let the machine do all the calculations. Is it the OPTIMUM way to work? Maybe, maybe not. Depends on the deadlines being faced and where you think the time exists in the workflow to allow the machine to eventually crunch all the numbers and build the show.

But regardless, X allows for a "deferred rendering and processing" workflow very nicely.

I will grant that if you're working with non-native file types that X can't immediately parse into on-screen clip representations (in other words, OTHER than ProRes or h-264 or similar Apple "in house" codecs - you may be shut out without transcoding. But millions of editors don't face that. So it's not always germane.

Whatever language you or I use to describe 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.


Return to posts index


Bret Williams
Re: Problem with file length in editing in FCPX
on Feb 25, 2015 at 11:07:10 pm

True. Below is the image of the background render setting it logically seems you were referring to here...

[Bill Davis] "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. "



It's not until much later in the post you even mention the background processes window. Which, yes, of course is where you could pause or stop the optimizing or proxy creation. Another solution might be to turn off both of those settings altogether by default before import (in the import prefs) and invoke it after the fact in the event on the appropriate media. But seems kinda like a weird thing to stop them. Either you need proxies/optimized media to edit or you don't. If you can work without, then import the originals and begin editing. But I guess you could let the process start, open the window and force stop or pause it.

FWIW I'm not sure stopping those processes would improve performance. Isn't the performance problem not that it's churning on the transcodes while you edit, (it very seamlessly stops that the instant you move the mouse) but the fact that one ins't using transcoded material when they need to? For example if you're editing with originals instead of proxies when your system can't handle the originals. If you want the performance, you do have to wait for them to encode.

Anyway, hopefully this little sidebar clears up any questions for the OP instead of muddying the waters!


Return to posts index

Bill Davis
Re: Problem with file length in editing in FCPX
on Feb 25, 2015 at 11:24:10 pm

[Bret Williams] "Anyway, hopefully this little sidebar clears up any questions for the OP instead of muddying the waters!
"


Amen to that.

This entire thread is a great testament to the fact that while X appears to some like a "simple $299 NLE" it's depths are pretty substantial. Witness the two of us deep in the weeds looking at the same workflows from two slightly different angles, and being able to usefully discuss the differences and similarities.

Score another one for the Apple design team. Simple, but deep. Not the easiest design goal to meet!

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.


Return to posts index

Dave Jenkins
Re: Problem with file length in editing in FCPX
on Feb 26, 2015 at 1:35:09 am

Joel, I have been using FCP X for a couple of years now. FCP X has problems with long files 2 hours plus. I think the problem is it has to build the audio waveforms and on long files that can't take 30 minutes to an hour before I can use those files. I'm using the latest MacPro and a T-BOLT 2 raid running at 700mb per second. How many audio channels does your video file have? I import ProRes 422 created using a Blackmagic Hyperdeck and FCP X has a fit with the 16 channels of audio even though only 2 channels have audio.

Dajen Productions, Santa Barbara, CA
Mac Pro 3.5MHz 6-Core Late 2013
FCP X


Return to posts index


Joel Porter
Re: Problem with file length in editing in FCPX
on Feb 26, 2015 at 5:51:05 pm

Thanks everybody for the input, I will definitely be trying out some things here.

We have just 2 channels of audio. All 3 camera files have the same audio (for 6 tracks) but the extras are deleted and we just use 2.

It sounds as if there simply isn't much to do except wait for processes to finish either before of after the editing, or turn into proxies.

Would it help to initially cut the file into 2 or 3 pieces each?

I will also look into getting RAID drives as well as it seems one lone SSD and laptop may just be too slow.


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]