- December 3, 2014 at 6:12 am
Not sure about that. My delivery to Discovery is still Quicktime. DNxHD 145 QT, but QT nuntheless. Several cameras shoot QT. QT is still a deliverable to end users in some cases…for playback on iPhones or iPads.
Do you mean professional grade codecs? Intermediates for editing? Camera masters?
Little Frog Post
Read my blog, Little Frog in High Def
- December 3, 2014 at 11:58 am
Lots of cameras shoot MXF. The Sony HDCAM SR and XDCAM EX line comes to mind. I’m thrilled because I collaborate with shooters that have cameras like the Sony EX3 and now I can import their MXF files natively. So this is a big improvement for my workflow.
Also because editors with PC’s can’t create ProRes files, some post houses have been accepting XDCAM HD422 50Mbps MXF files instead.
- December 3, 2014 at 12:54 pm
.mov will be around, but yes, this is a big step for Apple. It seems to have taken a really long time.
- December 3, 2014 at 1:21 pm
“Do you mean professional grade codecs? Intermediates for editing? Camera masters?”
I’m talking about professional acquisition post and delivery. I think ProRes will be around and QT as a wrapper will hang around as well. But pro users have long lamented about QT gamma shifts and are eager to move to something else. MXF is the most acceptable wrapper outside of MOV and is widely used. With MXF, you now have native interoperability of media files among Apple, Avid and Adobe without rewrapping. Probably Autodesk and Quantel, too. As a test, last night, I could easily import DNxHD MXF files from an Avid MediaFiles folder directly into X.
I think once this starts to resonate with facilities and broadcasters, it’s going to be a very big deal. If you look at camera vendors, like ARRI for example, there’s no reason not to offer MXF-wrapped ProRes files now. In the end, moving away from QT has a lot of advantages for pro users.
Of course, as we all know, standards are often ignored and each broadcaster has their own particular specs. It’s nearly impossible to create one distribution file and have it be valid for a range of broadcast outlets. Heck, I just did a set of spots and had to create 8 variations to cover all the local station specs. And that was still “generic”.
So, I applaud this move as hopefully one that will put some sanity back into the post environment.
Oliver Peters Post Production Services, LLC
- December 3, 2014 at 1:45 pm
5 minute overview from Ripple:
Senior Editor/Post Production Supervisor
Professor, VCU BrandcenterSome contents or functionalities here are not available due to your cookie preferences!
- December 3, 2014 at 1:55 pm
Are there significant advantages to copying MXF directly off the camera card versus rewrapping to Quicktime? I’m not sure why I would do this.
- December 3, 2014 at 2:14 pm
[Oliver Peters] ” thing this does is improve the interoperability between FCP X and broadcast/post SANs and servers, such as Avid Isis.
Absolutely. This finally legitimizes MXF on the Apple platform. MXF4Mac has worked for a really long time, and worked really well. But now that AV Foundation seems to be in full swing, and there’s less and less use of QtKit, this is a decent time for Apple to finally add this capability directly to the NLE.
This also opens up a lot of possibility to other codecs for import, delivery, and cross-platform use. There will be more 10bit codecs other than ProRes. It’s a pretty big signal from Apple.
.mov will become just another wrapper.
Now it’s time to move on to shared storage! 😀
PS No, Scott. It’s not time to change the name of the forum. 😉
- December 3, 2014 at 2:24 pm
[Brett Sherman] “Are there significant advantages to copying MXF directly off the camera card versus rewrapping to Quicktime? I’m not sure why I would do this.”
For me, it’s one less set of media to archive.
I have been using MXF media in fcp7 and X for s long time. With direct MXF import, I don’t have to archive both the MXF and QT rewraps, instead I just archive the MXF. This means if I have a shoot with 2TBs of shoot media, I can archive that 2 TBs, and not 4TBs.
This is separate from backup. You should slways have backups. The nice thing about it is, should something go wrong on your main storage system, you can simply reimport the MXF files directly from backup instead of waiting for all of them to rewrap again. I am curious to see what is going to happen with X’s consolidation commands and MXF.
Log in to reply.