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

 Replying to [comment:9 ngaullie]:
 > I have analyzed your files and I have another reading :
 > - every picture sample is encoded to your MOV file, and every audio
 sample is rewrapped, there is no loss
 > - the loss of sync (ffmpeg bug) does not seem to be related to the MXF
 wrapper itself. At the output, the MOV file has a video track with an edit
 list that shift video of 0.0667s (precisely=2/29.97) - but not the audio
 track, and this breaks sync.

 I think I missed the part where it's only different after
 transcoding/muxing to MOV. output.mov looks in sync to me, but maybe my
 brain's tolerance for desync is too high? The MOV has higher stream
 durations, which is definitely shady as hell. A file with a larger Offset
 would make the effect more noticable. Maybe I can cook something up
 tomorrow after having some sleep.

 > The input MXF file has a precharge value which is consistent amongst the
 tracks (video/audios/tc), and I agree that, in this case, you can claim
 its's Op1a because this is the state of the art, broadly implemented,
 despite absence of clarification in actual texts.

 The spec is clear, and the MXF book reaffirms it. It's only OP1a if the MP
 and FP have the same duration. FFmpeg can still implement this limited
 form of OP3a of course, but let's stick to correct terminology.

 > Support for MXF having non-consistent precharges values does not seem
 necessary in my opinion.
 > Handling MXF files having a consistent precharge value like yours is no
 big deal with a first pass analysis and a basic trim clip switch; but of
 course this is not ideal and could be enhanced.

 If you get the trim right, then you'll automagically handle different
 trimming for each stream right. There are storage benefits to getting it
 right as well.

 !HenkDemper's use case is equivalent to grabbing the same interval out of
 the original XDCAM files. Getting that right is not trivial. We can get
 some funny cases where a malicious file reports as being 1 second long (MP
 length), but with a 100 hour long heavily compressed FP. A naïve trim
 implementation will process all that. Hence why I don't like the hacks in
 mov.c, because this belongs in the ffmpeg CLI and in ffplay, or somewhere
 between those two and libavformat. But that also gets into libmelt
 territory.

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