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

 Based on your both replies I decided to make a perfect test sample to see
 what is going on in more detail:
 I constructed with QuickTime Player 7 Pro (always handy in these cases) an
 Intra codec file that contains:

 {{{
 1. 13 frames of football match with horn sounds
 2. 10 seconds bouncing ball A/V sync test with burned-in timecode starting
 at 00:00:03:00
 }}}

 All samples in 1080i50 (so 25 fps) to keep things simple with 1920 audio
 samples per frame without any NTSC audio 1601/1602 sequence misery.
 I then rendered above file to XDCAM codec as QuickTime file, which then
 has no pre-charge (fresh render).
 This file was then rewrapped (with timecode matching the burned-in
 version) to SyncTest.mxf, which I zipped and uploaded to
 http://0x0.st/z66D.zip
 I also uploaded in the same .zip an Excel file of the GOP structure of the
 test source file.

 Next I made a 5-second sub-clip out of this file on the second B-frame =
 14th (display order) frame in the 2nd GOP (worst case for pre-charge, it
 will need the last P-frame out of the 1st GOP as well), resulting in a
 pre-charge aka File Package - Origin in MXF file of 13 frames.
 I made the sub-clip both in Sony flavour and generic OP1a (OP3a if you
 like ;-)) flavour, which turns out not to influence below results, just
 some slight metadata differences and extra System Metadata Packs & Package
 Metadata Sets in each Content Package (aka frame).
 In an ideal MXF player, the video and audio for this MXF subclip should
 start exactly at the 14th frame of the source file, start with the
 bouncing ball at burned-in timecode 00:00:03:00, have no traces of either
 football or blowing horns and last for exactly 5 seconds.
 Note this happens OK in Mac QuickView, Switch Player, Premiere, FCPX, ...
 etc.
 These 2 resulting MXF sub-clips together with matching GOP Analysis Excels
 have been uploaded as http://0x0.st/z66d.zip

 Then I transcoded these 2 sub-clips using the earlier mentioned ffmpeg
 command line

 {{{
 ffmpeg -i input.mxf -vcodec h264 -acodec copy -report output.mov
 }}}

 I uploaded the resulting output.mov files (with log and GOP analysis) to
 http://0x0.st/z66n.zip
 I then played these files back and guess what ?
 I must admit that my earlier conclusion 'out of sync' was wrong, it was
 based on bad example files in combination with me believing that the audio
 started earlier (in the pre-charge, as I heard that) in combination with
 the video looked fine...
 Because what I see is that ffmpeg seems to completely ignore the Origin
 (pre-charge), both for video and for audio:
 The resulting .mov files start with the football match with horn (both in
 pre-charge area), are perfectly in sync and play for 5 seconds and 13
 frames.
 Note the output.mov files itself have no pre-charge (as expected).
 This is the same issue as you see in VLC playing back the MXF subclips
 that where used as source for the ffmpeg command line:
 VLC starts with the 1st pre-charge frame as well instead of skipping the
 pre-charge.

 Looking at libavformat/mxfdec.c I see:

 {{{
 if (material_track->sequence->origin) {
         av_dict_set_int(&st->metadata, "material_track_origin",
 material_track->sequence->origin, 0);
 }
 if (source_track->sequence->origin) {
         av_dict_set_int(&st->metadata, "source_track_origin",
 source_track->sequence->origin, 0);
 }
 }}}

 For these files, material_track->sequence->origin is 0 and
 source_track->sequence->origin is 13.
 Apart from these lines, it appears sequence->origin is not used and I
 doubt that the av_dict with the string-int mapping is used up-stream ?

 So the revised request/issue is to add pre-charge support for video/audio
 in MXF altogether.
 Note that with no doubt there might be some option in ffmpeg command line,
 but

 a. the amount of 13 frames is unknown to the user
 b. will differ for each subclip (depending where the cuts where made)
 c. is not the proper fix
 d. also still issue in VLC etc

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