[LewK2]

Hi,

I've been working with the MXFLib code for a week now (after diving head-first into the excellent book (cunningly name 'The MXF Book") that contained Matt's section on using MXFLib.

I've been working to build a simple command-line app similar to MXFWrap but with far less options that kicks out Avid Adrenaline OPAtom files.

I *think* I've managed it, with my MXF file now matching very closely some sample Panasonic P2 files and my Avid accepting the file and all it's metadata (that took some tweaking...).

However, that ran me most directly into a brick wall - all my testing has been done with a P2 PAL DV 411 file (DVCPro I believe), and it turns out that MXFLib does not happily embed this essence. I've since taken a snippet of DV 422 (vanilla DV) and I can't unwrap that properly either - I just get the first frame back from the file. The MXFSplit tool seems to unwrap it OK, but it sees the essence as a RAW format and not DV-DIF (but a simple file rename fixes it all). But the Snell & Wilcox MXF SDK does not unwrap it, nor can the DirectShow filter I have installed.

Am I doing something stupid - has anyone wrapped a plain .DIF file with either MXFLib or MXFWrap and gotten any other apps to read it?

I'm about to go and investigate it further, but seeing as I definately can't round-trip the file even with the unmodified binaries distributed on SourceForge, I don't think it could be me being stupid

I'm happy to post any samples needed; it's possible that the MXFLib is the only thing writing the files correctly and the Snell SDK and Avid are being naughty - but I thought it'd be a good thing to make this post anyway...

Cheers

Lewis Kirkaldie (Ex-BBCT bloke working for Siemens now).

[LewK2]

I *think* I've found it - first clue was that a clip wrapped DV file when looking at the BER length of the clip wrapped DV section was the length of a single frame!

The constructor for the Stream object sets the WrapType by default to StreamWrapOther. Later, when the essence writer comes to lay down the essence within the MXF file, it checks to see if it is clip wrapping or frame wrapping from this stream flag, hits the 'Other' type so reverts to wrapping in as a Frame.

The function SetStreamWrapType never gets called in mxfwrap.cpp (and hence I didn't replicate that in my P2 MXF OPAtom simulator), and adding a call to that means the essence writer correctly processes the dv as a clip wrapped essence (now matching the rest of my headers and metadata) and it works!

Now, of course, the only question is; do I walk into work to get borrow an Avid dongle and test my new MXF in the Adrenaline?

Sorry to all of you reading this that don't care - I'll go back in my hole now.

Lew

[Matt Beard]

Good catch

I have added back the code that sets the wrapping mode to clip wrap (It existed in a local copy, but never seems to have made it to SourceForge!)

I think that I now get properly clip-wrapped DV essence.

This leaves a couple of questions:

* Why can't the Avid and Snell decoders read the frame wrapped DV file?

* What is the problem with the PAL DV (4:1:1) ? - It would help me if you can send me a small sample of the DV to try.

[LewK2]

The avid won't read frame wrapped because it uses only clip wrapped opatoms as it's native MXF formats (although I've not tried switching my working clip wrapped ones back to frame wrapped - they might work, and it could have been some other issue stopping it before).

It's worth noting that most of my knowledge about the avid MXF formats are from MXF Dumping files I generated with it - not from hard and fast specs.

As for the Snell decode - it can read the essence when it is frame wrapped properly - it's only when it was half and half (marked as clip wrapped in the preface and coded as clip wrapped) that it failed.

To get some sample stuff, just google for P2 MXF Sample Files and you'll find some on the OpenCube web site - I've been using that content. I can gen anything else you might need though.

However, there are a couple of other impediments I found - possibly because the P2 and Avid implementations are strange. The first problem stopping the direct-show filter rendering DV MXF correctly was MXFLib putting DV essence on a data track instead of a picture track. It seemed to make these other tools see the essence as RAW - moving it to a picture track fixed that (and made it match the P2 implementation).

The other problem was the lack of EssenceContainer and PictureCoding ULs in the DCIEssenceDescriptor group - without these the Avid just listed the Video in the MXF as 'unsupported'. A quick change to the esp-dvdiff.cpp file to write the correct labels in (dependant on formats) fixed this - I can send it to you if you want.

During the course of my mimicking the P2 structure, I changed a large number of things when lifting code from the mxfwrap files - and since a lot of the changes didn't solve the overall 'why wont you work in the Avid' problem, I've no idea if they are important or not. However, I can send you a sample of my wrapped DV and the code for my atom-wrapper if you so care (it might be easier if the fixes were just rolled into mxfwrap).

My current plan is to extend the code I have a little to set the starting timecode of a given DV clip, support the addition of referenced WAV clips in other atoms and then run with this in my lab as a demo of Avid integration - I've already hooked it to the Colledia system we have to spit lumps of DV into the Avid, and I have a request in to get some other MXF samples from Avid with vanilla MPEG-2 in it (in order to try and get other formats to work in this way - I know IMX-50 wont currently wrap, and I need to look at that yet).

Still, funtimes, and thanks for your response (and the huge amount of work you must have put into making the library).

Oh, and the other thing I should warn you - I'm a C# programmer normally, and am pretty useless / scared by CVS. Please don't judge me on the quality of my C++ hacking - my main critera in the little project has been to get stuff working in a week... and it shows in my code!

Cheers

Lew

[LewK2]

Oh, and it turned out there was nothing specifically wrong with the 4:1:1 DVCPro stuff - it was all the fault of the clip / frame wrapping snafu.

I'm now wrapping SMPTE314M and IEC DV files.

Lew