MXF files issues

Rory Cooper wrote on 2/7/2014, 3:31 AM

HI Guys would appreciate a heads up. More frequently I am getting MXF files that I can’t read in Vegas or Sorensen squeeze 9 or Tmpegen .
I can use VLC Player to convert to H264 what are you guys finding success with. I am not sure what cameras are being used as the footage comes down a long pipe from who knows where.

Comments

videoITguy wrote on 2/7/2014, 7:24 AM

as you now realize MXF is a container - not a codec. And it is possible that what you are getting at the end of a pipe is a re-wrapped source making it even more problematic to source it.

Vegas deals with SONY MXF which is an Mpeg2 codec. It is a true digital intermediate like Cineform and not necessarily camera based.
AFAIK - Canon MXF camera sourced from prosumer level is also Mpeg2 based as a direct camera type.

Marco. wrote on 2/7/2014, 1:32 PM

Vegas Pro 12 can deal with MXF containing Panasonic P2 AVC-Intra, MPEG-2 (XDCAM, XDCAM HD, XDCAM EX), DV (XDCAM), MPEG-4 Part 2 (HDCAM SR) and H.264 (XAVC).

If the MXF contains something different Vegas can't deal with it or at least it can't without using certain plug-ins.

Meanwhile some cameras record DNxHD wrapped in MXF. Vegas can read DNxHD if wrapped in MOV (if DNxHD is installed) but not if wrapped in MXF.

Rory Cooper wrote on 2/10/2014, 5:46 AM

Ok, that clears things up.
I always deliver DNxHD wrapped in MXF which has never caused any problems with other editors working with other NLE on other platforms. I incorrectly assumed that whatever we requested in MXF would be encoded and delivered for cross platform compatibility.

In future I will be more specific on requests on my side and also for delivery.

Thanks much appreciated.

ChrisDolan (SCS) wrote on 2/10/2014, 4:59 PM

Rory,
There are lots of kinds of MXF. Sony prefers Op-1a style (audio and video in one file, like XDCAM and XAVC) where Panasonic and Avid prefer Op-Atom (audio and video in their own files, like P2 and many DNxHD files). We have some support for Op-Atom (namely P2), but not everything so many Avid-readable files are not directly readable in Vegas without rewrapping.

More specifically, we don't currently have native support for DNxHD in any container format, let alone Op-Atom MXF.
Chris

Rory Cooper wrote on 2/11/2014, 5:07 AM

Thanks Chris your direction has help me a lot

I only have Op-Atom constraint available with Sorenson which is ok for the Avid pipeline but not good for Vegas so this is where the issue comes in as with Vegas we only have the Mov. Container support so Vegas will handle this as well as Avid. so this is why the delivery side is working but not the receiving side.

videoITguy wrote on 2/11/2014, 6:10 AM

And that is exactly to the point - SCS needs to equip VegasPro to do a better job of coexisting with other digital intermediates ...
see the following discussion:
Subject: RE: vegas pro compatible with adobe premiere??
Reply by: Runaway
Date: 2/10/2014 6:05:20 PM

.....Using AATranslator means that you can convert from one daw to another and back again which means that you don't have to bounce down to stems and move large amounts of audio back and forth all the time. You could for example just record a small solo section to a session and return just that audio clip and the session file rather than bouncing down say 30mb of mostly silence and sending that back.

A simple example I know but like wise you could send your session and audio to another person and maybe all they are doing is applying fades & automation and then all that has to be sent back is the session file and it goes on from there....

Subject: RE: vegas pro compatible with adobe premiere??
Reply by: videoITguy
Date: 2/10/2014 8:13:05 PM

I go back to my earlier observation, SCS has kind of put their eggs in a basket where they are trying to satisfy this to and fro outline that Runaway alludes to. With VegasPro 12 build 770 they want the user of one NLE to suggest the cuts session to another edit suite.

I maintain this is a seldom if ever real world situation that one would encounter between two edit houses. RATHER for large scale projects you employ entities that can do certain things - say I want titling from one house and complex compositing from another. Then the to and fro exchanges are more about format of digital intermediates and such workflow - not composing full composition cuts to another editor.