3

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%
Improve this question

1 Answer 1

Reset to default
3

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
Improve this answer
7
  • 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
    Commented May 18, 2016 at 15:31
  • Show the complete console output of the command ran on the Apple file. Insert it into the Q.
    – Gyan
    Commented May 18, 2016 at 15:36
  • Here you go. You basically answered the "why" part, so many thanks for your additional effort!
    – Gergely Lukacsy
    Commented May 18, 2016 at 15:48
  • What's wrong with the Apple output? Looks fine.
    – Gyan
    Commented May 18, 2016 at 15:55
  • 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
    – Gyan
    Commented May 18, 2016 at 16:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.