[FFmpeg-trac] #8366(avformat:new): Audio ticks and video/audio out-of-sync when using MXF files with pre-charge
FFmpeg
trac at avcodec.org
Wed Nov 20 00:39:57 EET 2019
#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
More information about the FFmpeg-trac
mailing list