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

<track type="Video">
(...)
<Delay>0</Delay>
<Delay>00:00:00.000</Delay>
<Delay__origin>Container</Delay__origin>
<Delay__origin>Container</Delay__origin>
</track>

<track type="Audio">
(...)
<Delay>58036</Delay>
<Delay>58s 36ms</Delay>
<Delay>58s 36ms</Delay>
<Delay>58s 36ms</Delay>
<Delay>00:00:58.036</Delay>
<Delay__origin>Container</Delay__origin>
<Delay__origin>Container</Delay__origin>
<Delay_relative_to_video>58036</Delay_relative_to_video>
<Delay_relative_to_video>58s 36ms</Delay_relative_to_video>
<Delay_relative_to_video>58s 36ms</Delay_relative_to_video>
<Delay_relative_to_video>58s 36ms</Delay_relative_to_video>
<Delay_relative_to_video>00:00:58.036</Delay_relative_to_video>
</track>

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


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


11950: <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>
 1871: <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>
