-
HD Multiclip editing in FCP7
-
Dunno why you are having issues Christer. XDCAM is a processor intensive codec, so multicamming them might be overload. Going to ProRes HQ is overkill for that format, but I have been on a show with XDCAM EX converted to the same. We have had 4 cameras…5 actually…multiclipped and plaback was fine. This running off of a Fibrechannel SAN in a shared workflow environment. No issues.
Shane
GETTING ORGANIZED WITH FINAL CUT PRO DVD…don’t miss it.
Read my blog, Little Frog in High Def -
Got maybe an answer this afternoon. It can be the ATTO-card. The supportpeople agreed that the card shows too much troughput fluctuations (see image) to handle the four ProResHQ-streams. They will send me a new one to test.
Hope this works. Maybe I can get to work without hickkups and annoying “lost frames”-messages.
-
Interesting chat. Well its been a few months since I first posted this link and I can’t say it has got much better. I am now running a faster XSAN with fibre connections and I still have drop out on XDCAM 422 multiclips. ProRes is worse as it is more processor heavy. I have only 3 clips and it drops frames telling me my drives may be slow – I DON’T THINK SO! I agree this is a flaw elsewhere in the AJA Kona 3. Let me know how you get on with this!
-
This issue has been quite a challenge for us. Just about identical workflow. XDCAM 35mb Multicam edit. 3 systems pulling from XSAN, 2 angles so not even that stream intensive. Green flicker of death when in open sync mode or in trim mode. To those saying its an AJA thing, I would have agreed with you but we can reproduce without any hardware. Basically a stripped down FCP with now output hardware. I would LOVE to see a solution somewhere. Our best success was to drop the cache down to 80%. We can at least save before it fully crashes. Anyone have any solid luck with this annoyance? The silence of success from the Avid rooms are deafening.
-
XDCAM…that’s a GOP format. Multiclipping GOP formats, that are already processor intensive, means more weight on the processors. If you converted to a less intensive format like ProRes then this would go much smoother.
Are those Avid’s playing back XDCAM native? Or has the footage been transcoded to DNxHD? Maybe THAT’S why the Avid is handling it so well. Do things right in FCP…convert to PRoREs…and things will go smoother too.
Shane
GETTING ORGANIZED WITH FINAL CUT PRO DVD…don’t miss it.
Read my blog, Little Frog in High Def -
Yes, all 5 Avid systems are cutting XDCAM 35mb native. Transcoding final sequence to DNX for finishing but editorial is completely native. I think i went down to one of the rooms once because Editor was chilly and needed an AC adjustment.
-
Ahhh….MC4 or 5 then? Interesting that Avid can handle those formats better. Avid has a leg up on many many things lately. Used to be you had to transcode, and they didn’t support a lot of formats. They improved quickly.
I’ll have to play with XDCAM on my system. I have some footage to test.
Shane
GETTING ORGANIZED WITH FINAL CUT PRO DVD…don’t miss it.
Read my blog, Little Frog in High Def -
They’re on 3.5.9
We just transcode to DNX as you need your media to be DNX for digital cut to tape.
We could try the pro res thing but there is a LOT of media so that would be a huge commitment. Willing to explore if it makes those troubles go away. Takes up considerably more drive space though correct?
Thanks Shane,
Enjoy your weekend
-
Hey. We hve still had problems. In fact they are even worse when you add in other codecs such as ex3. What worked best in a recent show was to convert all th footage to pro res proxy files. I was amazed at how good the quality was and actually if you keep the file names the same via compressor it reconnects to original media quite eallsily at the end. Obviously I would rather fcp be able to handle the native codec bit this was quite easy and pro res is quite quick to convert to.
-
HI All
Still having issues with multiclip sequences here! I’m running on an “old” 3.0 Ghz eightcore system with 12GB’s of RAM. OSX 10.6.3. Eight SonnetTech 500P boxes with 40 1TB hardrives connected to a RocketRAID 2522 card running RAID 5. Appr.: Read: 700MB/s Write: 650 MB/s
So what I’m asking my computer to do is run 9 streams of XDCAM EX in a multiclip sequence. And before everyone jumps at me with the obvious and by now quite tired “but that’s a lot of processing you’re asking of your CPUs!” and “You should convert to prores!” (the holy grail of codecs sure to fix everything from the common flu to the demise of your ex) , let me just say I have been there and it still doesn’t work with ProRes proxy.
The good news is… It works fine…. until it doesn’t. That’s basically my frustration. My old MacPro just eats it’s way through my 9 streams and I can sit and edit just fine for half a day… and then all of a sudden, boom! FCP is gone! There’s no warning, no slowdown, I’m doing nothing other than what I have done the rest of the day when it was working fine. This is what is really bugging me. If the machine is too slow, well then it should just grind to a halt, not crash! I do not believe that when you design an app, you say: “Hey what if we make the app just crash if you put a big load on it.”Me actually being able to work half a day on the system without a crash and the nine clips of XDCAM EX just playing without any hickups, tells me that it has nothing directly to do with performance. Of course if I enable “External Video” and try to play through my Multibridge Pro II the system crashes immediately! So apparently it doesn’t like to output nine steams to the graphics card AND output to the PCI bridge card at the same time.
That in my opinion also is a bug, most likely from Decklink’s side. A look at the crash log seems to strengthen this theory as well.I had a friend who was an ace on the early Avid systems, back in the day they were called PowerMac 8100 and was running on a 601 PPC CPU. He was always three or four commands ahead of the system when he was editing (Yes he was that fast, or the machines that slow!) But whenever he took a breather the machine caught up to him. And this was even on Mac OS 8.5! This is how software should be written!
So I think my reasoning still stands as valid: There’s some shifty code inside FCP! How about it, Apple??
Reply to this Discussion! Login or Sign Up