Videometadaten: Wofür wird "Videoverzögerung" verwendet?

Kürzlich musste ich mich mit Videos herumschlagen, die einige spezielle Metadatenattribute haben, nämlich „delay“ oder „delay_relative_to_video“.

Es gibt eine Software-Videokonferenzlösung, die diese speziellen Dateien erstellt, und wenn unsere Videoverarbeitungssoftware diese Dateien untersucht, erhält sie längere Dauerwerte als die tatsächliche Länge des Inhalts, wodurch falsche Daten in der Datenbank gespeichert werden, was in der Nachbearbeitungsphase mehr Probleme verursacht.

Beispielsweise haben wir ein 46 Sekunden langes Video aufgenommen, das als 104,7 Sekunden lang erkannt wurde.

Nachdem die Datei mit FFmpeg und Mediainfo untersucht wurde, stellte sich heraus, dass die Originaldatei einen sogenannten "Verzögerungswert" hatte, der als startZeit in der Ausgabe von FFmpeg zu sehen ist:

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

...und Delayoder Delay_relative_to_videoin 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>

"Überraschenderweise" ergibt die Subtraktion der Länge und der Verzögerung die richtige Dauer ...

Außerdem ist es wirklich peinlich, dass einige Encoder-Bibliotheken diese Verzögerungen zur Gesamtlänge zählen, andere jedoch nicht! Anscheinend gibt es keine Möglichkeit zu unterscheiden, welche Längenwerte korrekt sind und welche entsprechend erhöht wurden!

Um es kurz zu machen, ich würde gerne wissen, wofür diese Metadaten verwendet werden? Was ist der Grund für ihre Existenz und warum fügen einige Encoder/Videobearbeitungssoftware diese Metadaten in die Datei ein?

Danke für eure Antworten im Voraus!

Bearbeiten:

Laut Mulvyas Antwort kann das Ausführen einer einfachen Stream-Kopie für die Datei die Zeitstempel zurücksetzen!

Es gab jedoch eine .mov-Datei, bei der es nicht funktionierte. Zugehörige Konsolenausgabe:

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%

Antworten (1)

Streaming-Formate verwalten Zeitstempel für jeden Frame, ob Audio oder Video, die bestimmen, wann der Player sie präsentieren soll. Diese großen Startzeiten ungleich Null treten normalerweise auf, wenn ein Ausschnitt aus einem längeren Video herausgeschnitten wird und das verwendete Tool die Zeitstempel nicht zurücksetzt. Obwohl, wenn dieses FLV alleine aufgenommen wurde, dann ist es seltsam.

In jedem Fall sollte das Ausführen des folgenden Befehls das Problem beheben.

ffmpeg -i input.flv -c copy output.flv
Danke für die schnelle Antwort! Ja, ich denke, die Timecodes des Live-Streams wurden beibehalten, als er abgelegt wurde, also macht es jetzt Sinn. Ihr ffmpeg-Zeitstempel-Jonglieren hat das Problem irgendwie gelöst ... es hat mit dem oben genannten Beispiel funktioniert, aber ich habe es mit einer anderen Datei getestet, die das gleiche Problem hatte (1 Stunde Verzögerung). Diese Datei ist ein Produkt einer Art Apple-Software, bei der der Befehl nicht wie erwartet funktioniert hat ... Und ich habe ein weiteres Problem entdeckt: Es sieht so aus, als würden einige Encoder-Bibliotheken die Verzögerung zur Gesamtlänge zählen, einige von ihnen nicht t, was EXTRA verwirrend ist ...
Zeigen Sie die vollständige Konsolenausgabe des Befehls an, der für die Apple-Datei ausgeführt wurde. Stecken Sie es in das Q.
Bitte schön. Sie haben im Grunde den "Warum" -Teil beantwortet, vielen Dank für Ihre zusätzliche Mühe!
Was ist falsch an der Apple-Ausgabe? Sieht gut aus.
Mediainfo sagt immer noch, dass die Verzögerung <Delay>1h 0mn</Delay>. FFmpeg deutet das gleiche mit dem timecode : 01:00:00:00Teil an ... Ich denke, das spezielle Problem mit der .mov-Datei ist so selten, dass es nicht weiter beachtet werden sollte (im Grunde 1 von 1200+ anderen Dateien).
Das ist ein Zeitcode, kein Zeitstempel, und sollte die Dauererkennung nicht beeinflussen. Sie können es zurücksetzen:ffmpeg -i in.mov -c copy -timecode 00:00:00:00 out.mov
Verdammt, Sie haben Recht, die Ausgabe von mediainfo war im letzteren Fall ziemlich irreführend ... Die -timecodeOption hat es geschafft! Danke!
Videometadaten: Wofür wird "Videoverzögerung" verwendet?
AntwortenHierDatenschutz-Bestimmungen1y, 0v