[Andy Mees]

ha ha … they’re probably getting a great deal on those cameras as no one else is buying them.
when Al Jazeera International geared up in mid 2006 they were using the 510’s, but only as a stop gap until the 330’s were shipping in large enough volume … hmmm, I wonder if ABC’s new cameras are ex AJI 😉

[Andy Mees]

you might want to double check whether Adobe have the quicktime codecs for XDCAM … I’ve a feeling that you’ll need to purchase FCP to get the codecs

[Andy Mees]

OS X puts its QuickTime components into the /System/Library/Quicktime folder … you should leave anything and everything in the /System folder well alone. Danger, Will Robinson!

FCP puts its QuickTime components into the /Library/Quicktime folder ( and this is where you should put back any FCP QuickTime components you may have moved) — this is the Public library as it were, with access granted to all applications run by any user

The final library folder is in your user folder at ~/Library/Quicktime folder — this is a Private library that only applications run by your user can access, so any components you place in here will be accessible only when logged in under your user account.

[Andy Mees]

indeed. i’ve never understood why there isn’t a simple checkbox option in the speed dialog to “preserve duration”

… when i make a “constant” speed change I’m not permitted to lock the duration, and when I make “variable” speed change I’m forced to lock the duration. there’s certainly no technical reason why I couldn’t have my cake and eat it, but Apple seem to want to force me to diet

[Andy Mees]

thanks Pelai
appreciate the response. its certainly food for thought as you’re practicing quite a different workflow than I use myself when working with XDCAM HD …. time for further experimentation.
cheers
Andy

[Andy Mees]

What I am saying is that when editing HDV material in an HDV sequence you get the choice of changing your rendering settings to Prores within the HDV sequence (Not the same thing as having a Prores sequence)
Why you would do this is because if you render as HDV, rendering times are much longer and this option permits you to work faster.

yep. we’re still n the same page at this point 🙂

The problem arises once you have finished your editing and want to export it:
If you then have your whole timeline rendered with option to render as Prores and now try to export selfcontained or reference your exporting times go bonkers: 8hours.
Why? Because it doesn’t just export referencing renderfiles but recompressing the whole thing once again.

thats correct … when you export an HDV timeline either self-contained or referenced, and regardless of the render codec, then FCP has to conform that timeline to a single file that conforms to the Long GOP structure. My guess is that the 8 hour render time you see is the estimation of how long it will take to conform your 32 minute sequence.

Solution:
If you on the other hand once finished your editing delete your Prores-rederfiles and rerender your hole timeline as HDV (change your rendering option to same as sequence codec). It will take a while. But once you try to export exporting times go down to 5 for selfcontained and 2 for reference.

interesting. how long is “a while” for you? and are we still talking about a 32 minute timeline? what are your render settings ie Need Render, Proxy, Preview, Full etc ?

Your second option is to change your sequence settings or drop your edited clips into a Prores sequence. Rerender again. And this time exporting times will be very short as well.

correct. the export times would be consideraby shorter now as you are rendering to the much faster ProRes codec rather than having to conform to HDV’s Long GOP structure

I asume by all this that the Prores-rendering option in an HDV sequence is only a meant as a temporary-while-editing solution by apple to help you work on your editing much faster than if you had to render to HDV while you were editing. It is not intended that you export a sequence from these renderfiles and therefore problems arise when you try.

yes, it is a solution to make your edit process much faster but as far as I know you are not expected to have to change this for output … although your own experience suggests that this deserves testing

One more thing that makes me wonder what kind of Prores codec the rendering option in a HDV sequence gives you is that if you try to put an HDV Prores-rendered clip (from HDV sequence) into a Prores sequence. FCP will automatically tell you it needs rendering weather the sequence is Prores 422 or Prores HQ, 8bit or 10 bit.

now that is interesting. again, that deserves testing … it could be a universal thing, or it could be part of the problem that you are having.

Hope it’s a bit clearer now.

a bit 🙂

[Andy Mees]

well that’ll learn me eh?

although sadly, unlike Pavlov’s dog i will probably never learn 😉 thanks Colin

[Andy Mees]

actually its all seems a bit suss Walter

apparently there was horrendous render times reported when exporting a 32 min HDV timeline with timeline renders set to ProRes … well regardless of the timeline render setting, exporting a 32 minute HDV timeline is going to take a very long time (can we all say “conform” time?)

but when resetting the render codec to HDV then the export time was reduced to 5 minutes … for a 32 minute HDV timeline? boy, i’d like one of those Macs 🙂

which bit did I miss? there has to be something so I’m ready and willing to be corrected

[Andy Mees]

i think you’d find that in practice that there is precious little if any difference in measurable performance gain when rendering to a separate hard disc regardless of whether its on the same bus or not, as the bottleneck is likely to be the actual render time not the fact that you are reading from and writing to the same drive. theoretically tho it all makes sense.

[Andy Mees]

>Trying to render from one format to ProRes always adds a lot of time.

ahh, but what if the time to render to ProRes is signifcantly faster than the time to render to the native format (MPEG HD Long GOP) …. thats the crux of the biscuit here i think