2

Edit: Found to be a small bug in FFmpeg. It should hopefully soon be patched.

I'm having issues with setting the timecode for some .MXF files that I have. If I run the command:

ffmpeg -i test.MXF -vcodec copy -acodec copy -timecode "00:05:00;10" tmp.MXF

and then check using ffprobe:

ffprobe tmp.MXF
dpc3:tmp me475$ ffprobe tmp.MXF
ffprobe version 3.4 Copyright (c) 2007-2017 the FFmpeg developers
  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/3.4 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-gpl --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-opencl --enable-videotoolbox --disable-lzma
  libavutil      55. 78.100 / 55. 78.100
  libavcodec     57.107.100 / 57.107.100
  libavformat    57. 83.100 / 57. 83.100
  libavdevice    57. 10.100 / 57. 10.100
  libavfilter     6.107.100 /  6.107.100
  libavresample   3.  7.  0 /  3.  7.  0
  libswscale      4.  8.100 /  4.  8.100
  libswresample   2.  9.100 /  2.  9.100
  libpostproc    54.  7.100 / 54.  7.100
[h264 @ 0x7fb652816600] Truncating likely oversized PPS (9469 > 4096)
    Last message repeated 4 times
[mxf @ 0x7fb652815200] decoding for stream 0 failed
Input #0, mxf, from 'tmp.MXF':
  Metadata:
    uid             : adab4424-2f25-4dc7-92ff-29bd000c0000
    generation_uid  : adab4424-2f25-4dc7-92ff-29bd000c0001
    company_name    : FFmpeg
    product_name    : OP1a Muxer
    product_version : 57.83.100
    product_uid     : adab4424-2f25-4dc7-92ff-29bd000c0002
    modification_date: 0000-01-02T00:00:00.000000Z
    material_package_umid: 0x060A2B340101010501010D0013E30DF252947134C9E30DF20052947134C9E300
    timecode        : 00:05:00;30
  Duration: 00:00:08.01, start: 0.000000, bitrate: 577647 kb/s
    Stream #0:0: Video: h264 (High 4:2:2 Intra), yuv422p10le(progressive), 3840x2160 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 59.94 tbn, 119.88 tbc
    Metadata:
      file_package_umid: 0x060A2B340101010501010D0013E30DF252947134C9E30DF20052947134C9E301
    Stream #0:1: Audio: pcm_s24le, 48000 Hz, 1 channels, s32 (24 bit), 1152 kb/s
    Metadata:
      file_package_umid: 0x060A2B340101010501010D0013E30DF252947134C9E30DF20052947134C9E301

Then the timecode is clearly later than the requested timecode (00:05:00;20 -> 00:05:00;30)

I have tested with various different valid input timecodes, and the output timecode is always different from what I request.

e.g.

00:10:00;00 -> 00:10:00;18
09:58:34;00 -> 09:58:51;58

Any suggestions?

  • It's a bug in the code. It assumes all streams are 30 fps. – Gyan Feb 22 '18 at 11:53
  • Thanks, just found the bug myself too, should now be able to compensate – Murray Evans Feb 22 '18 at 15:19
  • Fixed now in ffmpeg git master. – Gyan Feb 23 '18 at 5:13
0

The user-supplied timecode value is converted to an integer value that represents the frame number which is associated with that timecode. It is this integer which is stored in the file.

In drop-frame timecode, since some timecode labels are periodically skipped, timecode and (frame count/fps) do not correspond anymore i.e. timecode * fps != frame count. This necessitates an adjustment in order to derive the corresponding frame number. The code assumed a fixed 30 fps, but has now been fixed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.