|
Forum List
>
Café LA
>
Topic
Converting XDCAM 35mbs timeline to Prores HQ crashingPosted by jwatt
I just finished editing a 50 minute timeline in XDCAM 35mbs long GOP (1080i/60)and I'm attempting to convert it to a PRO Res HQ timeline and it's crashing my machine. MACPro Dual Quad core, 10gb's ram, Kona 3 card & Xserve Raid HD's).
In the past I've edited all this XDCAM material to a Pro Res HQ timeline as I went, but thought I'd try something different. It's different for sure, but not very satisfying. I tried reinstalling FCP with an FCS uninstall, but nothing seems to have changed. Anyone have a clue what i can due? thx...jw
Editing in long GOP is a bad idea. You want to get it out of that format before it hits the timeline. Just because the CPU can handle it "native" doesn't mean it's a good idea. I would capture that XDCAM as ProRez and cut from there if I could.
- Loren Today's FCP keytip: Toggle your Timeline Filters bar with Option T ! Final Cut Studio 2 KeyGuide? Power Pack. Now available at KeyGuide Central. www.neotrondesign.com
At this moment, i'd be the first to agree. I've done 4 hours by editing in Pro Res and it worked fine. This material is XDCAM EX, so it's basically acquired to the HD's with the file transfer utility, so when editing in Pro Res I'm constantly rendering, so that's why I decided to try the Long GOP route.
I'm still faced with the problem of having this timeline which I can't render, that's crashing my machine. So other than "don't ever do this again" is there any advice that may solve my issue. Exporting the timeline to a QT movie would be a nice option, but everytime I try to render the transitions in the XDCAM long GOP format, it crashes too. This just started toward the end of the edit. It had been working decently until the last 5 or 7 minutes of the show. thx...jw
>so when editing in Pro Res I'm constantly rendering, so that's why I decided to try the Long GOP
>route. The main reason I can think of for editing in Pro Res is so it doesn't have to constantly render. In fact, avoiding temporal compression in post is the main reason why I would transcode to/capture in prores when working on any of the Long GOP formats. For now, I can only suggest cutting your scenes and exporting small chunks. If it's a particular transition that crashes your machine, you might want to try to pin point it. If FCP constantly crashes, you might want to perform the usual maintenance steps like trashing your preferences, checking your scratch disk space, repairing disk permissions, etc... www.strypesinpost.com
>Editing in long GOP is a bad idea. You want to get it out of that format before it hits the timeline. Just because the CPU can handle it "native" doesn't mean it's a good idea. I would capture that XDCAM as ProRez and cut from there if I could.
Loren, I'm going to have to respectfully disagree with you on this one. Editing in XDCAM and HDV (specifically) are a doddle with FCP6. Today's CPU's handle editing these formats with ease, the only drawback being the computational hit of "conforming" to these codec's during render or output. FCP6 has overcome this by offering the ability to edit in the native codec and yet render to ProRes, seamlessly combining the codecs in the same timeline. This offers the very best of both worlds, ensuring fast renders that make the most of the ProRes codecs versatility (quality, I-frame, 422 etc), whilst maintaing the raw camera data in its native pristine format. As far as ideal workflows go, this one is pretty darn close! Sound like jwatt clearly has an issue, but I'd suggest the codec and workflow is not it. Certainly he could avid the workflow and therefore avoid the issue, but it wouldn't solve the root of the problem on his machine. No offense intended Loren, I'm not trying to start a workflow war (!) Its just that the "you have to get out of that codec" argument is trotted out frequently and is usually offered as though its real cure when in sometimes its just a band aid. In this instance I'm calling band-aid. The machine shouldn't be crashing on render and it doesn't sound to me that the cause is the codec in and of itself. ... now if I only had the answer to the problem as well I could strut off shining my halo. I don't though (drat!).
Thanks to everyone for their advice/insights. I finally got everything rendered, one little bit at a time on this show and laying off to tape now.
I like the ProRes render concept, while staying in the XDCAM format. I'll try that on my next hour, which I'll be starting today. Thanks again for all the help. Jim Watt
I'm kind of curious about the HDV workflow process. I still haven't worked on it yet, but if I do, I'll capture ProRes, because of the HDV issues I've been hearing about. Here, I can't tell my guys "hey, sorry, there was some artifacts, gotta reconform it and check it for artifacts/flashframes and send out that ep probably a day later, if the render goes well."
There are basically 2 camps. Capture, edit in HDV, render in ProRes if not going out to HDV, render in HDV if not going out in HDV; and another that says to get out the HDV as soon as you get it. Capture and edit in ProRes. Generationally, it is better to capture HDV, render in ProRes if your output is not going to be HDV, and render in HDV if your output is going to be HDV. Going any other method adds compression on top of compression. However, also knowing that HDV isn't a traditional editing codec (due to it's GOP structure). A cut made in HDV, isn't like a cut made on DV or any other editing codec. Final Cut now has to reorganize the I-frames on conform. If a cut was made on a B-frame, that point has be recalculated into an I-frame from the previous I-frame... This cranks up your rendering time unlike rendering on a normal codec. This, plus issues I've been hearing- flash frames from various parts of the video that isn't in the cut, as well as artifacts. Is this a result of the GOP structure breaking down? Or is it a QT 7.4 issue? Capturing as ProRes is a way to avoid both the rendering times, as well as the issues I've been hearing. It renders like any other editing codec, BECAUSE it is like most editing codecs, all I-frames. Calculations are easier, what you see is what you get. Not to mention, ProRes is quite the codec- virtually indistinguishable between Uncompressed and ProRes from a Digital Beta (i'm fairly new to working on ProRes, but it seems pretty close), so the compression isn't that big an issue. As far as speed is concerned, it is converted directly on injest, so no time for transcoding is necessary. And because it is captured on injest, and is like any editing codecs, there won't be any unexpected surprises after rendering, nor long conform times. So basically for ProRes captures, it's about reliability and time. XDCAM? I'm curious to hear about it too. Render times, machine specs, any issues especially off longer form (20 mins and up), as well as workaround/fixes. Just posted, but decided to cut and paste it here instead: [www.lafcpug.org] www.strypesinpost.com
Sorry, only registered users may post in this forum.
|
|