What codec are you editing?

[Daniel Alexander]

Just curious to know some of the work flows you all are taking at working with the footage from this camera. For those shooting in 1080p hq, are you editing in the native xdcam codec or are you transcoding to something else for any particular reason?

[Justin Carlson]

For just about everything I convert to ProRez HQ after I import the Raw footage. Then it makes it a little sharper (and faster) when I edit in in FPS 'Color'.

[Eric Pascarelli]

XDCAM. Seems to work great and I love how little space it uses on the drive. Also, it's nice to just have one copy of everything to keep track of.

[Rainer Mann]

I also use the original XDCAM Files. Importing to FC is so easy and I can start editing immediately. That's one of the reasons I switched from Avid/Windows to Final Cut/Apple.

[Matt Davis]

Originally Posted by Justin Carlson

For just about everything I convert to ProRez HQ.

Have you experimented with the 'render in ProRez' option? In that, for cuts-only, unprocessed footage, you stick with the native format, but as soon as transitions or other twiddles are introduced, they're all done at ProRez at the selected quality. The final edit is exported as ProRez regardless.

Therefore one's editing quickly, no footage gets transcoded unless it needs to, and you've got a frame based codec just when you need it.

[Paul Cronin]

Use XDCAM EX settings in FCP.

[Justin Carlson]

Matt, yes I have and it's a great option to use. Its just that when I grade my footage I tend to add a very soft 'gradual' vignette to my shots so I want to make sure there's the least amount of banding as possible. Thats why I convert all my footage to ProRez. And then once in Color I edit in 32-bit floating point.

[Eric Pascarelli]

Justin,

Wouldn't you get the same benefit from just going into Color in XDCAM and coming out in ProRes? Less conversion required?

I haven't really done much with the EX1 in Color yet but have found this basic concept to work for other codecs.

[Alexander Ibrahim]

Originally Posted by Eric Pascarelli

Justin,

Wouldn't you get the same benefit from just going into Color in XDCAM and coming out in ProRes? Less conversion required?

I haven't really done much with the EX1 in Color yet but have found this basic concept to work for other codecs.

I don't think Color supports XDCAM. Color is a bit pickier about what it supports than the rest of FCP studio.

In any case, while what you are suggesting works well enough when supported, you are imposing something of a processing burden on your system. ProRes decodes easier- and there is hardware to accelerate it.

Its a give and take though. You have to evaluate your circumstances and decide what makes sense for your workflow. I like ProRes all the way through the pipeline for everything where that is practical- starting at acquisition if I can.

Of course in some cases, like say covering a school play or the like, XDCAM HQ is overkill, so there isn't any point in playing around with "better" codecs. Then there are situations where data storage is an issue.

I could go on in either direction.

[Eric Pascarelli]

Color does indeed do XDCAM on the input side.

[Michael H. Stevens]

Originally Posted by Daniel Alexander

Just curious to know some of the work flows you all are taking at working with the footage from this camera. For those shooting in 1080p hq, are you editing in the native xdcam codec or are you transcoding to something else for any particular reason?

A lot of my friends use Cineform - you get full frame rate editing - but for now I am editing the original .mxf files on the time line with no prob on a laptop. get a about 12fps.

I notice you are from the West Midlands - many, many years ago I got pissed in Sutton Coalfield. Just thought you might like to know.

[Alexander Ibrahim]

Originally Posted by Eric Pascarelli

Color does indeed do XDCAM on the input side.

Hrm. Good to know. That eliminates that consideration from my workflows.

So, that being the case... you are saving processing power and that is all. On new fast machines it may not be an issue at all.

One thing I noticed, an ambiguity which may conceal a hidden assumption in your earlier statement about codecs. You are striving to minimize "conversion."

There are three reasons to concern yourself with that. One is time. I can't speak to that. Depends entirely on your system and deadlines. The second is storage capacity. Again your system etc. If either of these are your concern, then you'll find I am being pedantic. Sorry if that is the case.

The third is "generational loss." (More properly its accumulated rounding errors due to color representation conversions... but people never say that.)

If you are using a "quality" modern codec like Cineform, DNxHD and ProRes, they shouldn't cause visible generational deterioration until the tenth or later generation. I mean it- even "golden eyed" viewers standing on the material coming from a D-Cinema projector shouldn't see differences until at least that many generations.

So bringing your data into these codecs as early in the process as practical helps preserve data. This is especially true for the typical acquisition codec, like XDCAM, which is 8 bit and has a paucity of color data and is highly compressed.

Again, sorry if I am being pedantic. Hope it gives you something to consider if you are in the third case.

[Steve Mullen]

Originally Posted by Eric Pascarelli

Color does indeed do XDCAM on the input side.

Which means a huge savings in disk space and disk bandwidth compared to transcoding to ProRes 422 during import. The much lower XDCAM bandwidth should translate into far more real-time streams -- even IF, and it is a if, the long GOP MPEG-2 is slower to decode than ProRes is to decompress.

And, since any effect one adds to XDCAM EX is -- in reality -- being added 4:4:4 uncompressed video, there is no need for any other codec in a workflow.

The choice of how many bits are used for FX rendering is determined by the setting you choose for FCP. It is not determined by the source codec. However many bits are in the source are simply used when 32-bit rendering is used. Only when 32-bits are down-converted to the OUTPUT codec does the format play a role. Since ProRes is used for OUTPUT, you automatically get 10-bits.

Moreover, by waiting until an effect is actually applied to a clip, the needless transcoding from MPEG-2 to ProRes is avoided. You save the compress and decompress to and from ProRes. There is, no matter how you work, a decode of MPEG-2.

[Alexander Ibrahim]

Originally Posted by Steve Mullen

Which means a huge savings in disk space and disk bandwidth compared to transcoding to ProRes 422 during import. The much lower XDCAM bandwidth should translate into far more real-time streams -- even IF, and it is a if, the long GOP MPEG-2 is slower to decode than ProRes is to decompress.

You are assuming that real time playback is entirely bound by disk bandwidth.

That is not a good assumption. Even very high end computers can only handle a fixed number of video streams.

There are two other ways in which a computer is limited. The first, which I refer to, is CPU limiting. That still happens for a lot of systems with HD video.

The second is decoded bandwidth limits. You may only be storing 35Mbps on disk, but when the computer decodes it, you essentially have to sling an uncompressed video around the various system busses out the video ports.

Finally- it isn't so much an if that ProRes decodes faster than just about any long GOP format on the same hardware. This leaves aside issues of hardware acceleration.

And, since any effect one adds to XDCAM EX is -- in reality -- being added 4:4:4 uncompressed video, there is no need for any other codec in a workflow.

Not strictly true. In fact its only true if you have a 4:4:4 codec for the timeline.

Any effect you add to a time line is calculated based on uncompressed video... but at the bit depth and chroma sampling of the source sequence.

Motion, Shake, After effects and other graphics/compositing software behave differently. They do everything at 4:4:4 uncompressed, then throw away data right before output, exactly as you suggest.

The choice of how many bits are used for FX rendering is determined by the setting you choose for FCP. It is not determined by the source codec.

Actually in all but one case the FCP setting bases its calculation precision on the codec for the source material. Only the last radio button gets you high precision YUV calculations all the time.

On most machines this exacts a huge performance penalty, which is why Apple included it as an option and set the default as it did, only using high precsion YUV on high precision YUV source materials.

Examining this high-precision YUV, what actually happens is that FCP (its the same in any editor) will calculate in higher bit depth- but with the same chroma subsampling of the source codec.

So, for XDCAM HQ materials, which are sampled at 8 bit 4:2:0 you merely gain the advantages of using 10 bit 4:2:0, but with 8 bit data.

If you transcode to ProRes, you still have 8 bit 4:2:0 data, but the editor will operate on it as 10 bit 4:2:2 data.

The question is how useful the extra headroom will be. In a lot of cases it won't be useful at all.

If you are using XDCAM EX HQ footage, then you should dial back the settings in FCP most of the time. The same reasoning means that you shouldn't bother transcoding into a better codec most of the time.

When is it useful?

When your footage is going to be handled time and again in your post workflow. i.e. your typical film workflow. Of course in these workflows you will usually acquire in a better format. Indie films are often acquired with ENG quality codecs- because thats what folk can get. In these cases transcode immediately to a better codec.

A lot of users here don't have anything near that complex- so it isn't useful. A lot of diskspace and CPU power get burned for no reason. It literally won't make any visible difference for a school play. (as an example)

[Steve Mullen]

Originally Posted by Alexander Ibrahim

You are assuming that real time playback is entirely bound by disk bandwidth.

I made no assumptions at all. I merely stated a fact. The disk bandwidth for XDCAM is much lower. I said long-GOP might be slower, but might not be. The Intel chips have instructions to speed MPEG-3 decoding. Someone should test.

Not strictly true. In fact its only true if you have a 4:4:4 codec for the timeline. Any effect you add to a time line is calculated based on uncompressed video... but at the bit depth and chroma sampling of the source sequence.

With the new Open Timeline, I think the Sequence codec has nothing to do with FX rendering. No matter the source codec, when a clip is decoded or decompressed, it becomes uncompressed video. If necessary, as for XDCAM EX, FCP performs the necessary computations to up-sample chroma to 4:4:4.

Actually in all but one case the FCP setting bases its calculation precision on the codec for the source material. Only the last radio button gets you high precision YUV calculations all the time.

According to Apple docs:

1) 32-bit processes both 8-bit and 10-bit source files.

2) Because of the longer computation time for 32-bit, Apple recommends turning it on only for the final render(s).

How can multiple 8-bit values be computed in only 8-bits? The intermediate calculations must be performed in 16-bits. Likewise, 10-bit values can't be computed with only 10-bit intermediates. Something seems wrong in Apple's description.

PS: I wonder what happens when 8- and 10-bit are mixed?

When your footage is going to be handled time and again in your post workflow. i.e. your typical film workflow. Of course in these workflows you will usually acquire in a better format. Indie films are often acquired with ENG quality codecs - because thats what folk can get. In these cases transcode immediately to a better codec.

If the vast majority of the footage will be moved from application to application you are totally correct. I was thinking of workflows where only short segments are moved to other apps. In this case, it seems space efficient to render only these segments in ProRes HQ. In fact, if one moves material that has already been CC with Color -- it's already ProRes.