Answers.Body: <p>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.</p>
  
  <p>In drop-frame timecode, since some timecode labels are periodically skipped, timecode and (frame count/fps) do not correspond anymore i.e. <code>timecode * fps != frame count</code>. This necessitates an adjustment in order to derive the corresponding frame number. The code assumed a fixed 30 fps, but has now been fixed.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-23T10:47:21.720Z
Answers.LastActivityDate: 2018-02-23T10:47:21.720Z
Answers.UserDisplayName: Gyan
Body: <p>Edit: Found to be a small bug in FFmpeg. It should hopefully soon be patched.</p>
  
  <p>I'm having issues with setting the timecode for some .MXF files that I have. If I run the command:</p>
  
  <pre><code>ffmpeg -i test.MXF -vcodec copy -acodec copy -timecode "00:05:00;10" tmp.MXF
  </code></pre>
  
  <p>and then check using ffprobe:</p>
  
  <pre><code>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 &gt; 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
  </code></pre>
  
  <p>Then the timecode is clearly later than the requested timecode (00:05:00;20 -> 00:05:00;30)</p>
  
  <p>I have tested with various different valid input timecodes, and the output timecode is always different from what I request.</p>
  
  <p>e.g. </p>
  
  <pre><code>00:10:00;00 -&gt; 00:10:00;18
  09:58:34;00 -&gt; 09:58:51;58
  </code></pre>
  
  <p>Any suggestions?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-02-22T11:53:05.763Z
Comments.Text: It's a bug in the code. It assumes all streams are 30 fps.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-02-22T15:19:39.623Z
Comments.Text: Thanks, just found the bug myself too, should now be able to compensate
Comments.UserDisplayName: Murray Evans
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-02-23T05:13:01.763Z
Comments.Text: Fixed now in ffmpeg git master.
Comments.UserDisplayName: Gyan
Tags: <ffmpeg><timecode>
Title: Problem setting first frame timecode using ffmpeg - timecode always different from requested for 59.94fps video
UserDisplayName: Murray Evans
ThreadText: # Problem setting first frame timecode using ffmpeg - timecode always different from requested for 59.94fps video
  
  (Asked by: username_0 on 2018-02-22)
  
  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?
  
  **Tags:** ffmpeg, timecode
  
  > **Comments:**
  > **username_1**: It's a bug in the code. It assumes all streams are 30 fps.  
  > **username_0**: Thanks, just found the bug myself too, should now be able to compensate  
  > **username_1**: Fixed now in ffmpeg git master.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-02-23. Score: 1
  
  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.
  
  
  ---
  
  