[FFmpeg-trac] #8366(avformat:new): Audio ticks and video/audio out-of-sync when using MXF files with pre-charge

[FFmpeg]

#8366: Audio ticks and video/audio out-of-sync when using MXF files with pre-
charge
------------------------------------+------------------------------------
             Reporter:  HenkDemper  |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  avformat
              Version:  git-master  |               Resolution:
             Keywords:  MXF         |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+------------------------------------
Changes (by HenkDemper):

 * cc: henk@… (added)


Comment:

 Replying to [comment:2 Tjoppen]:
 > Could you upload to a less obnoxious host? Maybe http://0x0.st/. I think
 FFmpeg's FTP still allows anonymous upload, could also be worth a try. Or
 just dd off the first couple of MiB or so and upload here.

 I re-uploaded a zip with all files including input.mxf and output.mov to
 http://0x0.st/zg7l.zip
 Good tip for alternative to WeTransfer !

 > Could you paste the output of mxfdump as well?

 My bmx build on Mac doesn't include the mxfdump binary for some reason,
 likely because we created Universal Binaries (incl. 64 bits) and the
 mxfdump part failed on that or so...

 But I did include an alternative in the .zip and separate attachment: the
 textual output for input.mxf (input.txt) of a my own MXF Analyser (the one
 from the PNG screenshot), which I think contains equally usable info...

 > This sounds like an OP3a file, despite what the header says, since it's
 cutting off the start/end of a !FilePackage to make the !MaterialPackage.
 Adding full OP3a support is a tall order of course. Setting start_time on
 the relevant AVStreams might be enough in this case. libavformat/mov.c
 does something similar for edit lists, but frankly it's a horrible hack
 that doesn't belong in a demuxer..!

 Using the Origin field for (only) pre-charge purposes does not make the
 MXF file OP3a.
 Logically (let's say viewable) it is still SingleItem-SinglePackage and
 categorised as OP1a.
 I agree technically it 'misuses' a bit of the editlist methods.
 I have sample files from Sony (Japan camera division) also with PreCharge
 in XDCAM (from their camera's/Servers) labelled as OP1a.

 > Any patch that attempts to fix this should take care that edit lists are
 added both to remuxed MOVs and MXFs, and that such remuxed MXFs are marked
 as OP3a.

 As mentioned I think that 'only' the Origin offset for audio must be
 added/taken into account somewhere when audio samples are fetched, such
 that for t = 0 in the MXF file the Edit Unit with value 'Origin' is used
 instead of 0.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/8366#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker