I've uploaded the files to rapidshare here: 
http://rapidshare.com/files/166317581/Avid_MXF_files.zip.html

Since rapidshare sucks, I would appreciate if someone could mirror this somewhere else that has decent bandwidth.

Thanks Owen, this is much appreciated. I have downloaded the files and will make sure we put them online on the gstreamer website and that Sebastian gets access to them for testing.

Thanks, I've downloaded them too... They don't work yet but I'll get them working, don't worry ;)

Owen, a quick question is Avid 1:1 codec the same as DNxHD? (if not would you mind also putting up an Avid file with that codec inside)

1:1 != DNxHD

I've uploaded 4 files.  They are all 1080p/23.98 at different bitrates of DNxHD:  36, 115, 175, and 175 10-bit.  Each file is 1 second long.

(You may see reference to other bitrates, specifically dnx 145 and 220.  I believe these are the same as 115 and 175, but since they handle 30fps instead of 24, they are 1.25x as large.  It's not simple variable quality like jpg, it appears to be three distinct formulas)

http://rapidshare.com/files/167029685/Avid_DNxHD_files.zip.html

Also, are you planning to reverse-engineer DNX, or use their SDK?  I believe if you use the SDK the result must be closed-source.

DNxHD is an open standard (SMPTE VC-3), and is already implemented in ffmpeg.

I'm probably going to reverse engineer the Avid MXF modifications which are incompatible with the standard... unless I find something free with documentation or an implementation of it.

The DNxHD (except the 10 bit file which is not supported by ffmpeg) and the DV files are now supported with latest GIT.

I'm adding support for the uncompressed (seems to be raw YUV of some format) and for another Avid file (containing TIFF picture essence) later...

Could you also create some sample files with sound essence? :)


-----
commit 8dc9f2ea4d01ebefa87b77b879d577b5bed115eb
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Sat Feb 7 10:38:26 2009 +0100

    mxfdemux: Add support for non-standard Avid MXF files containing DNxHD essence
    
    Avid uses a custom essence container UL and custom essence element keys
    that are fortunately compatible with the generic container essence
    elements. Partially fixes bug #561922.

commit 6e392318c01394667578a09ba894184d356d9960
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Sat Feb 7 09:27:13 2009 +0100

    mxfdemux: Add support for non-standard Avid MXF files containing DV essence
    
    Avid usually uses a custom essence container label for the essence
    descriptors and stores the actual codec that is used inside the
    picture essence coding field (and for sound probably in the sound
    essence coding field but I have no sample files with sound).
    Partially fixes bug #561922.

commit 1822dc99d3ca39f8ca1f273aeb225687a7705406
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Fri Feb 6 11:57:46 2009 +0100

    mxfdemux: Add data definition for Avid vendor specific picture essence

Owen, it would also be nice if you could create a lot more files with all kinds of different video and sound codecs :) I guess supporting those should easy now after getting the first working.

Yes I can create a whole lot more.  Avid supports some 15 different codecs with various compression ratios (1:2, 1:4, 1:10 etc etc).

As for sound, those are stored as separate MXF files -- sound is never interleaved with video on Avid.

Ok, that'd be great :) Such sound-only MXF files would be nice too though but it will be a lot of work until we can support those correctly... also the uncompressed file is a bit more complicated because we don't support 4:4:4 packed YUV yet... and because clip-wrapped MXF essence is a big problem and it will be hard to support correctly in GStreamer.

Sebastian are all these files part of our test samples now and we can close this bug?

Yes they are: http://gstreamer.freedesktop.org/data/media/incoming/mxf/

But we don't completely support them yet and doing that would require a lot of work

There appears to be a regression for this issue in recent GStreamer releases. There's now some code in the MXF demuxer that checks to see if files are in frame wrapped mode and will refuse to play them otherwise. This doesn't take account of the fact that while the AVID files are frame wrapped AVID produces custom headers that don't give the standard 0x01 == Frame wrapped, 0x02 == Clip wrapped values.

This can be see by running the "mxf/avid/Avid DV25 NTSC 2997 3 sec.mxf" test file through a playbin, which at GST_DEBUG level 1 will produce the following error:

0:00:00.064250354 22071 0x7f71680b2940 ERROR               mxfdemux mxfdemux.c:868:gst_mxf_demux_update_essence_tracks:<mxfdemux0> Only frame wrapping currently supported

The attached patch fixes this by rewriting the frame/clip wrap defining byte in the header when AVID encoded media is found.

Created attachment 267478 [details] [review]
Patch to rewrite AVID's custom MXF headers to correctly report frame wrapping mode

Review of attachment 267478 [details] [review]:

::: gst/mxf/mxfdv-dif.c
@@ +80,3 @@
+      if (mxf_ul_is_subclass (&picture_essence_coding_dv, key)) {
+        // Fix AVID headers to report frame wrapping mode
+        track->parent.descriptor[i]->essence_container.u[15] = 0x01;

I think the rewriting should be done in a more central place, and also here you always set it to frame-wrapped. It could as well be clip wrapped if I'm not missing anything.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/8.