Our EX->HDCAM Workflow Plan

[Steve Gibbons]

I was curious if anyone else uses a similar workflow as we are planning:

We just got our XDCAM-EX and have been scratching our heads trying to figure out the best workflow given a few things:

a) the high cost of SxS cards for archiving
b) the lack of official Avid support of 35mb/s HQ video
c) the high CPU hit for editing long GOP material

We plan to - at least initially - adopt a similar workflow as we did with our small B-cam Sony HDR-CX7 AVCHD unit. The workflow is as follows once back to our facility following a shoot:

1) submit camera/laptop/cards/backup firewire hard drive to our assistant editor for dubbing to an HDCAM deck via a NanoConnect box (HDMI->HDSDI). If we had to re-use cards during the shoot, they copy the AVCHD files from the laptop back to a card and play it back from the camera to the VTR. Alternatively, we can use our office Playstation3 card reader to play cards out to the HDCAM deck via our NanoConnect.

2) Ingest the HDCAM dubs to our Avid Unity via an Adrenaline to DNxHD.

3) Archive the HDCAM tapes

4) Complete the edit and master back to HDCAM

This workflow addresses the archiving issue as we end up with a regular tape to put in our library. It also addresses the CPU hit in editing performance as we are using DNxHD.

We've considered archiving the cards to DL DVD or even Blu-Ray as yes, HDCAM tape is far more expensive than a DL DVD. But for now I think we will stick with HDCAM as it's familiar to us and just works when ingesting to DNxHD on the Avid.

As mentioned, we'll likely adopt a similar workflow with the EX although we haven't quite got our heads around what happens with card spanning video. Perhaps only loading a single card or maybe doing an assemble edit when dubbing to HDCAM. The expected deck will also free the camera up during the dub process.


If anyone has any thoughts, comments or suggestions, we'd love to hear them.

Thanks,

SG

[Jon Carlson]

Still just a rumor, but this thread (http://dvinfo.net/conf/showthread.php?t=117823) seems to offer some improvements to your workflow.

If the rumored deck will come to fruition, that should take several steps out of your process.

Also, Avid support for the XDCAM format may solve all of your headaches.

But, again, it's just a rumor at this point.

[Alister Chapman]

Why use HDMI when you can play clips out of the camera via HD-SDi. HDMI-HD-SDi conversions almost always add artifacts.

[Steve Gibbons]

Originally Posted by Jon Carlson

Still just a rumor, but this thread (http://dvinfo.net/conf/showthread.php?t=117823) seems to offer some improvements to your workflow.

If the rumored deck will come to fruition, that should take several steps out of your process.

Also, Avid support for the XDCAM format may solve all of your headaches.

But, again, it's just a rumor at this point.

Hi Jon - I actually started that thread you linked to.

Even if Avid offers support of HQ 35Mb/s, it's still editing long GOP video which is very CPU intensive - and VBR video even more so. Sticking with DNxHD is still going to provide the best editing performance.

And yes, as I mentioned earlier in my original post, the new EX deck should help us out.

SG

[Steve Gibbons]

Originally Posted by Alister Chapman

Why use HDMI when you can play clips out of the camera via HD-SDi. HDMI-HD-SDi conversions almost always add artifacts.

Actually I was referring to our Sony HDR-CX7 workflow. That's a consumer camera with a mini-HDMI output. We connect it to our HDCAM VTR via a NanoConnect and haven't noticed any artifacts with that unit. It works quite well. We plan to adopt this workflow (minus the NanoConnect) for our XDCAM-EX which, as you point out, has HDSDI.

SG

[Simon Wyndham]

I am puzzled as to why you are using tapeless cameras for a tape based workflow??

[Steve Gibbons]

Originally Posted by Simon Wyndham

I am puzzled as to why you are using tapeless cameras for a tape based workflow??

In the case of our Sony HDR-CX7 cameras, we wanted a small, light, low-cost "in harm's way" HD camera that could be attached to cars, helmets, roller-coasters, etc. Solid state memory card based cameras were obviously our best choice because of their higher resistance to shakes and rattles and less moving parts to fail. So far we have been very pleased with the footage from these cameras including a few BMX outings and some skydives. We also just picked up a StickyPod for vehicle mounting.

We purchased the PMW-EX1 for its price/picture quality bang, size, lens, low-light ability, time-lapse ability and S&Q features. The fact it is memory-card based really didn't play any part as a selling feature to us. So consequently we are doing our best to integrate it into our existing tape-based workflow based on what we have learned with the CX7s. In our case, getting the video out of the Long GOP & AVCHD card world and into something more editing & archiving friendly quickly was a priority.


SG

[Simon Wyndham]

Hmm, I think you are going rather around the houses somewhat in that workflow plan.

These days, there is really no extra hit for editing with LongGOP formats. In fact you will retain higher quality by staying in the native format until any extra rendering/grading is needed, since transcoding to another format, be it HDCAM or anything else, including Apple Prores, is still a generation hit.

It is always when people use these styles of workflows that the camera system was never really designed for that problems always start to occur. The EX system was designed to have footage ingested straight from the card using some form of transfer software and then edited in an NLE. Anything different is asking the system to do what it isn't designed for.

The clips that span two cards are a case in point. This is handled transparently with the software and workflow it was designed for. Or if you play straight from the cards through the cameras SDI output.

Or as someone else suggested with the rumoured deck. Although that DVinfo post was the first I've heard about that one.

[Steve Gibbons]

Originally Posted by Simon Wyndham

These days, there is really no extra hit for editing with LongGOP formats. In fact you will retain higher quality by staying in the native format until any extra rendering/grading is needed, since transcoding to another format, be it HDCAM or anything else, including Apple Prores, is still a generation hit.

It is always when people use these styles of workflows that the camera system was never really designed for that problems always start to occur. The EX system was designed to have footage ingested straight from the card using some form of transfer software and then edited in an NLE. Anything different is asking the system to do what it isn't designed for.

The clips that span two cards are a case in point. This is handled transparently with the software and workflow it was designed for. Or if you play straight from the cards through the cameras SDI output.

It's interesting you mention that the EX camera was "not designed for our workflow" which I agree with. However, it should be mentioned that Long GOP was never originally intended to be edited - only for playback. However, companies like Apple & Sony have still done their best to make a "square peg fit in a round hole."

I'll be the first to say you should stay in your native format wherever possible. But in the case of Long GOP, it has been our experience that it simply doesn't provide the same editing performance as an intraframe-based codec like DNxHD. Since our facility is very much based around a collaborative workflow with our Avid Unity - keeping the same performance level across all workstations was an important consideration.

Given that, we want to get our XDCAM-EX footage out of Long GOP as soon as possible. Since software-based transcoding takes far too long - playing the video back in realtime off the camera (or eventually a deck) is a much quicker and robust option. The one obvious advantage of the cards here is that clips can be deleted before the dub to HDCAM begins.

By the way, you mention clip spanning during playing back from the HDSDI output - unless I have missed something, somewhere - this doesn't seem possible, unfortunately.

SG