[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           |
------------------------------------+------------------------------------

Comment (by HenkDemper):

 Hello Tjoppen,

 I have & read the MXF Book, know & implemented ST377, but I think the
 original design idea about OP1a was top have a single '''logical''' clip
 from start-to-end. Anyhow all places I can find these simple pre-charged
 files (so only including pre-charge and roll-out) they are marked as OP1a.
 There is just no other technical way to achieve this and when exchanging
 files we (broadcast industry) don't want to label them (in this case) as
 anything other than OP1a, exactly because what you state: there are not so
 much MXF readers available that (claim) to support anything beyond OP1a...

 Examples AMWA AS-03, Harmonic RDD25:2014 (Harmonic), RDD9:2013 (Sony), EBU
 https://ebu.io/qc/items/0115W, ...

 Let's keep it that the early documents are not very conclusive about how
 to handle the pre-charge case, but the broadcast industry is
 standardising/labelling them as OP1a.

 If we would like to 100% sure, I might reach out to 'Mr MXF' (Bruce
 Devlin) or others on the original MXF design team (that came up with the
 OP's) and ask him/them for his/their advise on the subject... but given
 that these files are actually frequently used/seen in practice it won't
 change the use case, so maybe wasted time... In the end the goal should be
 to let FFmpeg (/libavformat/VLC/...) cope with as many files as possible.
 Agree ?

 > No, both audio and video have Origin > 0. It you only cut the audio then
 the output will be horribly out of sync :)

 Well, the video Origin is already used correctly in FFmpeg: the pre-charge
 video frames (amount: Origin) are used used to produce the first visible
 frame, but never displayed itself. So it would 'only' need handling for
 the audio case, which is now out-of-sync with video if there is pre-
 charge...

 > What if Origin is very large? I do not want the same kind of hack that
 libavformat/mov.c does for edit lists, that crap doesn't belong in a
 demuxer.

 We (as in our software) placed this pre-charge logic in the MXF file
 reader (because it is specific to MXF files and handled differently in for
 instance QuickTime files as mentioned). We first 'ask' the MXF reader
 which 'media frame' (Source Package, Index Table) to fetch for 'display
 frame' (viewable, Material Package) and then ask it to fetch that 'media
 frame' (for audio that is. for video we need to dig back to fill the
 decoder with pre-charge video frames). That would seem the proper 2-step
 way supporting any media (single/multi-item) in a MXF (or any other
 wrapper) file, with a split responsibility between the wrapper
 (MXF/QuickTime/...) and upper layer I would say ?

 As mentioned, I'm not intimate with how this (timing, single/multiple
 items in editlist/timeline, media vs display frames, pre-charge, ..)
 should/is exactly be properly handled in FFmpeg, but my guess would be the
 fix for the problem on-hand would be in libavformat\mxfdec.c. Happy to
 study that code more (as a possible next step), but do not want (as you
 mention) add 'crap in the wrong places'... So open for alternative
 suggestions...

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