MXF is not a format. It is a container, meaning there can be all kinds of different stuff inside. There are seven or eight different smpte formats currently defined.

Sony MXF is a proprietary camera format. It is not intended to be station-ready.

Find out from the station which FORMATS it accepts (MXF doesn't tell anyone a thing) and we can guide you to a solution.

Common MXF formats include Panasonic, Avid, and Apple FCP, which use different codecs. Chances are they don't want MPEG-2.

So, back to the Company?

What station these days wants "HD 1440 x 1080 - 60 i"? Yeesh.

Not to mention mpeg-2 bandwidth demands. ..

DoubleYeesh

Thank you Grazie

I am encoding a lot of times. The result is also NG. I told you that I tried encode the completed file a second time, I tried, but the result was not good.

Thank you Musicvid

What you are talking about is a bit difficult, so I am worried that it is an accurate reply.As you pointed out, I think this is a matter of the MXF container.This problem has not occurred in MXF directly extracted from XDCAM or MXF created with Edius.

HD XDCAM 35（Mpeg2） is the one that the broadcast station has designated, so I have no choice.

Dear ASTAR

I think that there is not much difference between 1920 and 1440. It is the conclusion that the image elite issued that human beings are insensitive to the width. Also, I do not support the data becoming heavy. I think that there are too many people who want to make with anything, 1920 x 1080 50 M. And this is an instruction from a broadcasting station. My customer is mainly CS broadcasting stations, CATV, Internet broadcasting stations and so on. I think that this is high class.

For reference, paste the MXFixer check result of 35 M data created with XDCAMStation and 35 M data created with Edius 5. Both are green display and there is no problem. ※ MXFixer is software to check the MXF structure.

It can be a conclusion that MXFixer is wrong. If so, I will complain to the manufacturer. I really appreciate it when Vegas can be used. Cost performance is good.

MXF Check results for "test_xdcam35m.MXF"

Processing G:\test_xdcam35m.MXF with Fixerscript version 1.1.0.407 : 25 Jul 2016
 

The file contains Version 1 UUIDs, such as Preface/InstanceUID at 0x00000a14

SMPTE 377M-2004 referenced ISO/IEC 11578-1 for a definition of UUIDs; however this has been superceded by the definition in IETF RFC 4122. SMPTE 377-1-2009 now uses this definition. ISO 11578 omitted the definition for 'version 4' UUIDs which are defined by RFC 4122. Many applications rely on the operating system to generate UUIDs and operating systems now tend to use RFC 4122 version 4, to avoid the known security implications of version 1 UUIDs. Ref: http://msdn.microsoft.com/en-us/library/aa379205.aspx Ref: http://www.linuxhowtos.org/manpages/3/uuid_generate.htm

No Errors reported

No Warnings reported

No Errors

Report created by FixerScript

MXF Check results for "test_edius5.MXF"

Processing G:\test_edius5.MXF with Fixerscript version 1.1.0.407 : 25 Jul 2016
 

The file contains Version 4 UUIDs, such as MaterialPackage/Tracks/StrongReferenceTrack at 0x00000bbe

SMPTE 377M-2004 referenced ISO/IEC 11578-1 for a definition of UUIDs; however this has been superceded by the definition in IETF RFC 4122. SMPTE 377-1-2009 now uses this definition. ISO 11578 omitted the definition for 'version 4' UUIDs which are defined by RFC 4122. Many applications rely on the operating system to generate UUIDs and operating systems now tend to use RFC 4122 version 4, to avoid the known security implications of version 1 UUIDs. Ref: http://msdn.microsoft.com/en-us/library/aa379205.aspx Ref: http://www.linuxhowtos.org/manpages/3/uuid_generate.htm

The file contains Version 1 UUIDs, such as Track/TrackSegment at 0x00000ead

SMPTE 377M-2004 referenced ISO/IEC 11578-1 for a definition of UUIDs; however this has been superceded by the definition in IETF RFC 4122. SMPTE 377-1-2009 now uses this definition. ISO 11578 omitted the definition for 'version 4' UUIDs which are defined by RFC 4122. Many applications rely on the operating system to generate UUIDs and operating systems now tend to use RFC 4122 version 4, to avoid the known security implications of version 1 UUIDs. Ref: http://msdn.microsoft.com/en-us/library/aa379205.aspx Ref: http://www.linuxhowtos.org/manpages/3/uuid_generate.htm

No Errors reported

No Warnings reported

No Errors

Report created by FixerScript

Back up the Bus:

JPN "I am in trouble because the station does not receive it."

Were you told "why"? Sure, we all see you sheep-dipped it through this Fixer s/w, but is this error the reason coming from the station? And, BTW, what does, "...the station does not receive it." mean?

Thank you Grazie

That point is appropriate. I was forgotten. Only one broadcasting station is not actually received. That broadcast station uses MXFixer for file checking. In fact, if I deliberately ship Vegas files to other broadcasting stations, they may receive them. I am worried because MXFixer's red display rarely comes out, which means that the file is completely broken. So, I doubt that Vegas is wrong.

Since the UUID of the MXF container points out that it is a problem, I expect that the maker will fix it in no time.

JPN, are you considering that the s/w is now what? When you say it isn't Vegas, are you concluding that it is neither the SONY MXF Renderer also?

I'm trying real hard to juggle the variables you are putting forward. What's your thoughts on the matter?

You appear to have Edius to hand #7.  However; I presume you prefer to edit with Vegas.  Why not output a HQ intermediate from Vegas and then convert that file to an Edius MXF.
Problem solved.