On Tue, May 29, 2007 1:03 pm, Brad Ford wrote:
> Different ballgame if it's coming from P2 cards. If it's coming from
> P2 cards, it's not "native" DV. It's in an MXF file, and the audio
> is already split out into 8 separate MXF files. So you're going to
> need a layer that understands how to parse MXF before you can even
> write it as a movie. Unless Carbon understands MXF, it won't be able
> to handle media shot on a P2 camera.
I'm not following... we have two options currently:
1) We capture to P2 and leave the files as-is - all of our clients can
take these files and ingest into their P2-compatible NLEs as needed, but
it complicates workflow - file review, naming, etc
2) We capture to P2 and use P2Log to repackage as DVCPRO HD -encoded
Quicktime .mov; this is simple for workflow, with one standalone file per
clip rather than the whole mess of MXF; but then I'm left wondering what
NLEs besides FCP can read these files directly, or if not what products we
need to recommend for pre-processing before ingestion.
If we stuck with P2-native files (MXF) then Carbon isn't even an issue -
our clients will use whatever P2-compatible products they'd like - these
files can be ingested directly just like FCP can.
My concern is if we DO go to DVCPRO HD-encoded .mov files (which I'd like
to for internal workflow simplicity) - then I'm left wondering what
products, if any, our clients can use to ingest this content into their
NLEs. If I can't recommend a sane, reasonable workflow with these DVCPRO
HD-encoded .mov files that works across platform, then I'm back to option
1 :(
Thanks for any more ideas!
_______________________________________________
Do not post admin requests to the list. They will be ignored.
QuickTime-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
