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

CC BY-SA 3.0
2018-02-23T10:47:21.720Z
2018-02-23T10:47:21.720Z
Gyan
<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>

CC BY-SA 3.0
2018-02-22T11:53:05.763Z
It's a bug in the code. It assumes all streams are 30 fps.
Gyan
CC BY-SA 3.0
2018-02-22T15:19:39.623Z
Thanks, just found the bug myself too, should now be able to compensate
Murray Evans
CC BY-SA 3.0
2018-02-23T05:13:01.763Z
Fixed now in ffmpeg git master.
Gyan
<ffmpeg><timecode>
Problem setting first frame timecode using ffmpeg - timecode always different from requested for 59.94fps video
Murray Evans
# 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.


---

