Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-18T15:31:04.490Z
Answers.Text: 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...
Answers.UserDisplayName: Gergely Lukacsy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-18T15:36:58.447Z
Answers.Text: Show the complete console output of the command ran on the Apple file. Insert it into the Q.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-18T15:48:34.293Z
Answers.Text: Here you go. You basically answered the "why" part, so many thanks for your additional effort!
Answers.UserDisplayName: Gergely Lukacsy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-18T15:55:45.970Z
Answers.Text: What's wrong with the Apple output? Looks fine.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-18T16:03:15.583Z
Answers.Text: 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).
Answers.UserDisplayName: Gergely Lukacsy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-18T16:15:55.053Z
Answers.Text: 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`
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-19T08:37:37.963Z
Answers.Text: Damn, you're right, the output of mediainfo was pretty misleading in the latter case...
  
  The `-timecode` option did the trick! Thanks!
Answers.UserDisplayName: Gergely Lukacsy
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-18T14:10:34.007Z
Answers.LastActivityDate: 2016-05-18T14:10:34.007Z
Answers.UserDisplayName: Gyan
Body: <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>
  
Tags: <ffmpeg><conversion><timecode><mpeg4><metadata>
Title: Video metadata: What is "Video delay" used for?
UserDisplayName: Gergely Lukacsy
ThreadText: # 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
  
  <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%
  
  ```
  
  **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!  
  
  ---
  
  