|
|||||||||
|
Thread Tools | Search this Thread |
February 2nd, 2008, 09:38 PM | #1 |
Major Player
Join Date: Jul 2007
Location: West Midlands, UK
Posts: 320
|
What codec are you editing?
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?
|
February 2nd, 2008, 09:44 PM | #2 |
Regular Crew
Join Date: Oct 2006
Location: Vancouver, Canada
Posts: 173
|
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'.
|
February 2nd, 2008, 10:12 PM | #3 |
Major Player
Join Date: Nov 2007
Location: Los Angeles, CA
Posts: 498
|
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.
|
February 3rd, 2008, 04:50 AM | #4 |
Regular Crew
Join Date: Dec 2007
Location: Stuttgart, Germany
Posts: 41
|
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.
|
February 3rd, 2008, 05:17 AM | #5 |
Trustee
Join Date: Aug 2005
Location: Berkshire, UK
Posts: 1,562
|
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. |
February 3rd, 2008, 09:13 AM | #6 |
Inner Circle
Join Date: Dec 2005
Location: Rhode Island
Posts: 4,048
|
Use XDCAM EX settings in FCP.
|
February 3rd, 2008, 09:54 AM | #7 |
Regular Crew
Join Date: Oct 2006
Location: Vancouver, Canada
Posts: 173
|
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.
|
February 3rd, 2008, 10:03 AM | #8 |
Major Player
Join Date: Nov 2007
Location: Los Angeles, CA
Posts: 498
|
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. |
February 6th, 2008, 06:24 PM | #9 | |
Major Player
Join Date: Oct 2001
Location: Washington D.C. Metro Area
Posts: 384
|
Quote:
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. |
|
February 6th, 2008, 07:01 PM | #10 |
Major Player
Join Date: Nov 2007
Location: Los Angeles, CA
Posts: 498
|
Color does indeed do XDCAM on the input side.
|
February 7th, 2008, 01:26 AM | #11 | |
Major Player
Join Date: Sep 2007
Location: Palm Desert, California
Posts: 311
|
Quote:
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. |
|
February 7th, 2008, 01:30 AM | #12 |
Major Player
Join Date: Oct 2001
Location: Washington D.C. Metro Area
Posts: 384
|
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. |
February 7th, 2008, 01:53 AM | #13 |
HDV Cinema
Join Date: Feb 2003
Location: Las Vegas
Posts: 4,007
|
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.
__________________
Switcher's Quick Guide to the Avid Media Composer >>> http://home.mindspring.com/~d-v-c |
February 7th, 2008, 02:57 AM | #14 | |||
Major Player
Join Date: Oct 2001
Location: Washington D.C. Metro Area
Posts: 384
|
Quote:
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. Quote:
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. Quote:
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) |
|||
February 7th, 2008, 05:38 AM | #15 | ||||
HDV Cinema
Join Date: Feb 2003
Location: Las Vegas
Posts: 4,007
|
Quote:
Quote:
Quote:
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? Quote:
__________________
Switcher's Quick Guide to the Avid Media Composer >>> http://home.mindspring.com/~d-v-c |
||||
| ||||||
|
Thread Tools | Search this Thread |
|