[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):

 > Well, exporting this information so that the ffmpeg CLI could make use
 of it for all streams probably wouldn't hurt. But there are some use cases
 to consider:

 Exactly, we are on the same page.
 I ran into the exact same issue when making our lossless (/remuxing)
 rewrapper tool (which we use to make a subclip or partial file restore
 from MOV/MXF directly to any MOV/MXF combination): depending where you
 make the cut in the MXF/MOV source file (which may already be pre-charged
 itself !) and which source/destination MXF/MOV wrapper you use, you might
 end up using in that destination file:

 * For audible audio frames in MXF/MOV destination: always audible audio
 frames from source
 * For pre-charge (/roll-out) frames (non-audible) in MXF destination
 either:
  * audible (non-pre-charge/rollout) audio frames from source (if possible)
  * pre-charge/rollout (non-audible) audio frames from source (if possible)
  * create own zero (or even garbage ?) audio samples (always possible, I
 would say only after above)

 I have attached a slide I made at that time to visualise things...
 That was from some years ago, but I do recall it was challenging to get it
 right, such that it was all frame-accurate & in-sync and not taking too
 little/many frames in the resulting destination file including edge cases
 like cutting on a B-frame (in encoding/file order) just after an I-frame
 of an Open GOP (in which case you need to add an addition GOP at the
 beginning).

 Having said that (and thinking agile), having perfect re-wrapping/remux
 and transcoding support for Long GOP in FFmpeg might be a bit higher goal
 than the more limited case of this ticket: 'just' transcoding (not remux)
 to MP4/MOV (not MXF), in which case many of mentioned complexities do not
 (happen to) apply.

 What would be your suggestion to move forward on this ticket (and/or the
 more generic case which might many parts/files in FFmpeg) ?

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