[FFmpeg-devel] [PATCH] mxfenc: audio only support

[Tomas Härdin]

On Mon, 2012-04-02 at 03:57 +0200, Michael Niedermayer wrote:
> On Mon, Apr 02, 2012 at 02:01:18AM +0200, Tomas Härdin wrote:
> > On Sun, 2012-04-01 at 21:36 +0200, Michael Niedermayer wrote:
> > > @@ -1467,6 +1460,10 @@ static int mxf_write_header(AVFormatContext *s)
> > >                  return -1;
> > >              }
> > >              avpriv_set_pts_info(st, 64, 1, st->codec->sample_rate);
> > > +            if (!mxf->time_base.num) {
> > > +                mxf->time_base = (AVRational){ 1, st->codec->sample_rate };
> > > +                rate = (AVRational){ 30, 1 };
> > > +            }
> > 
> > mxf->time_base is EditRate (or rather, its inverse) - I wouldn't
> > recommend setting it to the sample rate. I'm not entirely into how the
> > interleaving works, but I suspect this would result in each *sample*
> > being muxed as its own KLV packet + system item; a mere ~2000-3000%
> > overhead :)
> 
> overhead doesnt change when i set this to 30 or 48000

Right, samples_per_frame. I think I've seen files with EditRate = 48000
but those may have been OPAtom. Not sure if it's a good idea with OP1a
unless there's an IndexTableSegment with IndexEditRate = 25/1.

> > Doesn't code elsewhere in mxfenc default to 25 fps / 1920 samples/frame?
> > If so then I think this should should too. Like:
> > 
> > mxf->time_base = (AVRational){ 1, 25 };
> > rate = (AVRational){ 25, 1 };
> 
> any other changes i should do or its ok with just that ?

I tested the original patch and my suggestion and both result in ffprobe
and mxfdump spewing complaints:

> $ ./ffmpeg -i ~/media/11k16bitpcm.wav -ar 48k -y foo.mxf && ffprobe foo.mxf
> ...
>   libpostproc    52.  0.100 / 52.  0.100
> [mxf @ 0x2d5a4e0] index entry 27 + TemporalOffset -120 = -93, which is out of bounds
> [mxf @ 0x2d5a4e0] index entry 38 + TemporalOffset -106 = -68, which is out of bounds
> [mxf @ 0x2d5a4e0] index entry 49 + TemporalOffset -92 = -43, which is out of bounds
> [mxf @ 0x2d5a4e0] index entry 60 + TemporalOffset -78 = -18, which is out of bounds
> [mxf @ 0x2d5a4e0] index entry 236 + TemporalOffset 125 = 361, which is out of bounds
> [mxf @ 0x2d5a4e0] index entry 248 + TemporalOffset 113 = 361, which is out of bounds
> [mxf @ 0x2d5a4e0] index entry 289 + TemporalOffset 60 = 349, which is out of bounds
> [mxf @ 0x2d5a4e0] index entry 300 + TemporalOffset 74 = 374, which is out of bounds
> [mxf @ 0x2d5a4e0] index entry 311 + TemporalOffset 88 = 399, which is out of bounds
> [mxf @ 0x2d5a4e0] index entry 345 + TemporalOffset 1 = 346, which is out of bounds
> [mxf @ 0x2d5a4e0] failed to find absolute offset of 120000000000 in BodySID 1 - partial file?
>     Last message repeated 252 times

This implies there's a VBR index with slices. Probably because of mxf->slice_count = 1;
Slices are MXF's way of indexing VBR combined with CBR.

> $ mxfdump foo.mxf
> ...
> ERROR: Expected to find an IndexTableSegment - found Unknown [00000001.0000.0000.00001000.00000001] at 0x00000000 in memory buffer

Uh oh..

> Index Table Segment (first edit unit = 251, duration = 95) :
>   Indexing BodySID 0x0001 from IndexSID 0x0002
> 
>  Bytestream Order:
>   EditUnit 251 for stream 0 is at 0x0011a600, Flags=00  *Exact*
>   EditUnit 251 for stream 1 is at 0x0011a800, Flags=00  *Exact*
>   EditUnit 252 for stream 0 is at 0x11b80000000000, Flags=00  *Exact*
>   EditUnit 252 for stream 1 is at 0x11b80000000200, Flags=00  *Exact*
>   EditUnit 253 for stream 0 is at 0x00000000, Flags=00  *Exact*
>   EditUnit 253 for stream 1 is at 0x00000200, Flags=00  *Exact*
>   EditUnit 254 for stream 0 is at 0x11ee0000, Flags=00  *Exact*
>   EditUnit 254 for stream 1 is at 0x11ee0200, Flags=00  *Exact*
>   EditUnit 255 for stream 0 is at 0x1200000000000000, Flags=00  *Exact*
>   EditUnit 255 for stream 1 is at 0x1200000000000200, Flags=00  *Exact*
>   EditUnit 256 for stream 0 is at 0x00000012, Flags=00  *Exact*
>   EditUnit 256 for stream 1 is at 0x00000212, Flags=00  *Exact*
These offsets should be contiguous ^^^^^^^^^^

So uhm. I'm not OK with this :)
Stop gap attached - I'm not familiar enough with the muxer to fix this properly.

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mxfenc-Don-t-allow-muxing-audio-only-since-it-s-not-.patch
Type: text/x-patch
Size: 1377 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120403/9b43f1a8/attachment.bin>