AVC-Video: Abläufe im Video zu schnell / Abspielzeit aber offenbar normal

  • Hallo,


    ich habe eine Videodatei mit der Bezeichnung videoname.264 erhalten, das angeblich mit einer WebCam aufgenommen wurde.


    Die Software MEDIAINFO zeigt folgendes an:

    Wenn ich dieses Video mit VLC oder MPC-HC abspiele, wird die Abspielzeit offenbar korrekt im Player angezeigt (d.h. 1 Sekunde ENTSPRICHT auch einer 1 Sekunde), aber die Abläufe auf dem Video, etwa gehende Personen, bewegen sich m. E. unnatürlich schnell. Woran könnte das liegen? Wie ermittelt denn ein Player wie VLC oder MPC-HC die korrekte Abspieldauer passend zu den Frames?


    Kann es sein, dass der Ersteller des Videos beim Schnitt (ich vermute, ich habe einen Ausschnitt erhalten) etwas "falsch" gemacht hat und sich daduch o. a. "Phänomen" erklären lässt?

    Wenn ich bspw. mir mit Mediainfo Daten zu einer Videodatei anzeigen lasse, die ich mit meinem Smartphone erzeugt habe, wird in der Sektion VIDEO weitaus mehr angezeigt, bspw.:



    Lässt sich das eingangs beschriebene Problem dadurch erklären, dass in der erzeugten H264-Datei irgendwelche wichtigen Informationen fehlen?

    Gibt es eine Korrekturmöglichkeit für das geschilderte Problem?



    Herzlichen Dank im voraus und viele Grüße

    testit2007

  • Ja, wahrscheinlich fehlt in der Kopie die Timing-Information einer ursprünglich variablen Framerate (VFR). Die beizubehalten ist recht aufwändig, da die meisten Konverter von einer konstanten Framerate (CFR) ausgehen, also jede Szene gleich schnell abzuspielen ist. Man müsste die Timecodes vor der Konvertierung aus dem Original extrahieren und sie im Anschluss wieder in die Kopie einfügen. Wenn ich mich recht erinnere, müsste das für den MP4- und MKV-Kontainer möglich sein. Ein roher H.264-Videostream wird die wohl nicht speichern können.

  • Hallo!


    Erstmals vielen Dank für Deine Antwort!


    Was ich nicht ganz verstehe: Was ist ein "roher" H.264-Videostream?
    Oder anders formuliert: Ist es nicht so, dass das komplette Video, aus dem der Auszug stammt, bspw. H.264/MPEG-4 AVC codiert war?

    Ich kann mir nicht vorstellen, dass H.264/MPEG-4 AVC-Videos prinzipiell die gefilmten Abläufe zeitlich völlig falsch wiedergeben.


    Verstehe ich das richtig, dass davon ausgegangen werden muss, dass das angeblich mit einer Webcam gefilmte Video anschließend KONVERTIERT wurde und dabei ein Konverter genutzt wurde, der nicht dazu in der Lage war, die VFR-Informationen miteinzubinden?


    Danke und viele Grüße
    testit2007

  • H.264/MPEG-4 AVC-Video kann in Kontainern (z.B. MP4) enthalten sein (in dem sich vielleicht auch Tonspuren und andere Daten befinden könnten), aber auch außerhalb von jeglichen Kontainern als Datei gespeichert sein. Ein "roher" H.264/MPEG-4 AVC-Video-Datenstrom enthält dann zwar den Videoinhalt, aber unter Umständen nicht sämtliche Eigenschaften, die zum korrekten Abspielen interessant wären; und er enthält garantiert nichts anderes als das Video (also keine Tonspuren).


    Wie ein Glas KiBa: "roh" wäre nur der Bananensaft ohne Glas, und ohne Kirschsaft.


    Leider kann man sich auf Dateiendungen unter Windows nicht verlassen. Die Endung ".264" weist zwar grob darauf hin, dass H.264/MPEG-4 AVC-Video enthalten ist, aber man kann nicht ausschließen, dass vielleicht doch ein Kontainer drum herum existiert. Du hast aus dem MediaInfo-Report leider nur den Video-Anteil veröffentlicht. Oder war tatsächlich nicht mehr als das aufgelistet?

  • Vielen Dank für die Erklärung!


    Hier das Ergebnis der EXPORT-Datei aus MediaInfo:



    Viele Grüße

    testit2007

  • Nach diesem Bericht enthält die Datei C:\video.h264 tatsächlich nur das rohe Video. Es könnte also nur ein Teil einer vollständigen Aufnahme sein, die im Original sicherlich mal in einem Kontainer steckte, der dann auch die Timestamps enthielt, durch die eine Anpassung an die tatsächliche Aufnahmegeschwindigkeit möglich war.


    Du hast was von "Webcam" geschrieben; es ist gut möglich, dass solche Systeme bei Ruhe im Bild schnellere Bildfolgen komprimieren können, bei sehr viel Bewegung aber mehr Zeit brauchen und dadurch seltener ein Bild speichern, also in solchen Szenen mit geringerer Bildrate aufzeichnen.


    Wenn du nicht an die tatsächliche Originalaufnahme mit Kontainer herankommst, wird es wahrscheinlich nicht so leicht möglich sein, allein aus der Videospur wieder eine gleichmäßig wirkende Abspielgeschwindigkeit zu konstruieren.

  • Wenn ich dieses Video mit VLC oder MPC-HC abspiele, wird die Abspielzeit offenbar korrekt im Player angezeigt (d.h. 1 Sekunde ENTSPRICHT auch einer 1 Sekunde), aber die Abläufe auf dem Video, etwa gehende Personen, bewegen sich m. E. unnatürlich schnell.

    Bist du sicher, dass nicht das gesamte Video zu schnell abgespielt wird? Also das dein Video nicht doch in einer konstanten Framerate aufgenommen wurde, es bei dir aber nur insgesamt zu schnell wiedergegeben wird.


    Das wäre deine einzige Chance ohne das Originalvideo. Wenn die Framerate bei der Aufnahme variable ist, kannst du das nicht mehr korrigieren.


    Ich würde das Video mittels mkvtoolnix in einem MKV Container muxen und dabei verschiedene FPS (24,25,30,50,60) probieren. Vielleicht hast du ja Glück.


    XYBIekH.png

  • Wäre auch eine mögliche Lösung. Bei Webcams dürften es sogar auch noch geringere Frameraten sein (15, 12, 10). Auf jeden Fall einen Versuch Wert!


    Dem rohen H.264-Videostrom fehlt ja oft schon überhaupt irgendein Framerate-Flag, da kann ein Player schon mal einen zu schnellen Standardwert annehmen. Die Spieldauer wird dann über Durchzählen und statistisches Hochrechnen teilweise überraschend genau geschätzt, wenn die Aufzeichnung relativ konstante Bitraten encodiert.

  • Vielen Dank, ich werde das ausprobieren!

    Wenn ich im VLC-Player ZWEI MAL auf GESCHWINDIGKEIT LANGSAMER klicke, wirken die Bewegungsabläufe natürlich, vielleicht einen TICK zu langsam.
    Das Ganze läuft dann wohl in ca. halber Geschwindigkeit ab. Insofern könnte auch LigH mit den niedrigen WebCam-Framerates richtig liegen.


    Viele Grüße

    testit2007




    Allerdings wird dann unter

  • Hallo,


    das Problem wird sein, dass ich - auch mit VirtualDub - wohl kaum werde entscheiden können, ob 12,13,15 fps der Originalaufnahme zugrunde lagen.
    Das allein an Bewegungen auf dem aktuellen Video fest zu machen, ist m. E. recht spekulativ.


    Inzwischen weiß ich, dass die ORIGINAL-Aufnahme, die mir nicht vorliegt, von einer Webcam Starcam C7837WIP gemacht wurden, die folgendes in ihrer Spezifikation stehen hat:


    Encode format: H.264 main profile@level:4.0/Motion-JPEG/JPEG

    Three Stream:

    Main Stream:720p(1280X720)@25fps

    Sub Stream:360p(640X360)@25fps

    Third Stream:180p(320X180)@10fps

    Bit Rate: 128~4096kbps

    Maximum frame rate: 25fps


    Ob sich bei 720p@25fps auch frei andere fps-Werte einstellen lassen, ist dem Manual nicht zu entnehmen.
    Auch zu VFR oder CFR finde ich keine Angaben.



    Viele Grüße

    testit2007

  • Tja, wie wichtig ist die Kenntnis der exakten Geschwindigkeit? Würden geringe Abweichungen auffallen?


    Für mich erscheinen die folgenden zwei Fälle am wahrscheinlichsten:


    a) Bei geringer Helligkeit verwendet die Kamera exakt die halbe Framerate (12.5 fps) durch "Verdopplung" der Anzeigedauer (z.B. durch Skip Frames).

    b) Die Kamera arbeitet wirklich adaptiv (dann ist ohne VRF-Timecodes nichts zu ermitteln oder gar wiederherzustellen).

  • Die exakte Geschwindigkeit wäre wichtig.


    Was a) und b) betrifft, müsste doch eigentlich in der techn. Beschreibung vermerkt sein, was "Sache" ist.

    Bislang ergibt sich aber nicht einmal ein Anhaltspunkt dafür, dass die Kamera VRF geschweige denn bei 720p Frameraten < 25 beherrscht.


    Ich habe fast den Eindruck, dass beim Schneiden der Konverter falsch eingestellt und die Framerate heruntergesetzt hat.

    Viele Grüße

    testit2007

  • kleine Anmerkung dazu was mir beim Überfliegen auffällt:

    1. MKVToolnix ist 30.1 aktuell, seit v25 hat sich einiges verbessert,...

    2. Falls der Name der Datei im Screenshot von MKV dazu gehört würde ich vermuten, dass der Videostream eventuell mal 23,976fps war, dann per stretch auf 25fps gebracht wurde, ein deutsch Audiostream druntergeschoben wurde und Du dann den gestreckten Stream geschnitten hast. Beim Schneiden die TimeCodes nicht sauber berücksichtigt bzw. über das 'stretching' gestolpert wurde.


    Zitat

    Bislang ergibt sich aber nicht einmal ein Anhaltspunkt dafür, dass die Kamera VRF geschweige denn bei 720p Frameraten < 25 beherrscht.


    Web- und Handycams erzeugen oft vfr Material, da dass ihre Art ist mit dropped Frames klar zu kommen.


    Cu Selur

  • ...

    2. Falls der Name der Datei im Screenshot von MKV dazu gehört ...
    ...

    Web- und Handycams erzeugen oft vfr Material, da dass ihre Art ist mit dropped Frames klar zu kommen.


    Cu Selur

    Hallo,


    nein, der Screenshot gehört nicht zur Ausgangsfrage dazu und wurde von User Monarc99 eingestellt.


    Was VFR angeht, hatte ich ja bereits geschrieben, dass sich diesbezüglich kein Anhaltspunkt aus der techn. Spezifikation zur Webcam entnehmen lässt.

    Viele Grüße

    testit2007

  • Vielleicht bietet dir VirtualDub2 die richtige Umgebung, die Framerate zu finden und das Ergebnis dann als MP4 oder MKV zu speichern (ohne Neucodierung, "Video: Direct Stream Copy").

    Hallo,


    zum Verständnis: Das Ergebnis wäre vermutlich nicht anders als jenes, das ich mit der von Monarc99 empfohlenen Methode via mkvtoolnix erziele?

    Oder ist mkvtoolnix nicht in der Lage, ohne Neucodierung zu arbeiten?


    Danke und Gruß

    testit2007

  • Das die Spezifikation der der Webcam nicht vfr erwähnt war zu erwarten.

    Wenn Du die Datei mit uns Teilen kannst (oder eine vergleichbare Datei mit der das Problem auch auftritt), könnte man sich die Datei angucken.


    Cu Selur

    Hallo Selur,


    naja, ich bin schon der Meinung, dass so etwas in die techn. Datenblätter hinein gehört.

    Leider kann ich die Datei nicht teilen (auch, wenn ich dies gern täte), weil darauf auch Spaziergänger zu sehen sind.


    Viele Grüße

    testit2007

  • Hallo allerseits,


    wenn ich das betreffende Video im VLC Player mit 0,59-facher Geschwindigkeit abspiele, wirken die Bewegungen auf dem Video (Autos und Spaziergänger) realistisch. Das dürfte etwa 15 fps entsprechen.


    Das Problem ist, dass VLC leider nur Sekunden beim Abspielen anzeigt, was mir nicht hinreichend genau ist.
    Im MediaPlayerClassic (MPC) kann ich ein höher aufgelöste Abspielzeit aktivieren, finde dagen im MPC keine Möglichkeit, die Abspielgeschwindigkeit auf 0,59x einzustellen. "Langsamer" abspielen führt im MPC zu 0,5x.


    Gibt es einen Player, der die Abspielzeit - wie der MPC - auch in 10tel und 100tel Sekunden anzeigt UND es zulässt, die Abspielgeschwindigkeit genau auf 0,59x Speed zu setzen?


    Falls nein, werde ich wohl - korrigiert mich bitte, wenn ich das falsch sehe - bspw. mit VirtualDub2 das Video ohne Neunencoding (wie oben von LigH beschrieben) speichern müssen, um es dann mit MPC auch mit Anzeige von 10tel und 100tel Sekunden abspielen zu können.


    Danke für die Unterstützung!

    Viele Grüße

    testit2007

  • Eine Kopie speichern solltest du auf jeden Fall. Schon allein weil Videos in einem Container zuverlässiger behandelt werden als ein roher Videodatenstrom. Wie bereits erwähnt, wird gerade die Framerate manchmal nicht in einer 264-Datei hinterlegt.


    Herumspielen kannst du recht detailliert mit AviSynth, einer Skriptsprache zur Manipulation von Videos. VirtualDub2 arbeitet damit recht gut zusammen, hat auch einen integrierten Editor, du kannst damit also ein Skript bearbeiten und dann das in VirtualDub2 geladene Video (als Ausgabe aus dem Skript) auffrischen, um gleich darauf die Änderungen zu begutachten (File - Info zeigt technische Daten an, auch die Spieldauer in Millisekunden).


    Beachte, dass AviSynth immer decodiert. Zum verlustlosen Ändern von Eigenschaften einer komprimierten Videodatei ist es nicht geeignet. Aber man kann damit zunächst die Werte ermitteln, die man danach der eigentlichen Kopie übergibt. Leider muss man für die Videobearbeitung mit AviSynth einiges lernen (sowohl die Skriptsprache als auch die Erfahrung, die passenden Plugins auszuwählen). Aktuell zu empfehlen ist AviSynth+ in der MT-Variante von pinterf; dazu L-SMASH Works als ein Quellplugin, das 264-Dateien lesen können sollte. Am Ende könnte ein Skript etwa so aussehen:


    PHP
    1. LoadPlugin("LSMASHSource.dll")
    2. LwLibavVideoSource("dashcamvideo.264")
    3. AssumeFPS(15000, 1000) # (Dividend, Divisor)