[FFmpeg-trac] #8523(avformat:open): ffmpeg converts 30fps input to 29.97fps when converting to .mxf

FFmpeg trac at avcodec.org
Mon Feb 17 22:14:28 EET 2020


#8523: ffmpeg converts 30fps input to 29.97fps when converting to .mxf
------------------------------------+------------------------------------
             Reporter:  reakon      |                    Owner:
                 Type:  defect      |                   Status:  open
             Priority:  normal      |                Component:  avformat
              Version:  git-master  |               Resolution:
             Keywords:  mxf         |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+------------------------------------

Comment (by Tjoppen):

 The problem is that we can't define mxf_spf for every conceivable
 framerate. At the moment it is defined thus:

 {{{
 static const MXFSamplesPerFrame mxf_spf[] = {
     { { 1001, 24000 }, { 2002, 0,    0,    0,    0,    0 } }, // FILM
 23.976
     { { 1, 24},        { 2000, 0,    0,    0,    0,    0 } }, // FILM 24
     { { 1001, 30000 }, { 1602, 1601, 1602, 1601, 1602, 0 } }, // NTSC
 29.97
     { { 1, 30 },       { 1600, 0,    0,    0,    0,    0 } }, // 30
     { { 1001, 60000 }, { 801,  801,  800,  801,  801,  0 } }, // NTSC
 59.94
     { { 1, 25 },       { 1920, 0,    0,    0,    0,    0 } }, // PAL 25
     { { 1, 50 },       { 960,  0,    0,    0,    0,    0 } }, // PAL 50
     { { 1, 60 },       { 800,  0,    0,    0,    0,    0 } },
 };
 }}}

 mxf_content_package_rates relates to this as well:

 {{{
 static const int mxf_content_package_rates[] = {
     3, 2, 7, 13, 4, 10, 12,
 };
 }}}

 The muxer even warns about the inexact match:

 >[mxf @ 00000187ba421d80] 1/30 input time base matched 1001/30000
 container time base

 IMO the muxer should outright refuse if the user isn't specifying *exacly*
 the right time base, to avoid outputting things that will lose sync. With
 MXF being picky is a necessity.

 It might be possible to add support for specific rates without too much
 engineering effort, but a general solution that also respects mxf_spf
 would be trickier. Of course, audio-only MXF or .wav could be a solution
 for Pro Tools

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


More information about the FFmpeg-trac mailing list