I-Frames werden nur alle 3 Sekunden angezeigt

Started by Tiger-Fun, December 31, 2021, 07:13:42 PM

Previous topic - Next topic

Tiger-Fun

Hallo, ich habe folgende Frage.
Das Quellmaterial das ich schneiden will hat ein GOP von 30 bei ebenfalls 30 Frames pro Sekunde. Also müßte ja auch jede Sekunde ein I-Frame erstellt werden an dem ich schneiden kann (in LosslesCut wird mir auch jede Sekunde ein I-frame angezeigt).

Wenn ich das Video jedoch in avidemux einlese kannn ich mit den Schnitttasten immer nur in 3 Sekunden Intervallen vor und zurückspringen um zu schneiden.

Muß mich noch was umstellen um sekundengenau schneiden zu können?
Danke schon mal für die Unterstützung

eumagga0x2a

Quote from: Tiger-Fun on December 31, 2021, 07:13:42 PMWenn ich das Video jedoch in avidemux einlese kannn ich mit den Schnitttasten immer nur in 3 Sekunden Intervallen vor und zurückspringen um zu schneiden.

Geht es um Version 2.8.0 von Avidemux? Wenn es nicht die aktuelle 2.8.0 ist, bitte zuallererst auf 2.8.0 aktualisieren – ältere Versionen werden nicht mehr unterstützt.

Wenn es sich um Avidemux unter Windows handelt, bitte admlog.txt aus %localappdata%\avidemux\ vom Laden dieses Videos an die Antwort anhängen.

Quote from: Tiger-Fun on December 31, 2021, 07:13:42 PMMuß mich noch was umstellen um sekundengenau schneiden zu können?

Wenn die GOP-Länge 30 ist und FPS ~30 Bilder pro Sekunde beträgt und der Encoder keinen Open-GOP-Stream erzeugt (ich gehe von H.264 oder HEVC aus), so dass alle Keyframes IDR sind, sollte Avidemux im Kopiermodus sekundengenau schneiden können.

Tiger-Fun

Ja, es geht um die Version 2.8.
Quelldatei ist mp4.
Admlog.txt ist angehängt.

Nebenbei - wenn ich die Datei mit Avidemux 2.7.1 öffne, werden mir P-Frames mit sekundengenauem Schnitt angeboten.

Danke für die Unterstützung

eumagga0x2a

Der Hauptunterschied zwischen alten Versionen (vor 2.7.8, wenn ich mich nicht irre) und 2.8.0 beim Öffnen von MP4-Dateien mit H.264-komprimiertem Video besteht darin, dass sich alte Versionen auf die Informationen vom Container verließen, während die neuen Slice Headers von allen Frames dekodieren, um den Typ von jedem Frame genau zu bestimmen (alte Versionen konnten nicht zwischen P- und B-Frames in MP4 unterscheiden, was für Copy Mode ein Problem darstellte).

Falls die Funktion, die diese Analyse durchführt, fehlerhaft arbeitet, können dabei auch falsche Typbestimmungen herauskommen :-) Sofern das Video harmlos und nicht von intimer Natur ist, bitte ein kurzes (~1 Minute lang) Sample vom Video über WeTransfer, Mega, Dropbox oder Google Drive bereitstellen, damit ich dies überprüfen kann. Es sollte reichen, ein Stückchen im Kopiermodus (gerne ohne Audio) zu exportieren.

eumagga0x2a

Übrigens, die Statistik vom Dekodieren der ersten 100 Frames

[ADM_Composer::addFile] 12:49:45-779 H264 sometimes has invalid timestamps which confuse avidemux, checking

(Unwichtige Meldungen gelöscht)

[ADM_Composer::checkForValidPts] 12:49:46-422 -------- Stats :----------
[ADM_Composer::checkForValidPts] 12:49:46-422 nbBFrames:0
[ADM_Composer::checkForValidPts] 12:49:46-422 nbPFrames:97
[ADM_Composer::checkForValidPts] 12:49:46-422 nbIFrames:1
[ADM_Composer::checkForValidPts] 12:49:46-422 nbNoImage:2
[ADM_Composer::checkForValidPts] 12:49:46-422 nbPtsgoingBack:0
[ADM_Composer::checkForValidPts] 12:49:46-422 -------- /Stats ----------

legt den Schluss nahe, dass der Abstand von mindestens 100 Frames zwischen Keyframes der Realität entspricht.

Tiger-Fun

Laut dem Techniker der die Aufnahme steuert, erlaubt die Kamera/Software keine direkt Einstellung des I-Frams sondern bietet GOP 30 als Voreinstellung an.

Einen ca. 1 Minuten langen Schnipsel aus dem Vdeo findest du hier:
https://drive.google.com/file/d/10AvwJiRLyVZF-Wv0GxBUXCdGnaDRFLS6/view?usp=sharing

Das Stück mußte ich mit Avidemux 2.7.8 schneiden da bei 2.8 zu einen heftigen Bild/Ton Versatz kommt.

eumagga0x2a

Danke, jetzt wird einiges klarer. IDR-Frames, die einzig für sauberen Schnitt geeignet sind, liegen in diesem H.264 Stream 3 Sekunden voneinander entfernt. Allerdings gibt es zwischendurch auch Nicht-IDR-Frames, die Informationen (SPS und PPS NALUs) beinhalten, um von denen die Dekodierung zu starten. Sie werden nicht als Keyframes anerkannt weil die dafür erforderlichen SEI NALUs im Stream komplett fehlen. Wenn der H.264 Encoder in der Kamera nicht dazu gebracht werden kann, SEI zu generieren und auch in den Stream einzufügen, sind diese Hätte-sein-können-Keyframes leider völlig nutzlos.

Quote from: Tiger-Fun on January 03, 2022, 09:27:48 AMDas Stück mußte ich mit Avidemux 2.7.8 schneiden da bei 2.8 zu einen heftigen Bild/Ton Versatz kommt.

Das kann ich mit dem Sample nachvollziehen. Die Ursache ist dass der H.264 Stream keine Timing-Informationen beinhalten während die Bildrate der Kamera wild schwankt. Bei Matroska versucht Avidemux, dahinter eine Standard-Bildfrequenz zu erraten, was hier leider auch gelingt :-D

Avidemux 2.7.8 ist einfach schlechter im FPS-Raten, was in diesem Problemfall von Vorteil (und überall sonst von massivem Nachteil) ist.

Das Neukodieren mit dem "Bildfrequenz ändern"-Filter von NTSC (29,97 FPS) nach 30 FPS erzeugt beim Speichern mit dem MP4 Muxer ein gut synchronisiertes mp4 Video.

Tiger-Fun

Danke für die Rückmeldung, werde mit dm Techniker mal sprechen was das seitens der Kamera/Software machbar ist.

eumagga0x2a

Ich würde schlicht und einfach das Originalvideo mit dem "Resample FPS" Filter ohne Interpolation und 30 FPS als Zielfrequenz mit gewünschten Einstellungen im Bezug auf Qualität und GOP-Länge mit x264 neu kodieren. Die gute visuelle Qualität des Materials sorgt meines Erachtens für die nötige Reserve.

Tiger-Fun

Ja, ist sicher eine Möglichkeit. Wobei gerade die Möglichkeit zu schneiden ohne neu zu codieren zu müssen für mich nicht unwichtig ist (Zeitfaktor, geschnittenes Video nach Aufzeichung zeitnah online, max 4 Wochen online - dann weg).

eumagga0x2a

Dann sollte man IMHO an der Quelle ansetzen und in eine andere Kamera investieren. Zum Beispiel, die populäre Lumix DC-GH5 erzeugt einwandfreie H.264 Streams mit konstanter Bildrate, die problemlos im Kopiermodus geschnitten werden können. Was für Erzeugnis zeichnet sich für diesen, streng genommen kaputten H.264 Stream verantwortlich?

Tiger-Fun

Ich frag den Techniker mal nach Hersteller bzw. Typenbezeichnung.

Tiger-Fun

Vom Techniker folgende Info erhalten:
"Kamera eine Sony SRG-300H (verwendet wird der HDMI Ausgang).
Das Encoding, Recording und Streaming wird von einem Extron SMP 111 erledigt."

Tiger-Fun

#13
So, nachdem der Techniker die neuste Firmware aufgespielt hat, in der man nun die I-Frame auf 1 Sekunde setzen kann, klappt das mit dem Sprung und Schnitt in 1 Sekunden Intervallen problemlos. Jedoch nur in der Version 2.78 - bei Version 2.8 ist Bild und Ton (nach dem einlesen in AVIdemux) nicht mehr synchron.


eumagga0x2a

Quote from: Tiger-Fun on January 05, 2022, 04:37:05 PMDas Encoding, Recording und Streaming wird von einem Extron SMP 111 erledigt."

Sorry, habe deine Antwort von vor zwei Wochen erst jetzt bemerkt. Sehr interessant. Ein Profi-Gerät, Schrott als Ergebnis. Vermutlich würde ein starker Rechner mit OBS drauf das Problem lösen und dabei weniger kosten.

Quote from: Tiger-Fun on January 17, 2022, 09:56:44 AMJedoch nur in der Version 2.78 - bei Version 2.8 ist Bild und Ton (nach dem einlesen in AVIdemux) nicht mehr synchron.

Gleich beim Öffnen von MP4-Dateien, die SMP 111 erzeugt? Oder erst nach dem Remuxen zu MKV? Anscheinend hat die aktuelle Firmware weder das Problem der fehlenden Zeitbasis im H.264-Stream noch das der schwankenden Bildrate gelöst.