[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
Tue Nov 12 20:30:54 EET 2019

#8366: Audio ticks and video/audio out-of-sync when using MXF files with pre-
             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:4 HenkDemper]:
 > Replying to [comment:2 Tjoppen]:
 > > 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.

 Yes, it does. To quote S377m:

 >Single item: The file contains only one item. There is a single material
 package !SourceClip which is '''the same duration''' as the top-level file

 The MXF Book backs this up (page 27):

 >In some applications, it may be desirable to play out only the central
 contribution portion of our example file. In this case a material package
 is used that describes only this central portion of the file, and not the
 color bars, slate, or black portion of the stored content. The operational
 pattern that describes this functionality is OP3a.

 Replying to [comment:4 HenkDemper]:
 > Logically (let's say viewable) it is still !SingleItem-!SinglePackage
 and categorised as OP1a.

 The file has Duration = 287 in the MP clips, but 299 in the FP clips.
 Therefore it is not !SingleItem per 7.3.1 in S377m.

 > I have sample files from Sony (Japan camera division) also with
 !PreCharge in XDCAM (from their camera's/Servers) labelled as OP1a.

 This wouldn't be the first time a vendor was wrong.

 > > 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.

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

 I don't know how the ffmpeg CLI deals with start times on streams. Can it
 be told to decode but discard the first Duration number of edit units?
 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

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

More information about the FFmpeg-trac mailing list