[FFmpeg-user] MXF file from ikegami gfpack

[Moritz Barsnick]

On Mon, Sep 19, 2016 at 14:20:13 -0700, afellah wrote:
> I tried your command before and its giving an out output file duration
> different than the source
> source = 00:00:51.80
> output file for .mov = 00:00:52.239 and output file for .wav = 00:00:52.216
>  and here is the command :
> >ffmpeg.exe -f s16le -c:a pcm_s16le -ac:a 2 -ar: 48000 -i A2.MXF 21112.mov

That's not what I suggested!

What you are doing here is interpreting the whole MXF file as a raw PCM
audio stream, regardless of headers, padding, scrambling, whatsoever.

But let me ask you this: Does the resulting output file from your
command basically sound correct?

To explain what I did: Carl Eugen asked whether any other program at
all is capable of properly interpreting (and extracting) the contents
A2.MXF without the presence of A1.MXF or perhaps some other metadata
file.

We already know that Mediainfo - unlike ffmpeg - is able to *identify*
the audio stream.

I then used mfxsplit from MXFLib to show that a stream can not only be
identified, but also extracted. Doing this, mxfsplit gave me some raw
stream. *This* stream I then interpreted as raw audio (with the same
parameters as found in the MXF file's metadata) using ffmpeg, and was
able to convert and play it.

And as I mentioned: The length I got was 00:00:51.80, which seems to
correspond what you claim the source has. Assuming the result is okay
(I can provide you with an MP3 or WAV of what I got), this shows that
mxfsplit/MXFlib is capable of doing the right thing, and other tools
like ffmpeg should also.

This wouldn't help *you* right now (unless you resort to mxfsplit), but
it should show that ffmpeg is missing the capability of demuxing these
sort of MXF files correctly. *That* is what we are trying to get
behind. The *next* step would be trying to fix/enhance ffmpeg.

Cheers,
Moritz