Schneiden trotz Frame-Typ I-TTF fehlerhaft

[LuckyNoSlevin]

Wenn ich ein Video schneide, erhalte ich folgenden Fehlerhinweis. Obwohl ich mich an einer I-TTF Stelle befinde.
Das Merkwürdige ist, dass es fast immer funktioniert. Tritt der Hinweis auf, habe ich das Problem damit gelöst, zur nächsten I-TTF STelle zu gehen. Bei diesem Beispiel funktiniert es aber nicht.

[eumagga0x2a]

Ist der in der Warnung umrissene Sachverhalt unklar? Es kommt auf die Kombination des Start- und Endpunkts der Löschung an (auf POC der beiden Frames). Ergibt sich ein zurückgehender Zählerstand, gibt es Probleme bei FFmpeg-basierten Playern wie VLC, mpv, Avidemux selbst usw. Muss man auf diese Player keine Rücksicht nehmen, kann man die Warnung ignorieren (nur diese Warnung — die Warnung, wenn nicht an Keyframes geschnitten wird, darf man nie ignorieren).

Ob man gleich beim nächsten Keyframe einen Treffer landet und POC am Schnittpunkt ansteigt, ist reine Glückssache.

Keyframes in Open-GOP-Streams sind meist keine IDR-Frames, sie sichern nur zu, dass man zu diesem Frame springen kann und es keine nicht vollständig dekodierbaren Bilder danach geben wird. Sie stehen nicht dafür, dass man ein Stück aus der Mitte des Streams wegschneiden und trotzdem mit störungsfreier Wiedergabe rechnen darf. Sowas garantieren nur IDR-Frames, und IDR vermeiden Broadcaster einzusetzen, weil die Bandbreite beschränkt ist, und ein IDR-Frame verbraucht naturgemäß je nach Inhalt viel mehr Daten als Nicht-IDR "recovery points", sprich, ein IDR bedeutet automatisch miese Bildqualität.

[LuckyNoSlevin]

Ja, der Sachverhalt ist unklar. Ich glaube, wenn man sich nicht selbst intensiver damit beschäftigt hat, z.B. dafür selber programmiert hat, kann man es kaum verstehen.
Erkläre einem Laien einmal mit normalen Worten, wie er mit Hilfe der Backus-Normalform einen Compiler programmieren soll :-)
Also ist es so wie es ist. Das Schneiden an Keyframes beachte ich schon sauber. Im Grunde werden die Sendungen auf dem Fernseher abgespielt. Ein kurzes Flimmern bringt mir keine schalflosen Nächte.

Ich weiß jetzt, dass ich es nicht lösen kann.
Danke

[eumagga0x2a]

Ja, der Sachverhalt ist unklar.

Das ist schon wichtig zu wissen, da man in so einer Warnung komplizierte Probleme in wenigen Worten zu beschreiben versucht, und letzten Endes es doch nur für sich selbst verständlich erklärt.

Im Grunde werden die Sendungen auf dem Fernseher abgespielt. Ein kurzes Flimmern bringt mir keine schalflosen Nächte.

Das könnte ein Indiz dafür sein, dass der Player in der Fernseher-Firmware bzw. in einer darauf laufenden App FFmpeg benutzt :-)

[eumagga0x2a]

Ich weiß jetzt, dass ich es nicht lösen kann.

Wenn Neukodieren keine Lösung ist, dann in der Tat nicht. Avidemux versucht hier auch so schon eine Fünf gerade sein zu lassen.

[LuckyNoSlevin]

Ich habe ein Video, bei dem es aufgetreten ist, neucodiert. Das dauert einfach sehr lange. Das war nur ein 45min Video. Mit kurzem Flimmern kann man dann schon leben. Zumal es meistens geht.

Solche Dinge mit wenigen Worten zu erklären, ist fast nicht machbar. Was Du mir geschrieben hast wirkt fachlich kompetent. Deshalb kann ich gut mit der 2. besten Lösung leben.

[Strunz]

Btw. obwohl es ja diese sinnvolle Warnung gibt, hatte ich schon Videos, wo es, obwohl diese Warnung nicht kam, dennoch zu Problemen beim Abspielen an den Schnittpunkten kam. Es scheint also keine zuverlässige Methode zu geben, die Probleme vorab immer zu erkennen.

[eumagga0x2a]

Wenn dies mit 2.8.2er Nightlies, zumal mit Video komprimiert mit H.264 beobachtet wird, bitte ein Sample bereitstellen und die Schritte, die nötig sind, um das Problem zu reproduzieren, notieren. Danke.

[Strunz]

Wenn dies mit 2.8.2er Nightlies, zumal mit Video komprimiert mit H.264 beobachtet wird,

Wenn das auch auf mich bezogen war, habe das schon öfters bei der hiesigen ARD erlebt, die bekanntlich in h.264 sendet, immer mit der aktuellsten Nightly. Ob das jetzt schon 2.8.2 war, kann ich aber nicht sagen. Leider sind die aktuellen Nightlies unter Windows ja auch nicht brauchbar. Sollten sie es aber wieder sein, dann werde ich das mal testen. Ich hatte es aber eigentlich eh schon aufgegeben, das Schneiden ohne zu Encodieren, weil hinterher kam das pöse Erwachen.

[eumagga0x2a]

Leider sind die aktuellen Nightlies unter Windows ja auch nicht brauchbar.

Der letzte offizielle VC++ Nightly lief bei mir einwandfrei.

MinGW-kompilierte ("win64") Builds laufen auch, bloß nicht die offiziellen, sprich, man muss selber kompilieren. Die offiziellen Cross-Builds benötigen infolge der Aktualisierung der Build-Umgebung noch einige Fixes für Packaging die nur der Maintainer des Projekts machen kann.

Wenn das auch auf mich bezogen war, habe das schon öfters bei der hiesigen ARD erlebt, die bekanntlich in h.264 sendet

Für unterschiedliche Verbreitungswege werden unterschiedliche Streams verwendet, daher ist mindestens ein Sample mit genauen steps to reproduce unerlässlich.

[Strunz]

Für unterschiedliche Verbreitungswege werden unterschiedliche Streams verwendet, daher ist mindestens ein Sample mit genauen steps to reproduce unerlässlich.

Direkt mein erster und einziger Test machte Probleme. Während die ersten Schnitte ok waren, danach ging es den Bach runter. Es begann damit, dass Avidemux eine Warnung ausgab, diese habe ich gecancelt. Daraufhin bin ich zum nächsten Punkt gesprungen, auch da gab es eine Warnung, also zum nächsten und da gab es keine Warnung mehr. Vermutlich zu unrecht, denn ab da waren beim anschließenden Abspielen Klötzchen zu sehen. Ich weiß nicht, ob es nun an einer falschen Erkennung oder meinem wiederholten "Springen" lag. Das Ganze war eine Aufnahme des NDR aus dem Kabel. Ich habe Avidemux 2.8.2 230924-VC++ verwendet. Ich lade Dir 3 Minuten davon vom Original hoch und 1 Minute mit Klötzchen.  Ziel war es exemplarisch, nur das rosa T-Shirt im Export zu belassen.
Viel Glück, denn für mich hat die Funktionalität bisher noch nie wirklich funktioniert.   

[eumagga0x2a]

Es begann damit, dass Avidemux eine Warnung ausgab, diese habe ich gecancelt. Daraufhin bin ich zum nächsten Punkt gesprungen, auch da gab es eine Warnung, also zum nächsten und da gab es keine Warnung mehr.

Hier liegt ein tiefes Missverständnis vor. Einmaliges Verwerfen der Warnung über zurückgehenden POC deaktiviert die Warnung für die laufende Sitzung für das aktuell geladene Video (es kann valide Gründe geben, diese Warnung zu ignorieren, zum Beispiel, wenn man das Video für einen nicht auf libavcodec aufbauenden Player schneidet). Die zweite Warnung war vermutlich eine andere.

Ich schaue mir das Sample später an, danke.

[Strunz]

Hier liegt ein tiefes Missverständnis vor. Einmaliges Verwerfen der Warnung über zurückgehenden POC deaktiviert die Warnung für die laufende Sitzung für das aktuell geladene Video

Ausgehend von der angezeigten Warnung bin ich vom Gegenteil ausgegangen, das Bestätigen mit OK würde das deaktivieren. 

Ich schaue mir das Sample später an, danke.

Ich habe zu danken.

[eumagga0x2a]

Danke, alles funktioniert wie es soll. Die Warnung über zurückgehenden Zähler hat mit einigen nicht vollständig dekodierbaren "early B-frames" an Schnittpunkten nichts zu tun. Die Warnung informiert den Benutzer darüber, dass die Wiedergabe des im Kopiermodus exportierten Videos an dieser Stelle stocken kann (für wie lange, hängt davon ab, wie groß der POC-Rücksprung ausfällt).

Unabhängig davon, ob der Zähler kontinuierlich ansteigt, können einige Bilder nach dem Schnitt (das sind immer B-frames, die im Stream natürlich nach dem Keyframe beim Dekoder ankommen, aber vor dem Keyframe angezeigt werden) nicht vollständig dekodiert werden, weil sie Bilder aus dem gelöschten Segment des Videos referenzieren.

Bei obsoleten Codecs wie MPEG-2 und Xvid konnten "early B-frames" immer schadlos weggelassen werden. Bei H.264 und HEVC dürfen B-frames aber Daten enthalten, die von anderen Frames benötigt werden (ein Keyframe kann über mehrere Frames "verschmiert" werden, um Bitrate-Spitzen zu vermeiden). Avidemux berücksichtigt dies und belässt solche B-Frames im Video, obwohl sie nur mit Klötzchen dekodiert werden können. Frühe B-Frames, die nicht als Referenz benötigt werden, werden natürlich weggelassen.

Bei Avidemux-Builds vom aktuellen git master gilt das Verwerfen der POC-Warnung (ESC) als "Nein" (die Aktion nicht ausführen). Die Logik war früher möglicherweise buggy. Einmaliges Bestätigen der Aktion (das Akzeptieren des Dialogs durch Enter oder durch Klick auf "OK") deaktiviert die Warnung.

[Strunz]

Danke, alles funktioniert wie es soll.

Hab gerade den Kopf etwas voll, aber Du sieht die Klötzchen in meinem Export und Du sagst, es funktioniert wie es soll? Sprich, die Klötzchen sind nicht zu vermeiden?

Ich kenne den Hintergrund schon, hab aber wohl die Meldung falsch interpretiert.

Wenn die Klötzchen nicht zu vermeiden sind, obwohl von mir gesprungen wurde, bis keine Meldung mehr (mit welchem Inhalt auch immer) angezeigt wurde, dann ist das Ergebnis doch vollkommen unbefriedigend? Oder habe ich dich nicht verstanden?