|
|||||||||
|
Thread Tools | Search this Thread |
October 8th, 2009, 05:58 AM | #1 |
Tourist
Join Date: Sep 2009
Location: Berlin, Germany
Posts: 2
|
What affects the sequence compression codec in FCP finally?
Hello,
At first I would like to say Hello to everybody here around. I am new to this website. And as usually somebody who is new to this starts with a stupid question: I ask myself after working around with FCP for a while now: what does the compression codec parameter in the sequences settings affects finally? Just to clear this at first: I know what a codec, pixel ratio and display ratio and containers are, and so on. It is more a "way of thinking" issue what confuses me sometimes depending on transcoding steps in the editing and exporting process. I mean, when I start editing a DV PAL file in a sequence timeline and I choose several compression codecs I know (like ProRes or Sheer or Uncompressed or DV) to edit in a sequence, it only seems to affect the realtime rendering needs for preview in editing. When I export or send to compressor to get a H.264 file, the sequence setting doesn't seem to affect anything finally (apart from format and ratio you may have choosen with it of course), because it renders the DV file from the harddisc finally to a H.264 file, isn't it? Or ist like this?: Does importing a DV file and working on it in a seq timeline set up as ProRes 422, and sending it to compressor to get a H.264 Webcasting file afterwards, result in TWO (2!) transcodings? The first is, the rendering of all effects and edits at the DV file from the seq timeline to a ProRes 422 encoded renderfile, and the Second is, the transcoding after all to H.264 again? What means, two transcodings instead of one, in terms of quality loss? Or are there always 2 transcodings anyhow, even if I use DV compressed footage on a DV compressed timeline? It would imply that there is a no way to increase the number of compressions or re-compressions? Than DV->ProRes->H.264 would be better than DV-> DV->H.264, isn't it? Is that the reason, why so many cutters are working on a uncompressed timeline with DV material, because color grading on a uncompressed or ProRes file is more efficient than on a DV compressed one, while there is no way around the 2 transcodings in the whole process anyhow? (let us leave out the question of harddisc space for rendering files) Can anybody clear for me this thinking coordinates. Thanks a lot for all ideas and hints Best regards Last edited by Britta Leuchner; October 8th, 2009 at 06:37 AM. |
October 8th, 2009, 07:01 AM | #2 |
Inner Circle
Join Date: Sep 2002
Location: Vancouver, British Columbia (formerly Winnipeg, Manitoba) Canada
Posts: 4,088
|
Willkommen!
- If you start with DV material (a compressed INTER frame codec - all compression takes place within a single frame) and place it on a DV timeline, no transcoding occurs. - If you filter, effect or add transitions to your DV clip in a DV timeline, you need to render the "new" material - the dissolve did not exist before so it needs to be "created". Likewise, the colour corrected clip did not exist so IT needs to be "created". - The more loss a codec inherently has, the more degradation you MAY experience by adding filters. If I know I will be doing a lot of colour correction, text on screen or other items that require render, I will often use a higher quality codec to edit in. This is called "bumping up". In your example, capturing DV material and editing in ProRes makes a LOT of sense if you are going to add graphics, fine line text or a lot of colour correction. - If you add a DV clip to a non-DV timeline, for ULTIMATE quality and playback, you need to ender to create the clip that doesn't exist (for example your DV media of a horse jumping doesn't exist in ProRes until you render it). There are exceptions. - If you are editing with INTRA frame compressed media (like MPEG-2 or HDV where all compression takes place over a "group of pictures"), any changes to the stream need to be rendered (or Conformed in FCP language) because the stream has changed. To answer your question: if your final output is to be h.264, you still need to consider the workflow. If you are adding a lot of effects, graphics or colour correction, you may want to "bump up" to ProRes. I find text on screen particularly benefits from not using DV.
__________________
Shaun C. Roemich Road Dog Media - Vancouver, BC - Videographer - Webcaster www.roaddogmedia.ca Blog: http://roaddogmedia.wordpress.com/ |
October 8th, 2009, 07:55 AM | #3 |
Tourist
Join Date: Sep 2009
Location: Berlin, Germany
Posts: 2
|
Thank you for your detailed answer
Shaun,
Thank you for your detailed answer. That makes many things in my head much clearer. And BTW Yes, text and DV isn't a good couple - I remember that. Willkommen back to you :-) So after all what you sad about the workflow, it seems there are def. two transcodings happening in background logically. One to "create" the file as we've seen and edited it in seq timeline, and one for the choosen output format afterwards. So it makes sense to keep on the frequently auto-render option in background for parts which doesn't need to be rendered again. What if I def. know that I only will need to output a H.264 from a pre-production showreel to show it's webcasting? Would you prefer ProRes, Uncompressed or Sheer or something else, also with an eye on the timecosts? From efficience, isn't the time it costs to transcode ProRes and than to H.264 webcasting questionable, if we know that this edit version will onlyexist as H.264 finally? Is there any other codec working better at the compromise btween good quality result with text and color correcting and faster rendering than ProRes by targeting H.264? Shaun, Thank you for bringin' my head in the right direction. I think I am close to finding the right workflows on two three points here ... Do you think Sheer is good like ProRes, is it maybe faster? |
November 27th, 2009, 08:04 AM | #4 |
Tourist
Join Date: Aug 2009
Location: Bucharest, Romania
Posts: 1
|
apple pro res
I work with Apple Pro Res 422 HQ. Encode tga files with QuickTime using Apple Pro Res 422 HQ without gama correction. The sequence in FCP is made with the Apple Pro Res 422 HQ no gama correction. When do freez frame in line, this still frame is brighter than the rest. If encode TGA with Apple pro res 422 HQ gama correction AUTO, then there is no difference in brightness between still image and the material. But here another problem arises. Material encoded with gama corectio AUTO is lighter than the original image.
I receive the tga files from the PC. All the best Viorel |
| ||||||
|
|