XDCam HD Multicam out of sync

Hi, All,

I've inherited a FCP 7 project. Original media is XDCam HD422 1080p30. It is a multicam project. It was a 3 camera shoot was jam-sync'd.

The short version of my issue is that I am not getting consistent playback on my 2.8 GHz MacBook Pro running OS X v 10.6.8 with 4GB of RAM. I'm wondering if I have enough horsepower to play back native XDCam HD? The audio lags behind the video by several seconds. The media is coming in via FW800 from a G-Safe drive.

If I export a timeline, it looks fine in QT Player (except for the angle that really is out of sync that I will need to slip back into sync once I solve my playback issue... but that's another post)

Is there anything else you need to know to help answer this?

All my previous XDCam work has been on Avid, so I'm not entirely sure where to go for XDCam & FCP resources.

Thanks!

debe

Hi Debe,

Yea, it's could be processor power. Never tried doing multicam on XdCAM HD 422, only XDCAM EX. But XDCAM HD 422 seems quite processor intensive, based on the time I take to transcode to it. Anyway to transcode to Prores Proxy or LT?

What is the throughput on the drive? Can you run AJA System Test and check for dips?



www.strypesinpost.com

I will download that and let you know.

In the meanwhile,

The producer has decided that we need to move forward on this, so he's having me hand-sync the timeline up in his Avid. (It's not that long or intricate of a timeline, but I do appreciate compatriot sympathy!)

I was able to get a timeline out of Automatic Duck into the Avid. The Avid system doesn't see video on the master MOV files (which I'm assuming the previous editor got via Sony's XDCam Transfer software, but I need to verify). On the Avid, the audio is there, but the video is a black screen.

So I'm getting an old-school 10-Key workout typing in timecode and editing from the original XDCam HD disk footage via AMA. I copied the four disks to the Avid's media drives.

Long story short, because I really need to get back to the project, I do need to figure out both workflows. 1. FCP to FCP (what does my system need to be/have to make this work) & 2. FCP to Avid. If anyone has any thoughts on either, I'd really appreciate it!

Right now I need to finish this project. Deadline for it (and me) is Friday.

thanks!!

debe

Two things first. 1, Automatic duck works better with Prores. 2, XDCAM codecs are proprietary and Avid has their own codec and Avid doesn't read it very well through QT- gamma shifts and what not in MC5.5. So yea, I won't expect much if you go down this lane.

If you are in MC6, this is what I would do:

1) transcode footage to Prores (HQ). That will be your high rez footage.

2) Automatic Duck it over to Avid. The footage should link up via AMA.

3) Consolidate/tramscode to DNxHD36.

4) On picture lock, relink to high rez Prores files (need to test if using Automatic Duck will affect this function), and if you have to, consolidate to Prores MXF and trim unused and send for online.



www.strypesinpost.com

Thanks, Strypes!!!

This client is still on MC 5.5. Does your workflow suggestion change for this version?

Still, all very good info! I shall pass this along to my producer so the next time they hire someone to do an offline that they want me to finish in Avid they will hopefully start with ProRes footage instead of XDCam HD out of XDCam Transfer.

Initially they thought I'd be finishing in FCP, so the original plan was partially good.

I know that editing in FCP with some native codecs gets the editing happening sooner, but it bites an editor in the tushie at the export. In this case, the end product is 4 minutes, so transcoding all the footage might have taken longer than just transcoding on the output, had we stayed in FCP.

If it's just an approval copy and final output, no big deal, but when you get into multiple rounds of approval and futzy tweaks back and forth, the export just kills a process...

I do wish there had been time to test the workflow before he started his offline.

I still will run the AJA System test and see if it's my MBP that was choking on the XDCam HD footage.

Thanks, again!!

debe

>I still will run the AJA System test and see if it's my MBP that was choking on the XDCam HD
>footage.

The AJA System Test utility tests whether your hard drive is choking on the footage.


>I know that editing in FCP with some native codecs gets the editing happening sooner, but it
>bites an editor in the tushie at the export.

Well, it depends on whether your machine (and the software) can handle the format. Cutting multicam means the machine must be able to cope with playing back as many streams of footage as you have in real time. Depending on the format, it can be a hard ask. Moreover, XDCAM is a sticky format to cut in- long exports, crashy on large projects, long render times, etc. So I usually transcode XDCAM either to an offline format or ProRes HQ, but it depends on the job, amount of footage and turnaround time.


>This client is still on MC 5.5. Does your workflow suggestion change for this version?

Yes. I'll probably transcode the XDCAM footage to DNxHD 220 as the intermediate format, and DNxHD36 as the offline format.

So basically, instead of transcoding to ProRes in Compressor:

1) Transcode to DNxHD 220 in Compressor.

2) Then Automatic Duck the sequence into Avid,

3) then consolidate/transcode to DNxHD36 for the edit.

4) When you are done, relink back to the DHxHD QTs that you created in Compressor, and consolidate it into Avid Media and send it for online.


Things to test for:

- Gamma shifts when importing the footage into Avid.
- whether Avid is able to a fast import in step 4 during the consolidation process.


How would I do it if I was doing this in FCP? I'll transcode to ProRes Proxy, edit, then relink back to the XDCAM QTs, then render out as ProRes HQ. Switching between NLEs is time consuming and troublesome.



www.strypesinpost.com

Just ran the AJA Speed Test. I think you are right and the FW800 drive is choking on the footage.

I got 66.5 MB/s on write and 85.2 MB/s on read in the speed test.

The XDCam Transfer .mov file reads 59.31 mbits/s playing back in QT.

And now that pesky "bits versus bites" is prolly making me more confused... Sigh. Any insight here or do I need to run another one of their tests?

I am copying your workflow into a document that I can share.

Thanks!

deb

8 bits = 1 byte. The average speed on the drive is definitely fast enough, however, you need to check for dips in the graph when you turn on the graph function. The dips should not be too extreme, or you will drop frames, and sync may be affected.



www.strypesinpost.com

Does this tell you anything? (I should show it to the Technogeek, but I'm here, he's there, and you are online! It just seems more efficient and easier this way!! ;-D)

debe

The test sample is too small. You have about just enough bandwidth for multicam editing (scrubbing, etc). But as far as dropped frames on playback is concerned, it's probably the processor. Yes, I'll transcode before editing- on both FCP and Avid.



www.strypesinpost.com

That's mostly what I need to know! Transcoding is best!

Thanks!

debe

I won't say it's best, just that it let's you work with limited system resources.



www.strypesinpost.com