<p>Streaming formats maintain timestamps for each frame, whether audio or video, which govern when the player ought to present them. Those non-zero big start times usually occur when a snippet is cut out from a longer video and the tool used does not reset the timestamps. Although if this FLV was recorded on its own, then it's strange.</p>

<p>In any case, running the command below should fix the problem.</p>

<pre><code>ffmpeg -i input.flv -c copy output.flv 
</code></pre>

CC BY-SA 3.0
2016-05-18T15:31:04.490Z
Thanks for the quick answer!

Yeah, I think the live stream's timecodes were retained when it was dumped, so it makes sense now.

Your ffmpeg timestamp-juggling was sorta solved the issue... it worked with the aforementioned example, however, I've tested it with another file which had the same issue (1 hour delay). That file is a product of some kind of Apple software, on which the command didn't worked as expected...

And I discovered another problem: it looks like some encoder libraries count the delay towards the total length, some of them doesn't, which is EXTRA confusing...
Gergely Lukacsy
CC BY-SA 3.0
2016-05-18T15:36:58.447Z
Show the complete console output of the command ran on the Apple file. Insert it into the Q.
Gyan
CC BY-SA 3.0
2016-05-18T15:48:34.293Z
Here you go. You basically answered the "why" part, so many thanks for your additional effort!
Gergely Lukacsy
CC BY-SA 3.0
2016-05-18T15:55:45.970Z
What's wrong with the Apple output? Looks fine.
Gyan
CC BY-SA 3.0
2016-05-18T16:03:15.583Z
Mediainfo still says that the delay is `<Delay>1h 0mn</Delay>`. FFmpeg hints the same with the `timecode        : 01:00:00:00` part... I think the particular problem with the .mov file is so rare, that it shouldn't take any further attention (basically 1 out of 1200+ other files).
Gergely Lukacsy
CC BY-SA 3.0
2016-05-18T16:15:55.053Z
That's a timecode, not a timestamp, and shouldn't affect duration detection. You can reset it: `ffmpeg -i in.mov -c copy -timecode 00:00:00:00 out.mov`
Gyan
CC BY-SA 3.0
2016-05-19T08:37:37.963Z
Damn, you're right, the output of mediainfo was pretty misleading in the latter case...

The `-timecode` option did the trick! Thanks!
Gergely Lukacsy
CC BY-SA 3.0
2016-05-18T14:10:34.007Z
2016-05-18T14:10:34.007Z
Gyan
<p>Recently, I'm forced to fiddle with a nasty little problem with videos that have some special metadata attributes, namely "delay" or "delay_relative_to_video".</p>

<p>There's a software videoconferencing solution wich produces these special files, and when our videoprocessing software examines these files, it gets longer duration values than the actual length of the content, thus storing wrong data into the database which causes more trouble in the postprocessing phase.</p>

<p>For example, we recorded a 46 second long video, which was detected as 104.7 seconds long.</p>

<p>After inspecting the file with FFmpeg and Mediainfo, it turned out that the original file had a so called "delay" value which can be seen as <code>start</code> time in FFmpeg's output:</p>

<pre><code>Input #0, flv, from '/path/to/the/file/converter/master/194/194_video.flv':
  Metadata:
    metadatacreator : Yet Another Metadata Injector for FLV - Version 1.4
    hasKeyframes    : true
    hasVideo        : true
    hasAudio        : true
    hasMetadata     : true
    canSeekToEnd    : false
    datasize        : 12892571
    videosize       : 12198311
    audiosize       : 680584
    lasttimestamp   : 105
    lastkeyframetimestamp: 104
    lastkeyframelocation: 12646873
  Duration: 00:01:44.77, start: 58.033000, bitrate: 984 kb/s
    Stream #0:0: Video: h264 (Constrained Baseline), yuv420p, 1280x720, 30 fps, 30 tbr, 1k tbn
    Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp
</code></pre>

<p>...and <code>Delay</code> or <code>Delay_relative_to_video</code> in Mediainfo's:</p>

<pre><code>mediainfo --full --output=XML /path/to/the/file/converter/master/194/194_video.flv

&lt;track type="Video"&gt;
(...)
&lt;Delay&gt;0&lt;/Delay&gt;
&lt;Delay&gt;00:00:00.000&lt;/Delay&gt;
&lt;Delay__origin&gt;Container&lt;/Delay__origin&gt;
&lt;Delay__origin&gt;Container&lt;/Delay__origin&gt;
&lt;/track&gt;

&lt;track type="Audio"&gt;
(...)
&lt;Delay&gt;58036&lt;/Delay&gt;
&lt;Delay&gt;58s 36ms&lt;/Delay&gt;
&lt;Delay&gt;58s 36ms&lt;/Delay&gt;
&lt;Delay&gt;58s 36ms&lt;/Delay&gt;
&lt;Delay&gt;00:00:58.036&lt;/Delay&gt;
&lt;Delay__origin&gt;Container&lt;/Delay__origin&gt;
&lt;Delay__origin&gt;Container&lt;/Delay__origin&gt;
&lt;Delay_relative_to_video&gt;58036&lt;/Delay_relative_to_video&gt;
&lt;Delay_relative_to_video&gt;58s 36ms&lt;/Delay_relative_to_video&gt;
&lt;Delay_relative_to_video&gt;58s 36ms&lt;/Delay_relative_to_video&gt;
&lt;Delay_relative_to_video&gt;58s 36ms&lt;/Delay_relative_to_video&gt;
&lt;Delay_relative_to_video&gt;00:00:58.036&lt;/Delay_relative_to_video&gt;
&lt;/track&gt;
</code></pre>

<p>"Surprisingly", substracting the length and the delay gives me the correct duration...</p>

<p>Also, it is really embarrassing that some encoder libraries count these delays towards the total length, but some of them doesn't! Seemingly there's no way to distinguish which length values are correct and which were incremented accordingly!</p>

<p>So long story short, I'd like to know what are these metadata used for?
What's the reason of their existence and why does some encoders/video editing software injecting these metadata into the file?</p>

<p>Thanks for your answers in advance!</p>

<p><strong>Edit:</strong></p>

<p><strong>According to Mulvya's answer, running a simple stream-copy on the file can reset the timestamps!</strong></p>

<p>However, there was a .mov file on which it didn't worked.
Related console output:</p>

<pre><code>ffmpeg -i 22_video.mov -c copy _22_video.mov
ffmpeg version N-79632-g3ce1988-static Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.7 (Debian 4.7.2-5)
  configuration: --prefix=/home/gergo/buildscript/ffmpeg-static-master-customVSQ/target --extra-cflags='-I/home/gergo/buildscript/ffmpeg-static-master-customVSQ/target/include -static' --extra-cflags=--static --extra-ldflags='-L/home/gergo/buildscript/ffmpeg-static-master-customVSQ/target/lib -lm -static' --extra-libs=-ldl --extra-version=static --disable-debug --disable-shared --enable-static --extra-cflags=--static --disable-ffplay --disable-ffserver --disable-doc --enable-gpl --enable-pthreads --enable-postproc --enable-gray --enable-runtime-cpudetect --enable-libfaac --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-bzlib --enable-zlib --enable-nonfree --enable-version3 --enable-libwavpack --enable-libvpx --enable-librtmp
  libavutil      55. 22.101 / 55. 22.101
  libavcodec     57. 38.100 / 57. 38.100
  libavformat    57. 34.103 / 57. 34.103
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 44.100 /  6. 44.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '22_video.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537199360
    compatible_brands: qt
    creation_time   : 2013-10-29 21:33:33
    com.apple.finalcutstudio.media.uuid: 3B712819-1D1D-4F9B-8593-01656870A04C
    timecode        : 01:00:00:00
  Duration: 00:03:25.00, start: 0.000000, bitrate: 9332 kb/s
    Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 9019 kb/s, 25 fps, 25 tbr, 2500 tbn (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Video Media Handler
      encoder         : H.264
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 307 kb/s (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Sound Media Handler
    Stream #0:2(eng): Data: none (tmcd / 0x64636D74) (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Time Code Media Handler
      timecode        : 01:00:00:00
File '_22_video.mov' already exists. Overwrite ? [y/N] y
[mov @ 0x46c6660] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
    Last message repeated 1 times
Output #0, mov, to '_22_video.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537199360
    compatible_brands: qt
    timecode        : 01:00:00:00
    com.apple.finalcutstudio.media.uuid: 3B712819-1D1D-4F9B-8593-01656870A04C
    encoder         : Lavf57.34.103
    Stream #0:0(eng): Video: h264 (avc1 / 0x31637661), yuv420p, 1920x1080, q=2-31, 9019 kb/s, 0.04 fps, 25 tbr, 10k tbn (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Video Media Handler
      encoder         : H.264
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, 307 kb/s (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Sound Media Handler
Stream mapping:
  Stream #0:0 -&gt; #0:0 (copy)
  Stream #0:1 -&gt; #0:1 (copy)
Press [q] to stop, [?] for help
frame= 5125 fps=0.0 q=-1.0 Lsize=  233585kB time=00:03:25.00 bitrate=9333.9kbits/s speed= 547x
video:225709kB audio:7706kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.072599%
</code></pre>

<ffmpeg><conversion><timecode><mpeg4><metadata>
Video metadata: What is "Video delay" used for?
Gergely Lukacsy
# Video metadata: What is "Video delay" used for?

(Asked by: username_0 on 2016-05-18)

Recently, I'm forced to fiddle with a nasty little problem with videos that have some special metadata attributes, namely "delay" or "delay_relative_to_video".
There's a software videoconferencing solution wich produces these special files, and when our videoprocessing software examines these files, it gets longer duration values than the actual length of the content, thus storing wrong data into the database which causes more trouble in the postprocessing phase.
For example, we recorded a 46 second long video, which was detected as 104.7 seconds long.
After inspecting the file with FFmpeg and Mediainfo, it turned out that the original file had a so called "delay" value which can be seen as start time in FFmpeg's output:
Input #0, flv, from '/path/to/the/file/converter/master/194/194_video.flv':
  Metadata:
    metadatacreator : Yet Another Metadata Injector for FLV - Version 1.4
    hasKeyframes    : true
    hasVideo        : true
    hasAudio        : true
    hasMetadata     : true
    canSeekToEnd    : false
    datasize        : 12892571
    videosize       : 12198311
    audiosize       : 680584
    lasttimestamp   : 105
    lastkeyframetimestamp: 104
    lastkeyframelocation: 12646873
  Duration: 00:01:44.77, start: 58.033000, bitrate: 984 kb/s
    Stream #0:0: Video: h264 (Constrained Baseline), yuv420p, 1280x720, 30 fps, 30 tbr, 1k tbn
    Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp

...and Delay or Delay_relative_to_video in Mediainfo's:
mediainfo --full --output=XML /path/to/the/file/converter/master/194/194_video.flv


(...)
0
00:00:00.000
Container
Container



(...)
58036
58s 36ms
58s 36ms
58s 36ms
00:00:58.036
Container
Container
58036
58s 36ms
58s 36ms
58s 36ms
00:00:58.036


"Surprisingly", substracting the length and the delay gives me the correct duration...
Also, it is really embarrassing that some encoder libraries count these delays towards the total length, but some of them doesn't! Seemingly there's no way to distinguish which length values are correct and which were incremented accordingly!
So long story short, I'd like to know what are these metadata used for?
What's the reason of their existence and why does some encoders/video editing software injecting these metadata into the file?
Thanks for your answers in advance!
Edit:
According to Mulvya's answer, running a simple stream-copy on the file can reset the timestamps!
However, there was a .mov file on which it didn't worked.
Related console output:
ffmpeg -i 22_video.mov -c copy _22_video.mov
ffmpeg version N-79632-g3ce1988-static Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.7 (Debian 4.7.2-5)
  configuration: --prefix=/home/gergo/buildscript/ffmpeg-static-master-customVSQ/target --extra-cflags='-I/home/gergo/buildscript/ffmpeg-static-master-customVSQ/target/include -static' --extra-cflags=--static --extra-ldflags='-L/home/gergo/buildscript/ffmpeg-static-master-customVSQ/target/lib -lm -static' --extra-libs=-ldl --extra-version=static --disable-debug --disable-shared --enable-static --extra-cflags=--static --disable-ffplay --disable-ffserver --disable-doc --enable-gpl --enable-pthreads --enable-postproc --enable-gray --enable-runtime-cpudetect --enable-libfaac --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-bzlib --enable-zlib --enable-nonfree --enable-version3 --enable-libwavpack --enable-libvpx --enable-librtmp
  libavutil      55. 22.101 / 55. 22.101
  libavcodec     57. 38.100 / 57. 38.100
  libavformat    57. 34.103 / 57. 34.103
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 44.100 /  6. 44.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '22_video.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537199360
    compatible_brands: qt
    creation_time   : 2013-10-29 21:33:33
    com.apple.finalcutstudio.media.uuid: 3B712819-1D1D-4F9B-8593-01656870A04C
    timecode        : 01:00:00:00
  Duration: 00:03:25.00, start: 0.000000, bitrate: 9332 kb/s
    Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 9019 kb/s, 25 fps, 25 tbr, 2500 tbn (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Video Media Handler
      encoder         : H.264
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 307 kb/s (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Sound Media Handler
    Stream #0:2(eng): Data: none (tmcd / 0x64636D74) (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Time Code Media Handler
      timecode        : 01:00:00:00
File '_22_video.mov' already exists. Overwrite ? [y/N] y
[mov @ 0x46c6660] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
    Last message repeated 1 times
Output #0, mov, to '_22_video.mov':
  Metadata:
    major_brand     : qt
    minor_version   : 537199360
    compatible_brands: qt
    timecode        : 01:00:00:00
    com.apple.finalcutstudio.media.uuid: 3B712819-1D1D-4F9B-8593-01656870A04C
    encoder         : Lavf57.34.103
    Stream #0:0(eng): Video: h264 (avc1 / 0x31637661), yuv420p, 1920x1080, q=2-31, 9019 kb/s, 0.04 fps, 25 tbr, 10k tbn (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Video Media Handler
      encoder         : H.264
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, 307 kb/s (default)
    Metadata:
      creation_time   : 2013-10-29 21:33:33
      handler_name    : Apple Sound Media Handler
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 5125 fps=0.0 q=-1.0 Lsize=  233585kB time=00:03:25.00 bitrate=9333.9kbits/s speed= 547x
video:225709kB audio:7706kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.072599%

**Tags:** ffmpeg, conversion, timecode, mpeg4, metadata


---

## 1 answers

### Answer by username_1 on 2016-05-18. Score: 3 | Accepted answer

Streaming formats maintain timestamps for each frame, whether audio or video, which govern when the player ought to present them. Those non-zero big start times usually occur when a snippet is cut out from a longer video and the tool used does not reset the timestamps. Although if this FLV was recorded on its own, then it's strange.
In any case, running the command below should fix the problem.
ffmpeg -i input.flv -c copy output.flv

> **Comments:**
> **username_0**: Thanks for the quick answer!  Yeah, I think the live stream's timecodes were retained when it was dumped, so it makes sense now.  Your ffmpeg timestamp-juggling was sorta solved the issue... it worked with the aforementioned example, however, I've tested it with another file which had the same issue (1 hour delay). That file is a product of some kind of Apple software, on which the command didn't worked as expected...  And I discovered another problem: it looks like some encoder libraries count the delay towards the total length, some of them doesn't, which is EXTRA confusing...  
> **username_1**: Show the complete console output of the command ran on the Apple file. Insert it into the Q.  
> **username_0**: Here you go. You basically answered the "why" part, so many thanks for your additional effort!  
> **username_1**: What's wrong with the Apple output? Looks fine.  
> **username_0**: Mediainfo still says that the delay is `<Delay>1h 0mn</Delay>`. FFmpeg hints the same with the `timecode        : 01:00:00:00` part... I think the particular problem with the .mov file is so rare, that it shouldn't take any further attention (basically 1 out of 1200+ other files).  
> **username_1**: That's a timecode, not a timestamp, and shouldn't affect duration detection. You can reset it: `ffmpeg -i in.mov -c copy -timecode 00:00:00:00 out.mov`  
> **username_0**: Damn, you're right, the output of mediainfo was pretty misleading in the latter case...  The `-timecode` option did the trick! Thanks!  

---

