What Is So Crucial About Supporting MXF Natively?

David Saraceno

David Saraceno

Moderator
Staff member
Could someone explain this to me?

How is my workflow compromised in any significant manner or somehow less advantageous in FCP if MXF is not supported natively?

I don't really see this as a huge issue, but it might be my ignorance.

Thanks
 
From my perspective this is the issue... you're shooting footage on a P2 card and offloading it to a P2 store or an external hard drive, with Windows and Edius or Liquid (for std def) you can plug that P2 card or P2 store or Hard drive into the computer and drop clips right onto the timeline. Apple has been making people copy the MXF file to a new MOV file before it can be used. No big deal for a 30 second clip, but if you have two hours of footage you're going to be waiting a while.

Also with Edius, all metadata is maintained throughout the workflow. The HVX and P2 give us the capability of adding the shooters name, location, scene number etc. etc. to the clips. Apple throws all this data out but Edius retains it.

Hope that makes sense.
 
Crucial...I don't think its crucial.

I do think its space and time saving though.

a) You aren't wasting time and processing having fcp convert and duplicate the mxf files to .mov

b) you are taking up even MORE hard drive space with the now duplicate .mov files.
 
The Sarlacc said:
Crucial...I don't think its crucial.

I do think its space and time saving though.

a) You aren't wasting time and processing having fcp convert and duplicate the mxf files to .mov

b) you are taking up even MORE hard drive space with the now duplicate .mov files.
Click to expand...

you need to put the footage on a HDD and off the P2 anyways

and 2 hours of footage on a p2? at most 16gb from 2 8 gb cards is only about 1 minutes of transferring
 
With the improved features in FCP 5.1.2 I don't think native MXF support would bring that much to the table.
Especially with the clip spanning it's prefereble to have them assembled anyways, and FCP will do that automatically now.

And if you use the firestore you'll be able to record directly to QT in firmware V3 and that you can drop directly to the timeline.
 
As a shooter, I am sure it makes sense to stay in the MXF world. Especially if you are one-man-bandin' it and don't need to interface with other post departments or share media.

As an editor, which I am most of the time, it makes more sense to have one piece of media to deal with. If there is an actual change in the picture quality then no, but as long as the image is converted cleanly then one file instead of folders of files is better.

Alot of people keep mentioning Edius or sometimes Vegas here, but as an editor I will tell you that this is primarily a FCP/Avid world with a little Premier, Discreet and small slices of the others.

If you are commissioned to do a show for a network, you will have to turn over EDL's and all the footage at the end of the project for the client to keep in their archives. Currently, I am not sure anyone accepts MXF as archival. I know Discovery networks has specifically stated that P2 captured media should be transfered to tape for easy conventional access later. Sometimes that can be negotiated, but still...

All the comments about conversion time and additional media space are perfectly valid, but it still doesn't address that MXF is not currently an accepted part of most professional post-production workflows.
 
Cynic821 said:
you need to put the footage on a HDD and off the P2 anyways

and 2 hours of footage on a p2? at most 16gb from 2 8 gb cards is only about 1 minutes of transferring
Click to expand...

Not sure what you are saying here.

I always go straight from the P2 card to an external drive. 2 for redudency usually.

But when I have 25gb of files....it becomes 50gb when I dump them into FCP and they convert to .mov
 
Sproketz said:
.

All the comments about conversion time and additional media space are perfectly valid, but it still doesn't address that MXF is not currently an accepted part of most professional post-production workflows.
Click to expand...

Well, neither is quicktime, or wmv etc etc. none of them are.

But remember this is all new and still knocking the industry on its keister. Things will change over time. And it will happen rather quick I'd imagine or else the industry risks lagging behind.
 
Thanks John.

The Axio pdf is just a different workflow.

I guess I'm not seeing the importance of native MXF support in using p2 based footage.
 
MXF was intended to be a universal file type so we'd all stop having to worry about AVI, QT, whatever. As others have said, having to convert every file you shoot not only takes more time in post but also more HD space. I don't see how you can dismiss that. It also bugs me for archiving purposes. I like just being able to burn my P2 contents to a DVD and have that for archive. Having to burn both the MXFs and converted QT files is going to be a bit more of a pain. FCP can still work with the HVX200 but, without native MXF support, it's always going to be more cumbersome. It's just the nature of having to convert files.
 
DavidBeier said:
Having to burn both the MXFs and converted QT files is going to be a bit more of a pain. FCP can still work with the HVX200 but, without native MXF support, it's always going to be more cumbersome. It's just the nature of having to convert files.
Click to expand...

1) Why would have to burn both MXF AND Qt files??? That is a waste of time, money, and media. You should only need to burn the MXF files for archiving. Should you ever have to refer to them again, FCP will just convert them to QT again at whatever drive you designate in the future. OR should you need Avid or another system you still have the original MXF. If you only ever intened to use FCP and nothing else then by all means just burn the QT. But no need to burn both.

2) FCPs handling of P2 is not in anyway cumbersome. But there is the conversion process which just slows you down by a couple minutes. Its not a big deal at all, but it if you could eliminate it completely that would be best.
 
David S. said:
I guess I'm not seeing the importance of native MXF support in using p2 based footage.
Click to expand...

That's because you probably haven't seen how it could be done. It's an eye-opening experience.

It's like people who are still content to shoot on tape; they don't "get" why tapeless is so much better until they spend five minutes trying it.

I've been harping on it recently because I just finished working on two big projects that were all Mac-based, and I find it hard to understand why people put up with the inefficiencies and workarounds "just 'cause it's a Mac." It's silly.

It's really night and day. And once you step into the day, you won't want to cower in the night anymore.

Native MXF support delivers on the promise made by a tapeless workflow. The Apple/QT conversion system is really only a half-step removed from tape/capturing/digitizing etc.

Here's the deal with MXFs: If you have clips that span multiple cards, MXFs have pointers to link the two files together, so that if you import that file on a system that has native MXF support it brings it all in as one clip, seamlessly. With the QT system you have to manually find the pieces of the clip and lay them end to end on the timeline. And how do you do this? By timecode I guess? Silly. Pointless. Why not take advantage of the system that already does it for you?

What if you have a lot of footage. Hundreds of gigabytes, for example. You've been shooting for three weeks, offloading cards as you go, onto external FAT32 hard disks. maybe three 300gb drives. On an MXF-aware system like EDIUS you would plug those hard disks into your editing station and begin editing the footage, immediately. On the QT/Mov system, you'll have to first make sure that you have another terabyte somewhere because you're going to have to duplicate all the files. Then you have to babysit the system, telling it to "import P2" for each and every volume. How many volumes is this? How many cards did you shoot? In 900gb, using 4gb cards, that could be 225 import procedures. Each one taking about 4 minutes. So kiss 900 minutes goodbye (assuming 100% efficiency), or about two full days of sitting there babysitting while you have to copy each and every card directory over, importing them one at a time. Heck, you might as well be capturing tape at that point, because that stage of the workflow is about the same. Yet it's absolutely unnecessary, because in an MXF-aware app you wouldn't do this at all, you'd just edit.

Then there's editing from the cards. If you have a small enough project you could edit directly from the card. The card is fast enough to support up to six streams of high-def being streamed from the card. May not matter much with a 4gb card, but once the 16's and 32's come out, this starts to become a real possibility. Except -- not on the Mac, it will never be possible. Just another apsect of the workflow that gets discarded because the Mac won't work with MXF files.

What about writing back to the card? On Edius I can export directly to the card, or export an MXF file back to the hard drive for archival purposes. Can't do that on the Mac. The only thing you can do on the Mac is "print to video", which will output back to the card, but only as a 720/60p or 1080/60i stream. What if I have 40 minutes of presentation in 720/24p mode, that I want to write back to my two 8gb cards? Can't do it on the Mac, because it doesn't support the MXF export. EDIUS could do it, other native MXF-aware apps could do it. But the Mac would be limited to outputting 16 minutes. Again, maybe not that big of a thing, but: why? Why do I have to put up with this? Just because "it's a Mac"? Why can't they just go the extra step of adding native MXF support?

Then there's the metadata -- you can name clips and shooters and locations, take numbers and scene numbers, all sorts of things. Except that the QT/Mov workflow discards all that. Want to know what frame rate a clip was shot in? Oops, that info's gone. Want to know what camera this particular take was from? Oops, that info's gone, sorry, QT doesn't provide for that.

Now, with that said, it appears Apple will be addressing some of these things in 5.1.2. Apparently it will know how to string spanned clips together, which is a nice update. But you'll still have to go through this same process.

Here, let me ask it this way: would you be content to only be able to import PICT files on the timeline? What if FCP didn't allow direct import of JPGs? Would you find it completely acceptable that for every JPG you wanted to use, you had to open up Photoshop, import the JPG, and export it as a PICT? That would be pretty goofy, wouldn't it? PICT is Apple's format, why don't they force you to convert everything to PICT? Or audio -- what if every .wav file you wanted to use, they forced you to open up ProTools and import the wav file and export it as an .aif file? If they designed FCP so it could only import .AIF files, that's what you'd have to do, and I bet you'd see that as inefficient, clumsy, and pointless, and you'd much rather just drop a .wav or .mp3 on the timeline. Oh wait -- you can!

Same thing with MXFs. Those who haven't seen it done on the right way don't see what's wrong with the current way. And hey, I guess that's fine, if you're happy then you're happy. But it could be so much better.
 
Last edited:
Thanks for the update Barry.

As I read your post, I see that MXF native support is important in certain scenarios, but does not seem to be as important in others. At least to me in my workflow.

5.1.2 seems to address the issue of spanned files on two cards.

In those shops where large amounts of footage are routinely acquired, the current version of FCP or any NLE that doesn't have native MXF isn't advised.

When you indicate "editing from the card," are you referring to it while mounted in the cam or the p2 store, or something else?

The one issue I agree with you is support for writing back to the card. I wish this were possible using FCP or some Mac based conversion utility that could take an export sequence or export a sequence to MXF file format.

I'm not certain your PICT analogy is on point, but I do understand what you are saying.

thanks
 
David S. said:
When you indicate "editing from the card," are you referring to it while mounted in the cam or the p2 store, or something else?
Click to expand...
I'm referring to leaving the footage on the card and editing directly from it. Which could be from the 5-slot reader, or a laptop's PCMCIA slot, or from the camera in PC mode; anything.

The footage is digitized and edit-ready right on the card. So why not edit from it? Why not skip the whole transfer-to-computer, unwrap/re-wrap silliness? When the cards are big enough to support that as a practical matter, that's certainly what I intend to do. Of course, I can't do that on a non-MXF-aware application.

It's just a file wrapper, folks. It's not re-inventing the wheel. If little pipsqueak EDIUS can do it (and note: they did it *before* they were bought out by Grass Valley) then why can't big bad Apple do it?

I'm not certain your PICT analogy is on point, but I do understand what you are saying.
Click to expand...
It's very close to being on point. The only differences are that A) exporting a PICT is instantaneous, instead of taking 4 minutes per card, and B) you don't have to run a separate application like PhotoShop to import a P2 card. Well, actually you do, but it's internally launched.

I'm not picking on the Mac or saying that it can't be done on the Mac. I'm saying it CAN be done, they just have to implement it. And I don't understand why people would want to settle for a lesser implementation instead of demanding better. Take what they give you, yes, but don't be satisfied until they've done it RIGHT. I harp on it because 80+ % of HVX users appear to be using the Mac, and it's just so silly that they're not able to take advantage of the system properly because Apple has yet to implement a file wrapper.
 
Barry_Green said:
I harp on it because 80+ % of HVX users appear to be using the Mac, and it's just so silly that they're not able to take advantage of the system properly because Apple has yet to implement a file wrapper.
Click to expand...


That's my guess as well.

What is interesting, however, is that Panasonic's firmware updaters, and viewers are PC only, when at least here, the lion's share of users are Mac users.

C'mon Panasonic (and Apple for that matter.)
 
You must log in or register to reply here.
Back
Top