Avidemux Forum

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.

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.

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

Quote from: LuckyNoSlevin on September 20, 2023, 05:03:47 PMJa, 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.

Quote from: LuckyNoSlevin on September 20, 2023, 05:03:47 PMIm 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 :-)

Quote from: LuckyNoSlevin on September 20, 2023, 05:03:47 PMIch 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.

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.

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.

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.

Quote from: eumagga0x2a on September 26, 2023, 01:48:29 PMWenn 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.

Quote from: Strunz on October 14, 2023, 06:27:18 PMLeider 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.

Quote from: Strunz on October 14, 2023, 06:27:18 PMWenn 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.

Quote from: eumagga0x2a on October 14, 2023, 11:29:11 PMFü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.   

Quote from: Strunz on October 15, 2023, 04:41:53 PMEs 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.

Quote from: eumagga0x2a on October 16, 2023, 06:32:36 AMHier 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. 

Quote from: eumagga0x2a on October 16, 2023, 06:32:36 AMIch schaue mir das Sample später an, danke.

Ich habe zu danken.

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.

Quote from: eumagga0x2a on October 17, 2023, 06:26:31 PMDanke, 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?

Quote from: Strunz on October 17, 2023, 06:35:36 PMaber Du sieht die Klötzchen in meinem Export

Ich sehe sie in meinem (ich brauchte keinen Beispiel-Export, ich brauchte steps to reproduce, aber jetzt ist es ohne Belang).

Quote from: Strunz on October 17, 2023, 06:35:36 PMDu sagst, es funktioniert wie es soll? Sprich, die Klötzchen sind nicht zu vermeiden?

Korrekt, je nach Struktur des Streams sind sie nicht zu vermeiden – ein Nachteil von Open GOP.

Quote from: Strunz on October 17, 2023, 06:35:36 PMWenn 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?

Wie gesagt, die Warnung über zurückgehenden POC-Zähler hat mit diesen Klötzchen nichts zu tun. Das Ergebnis bei Missachtung der Warnung wäre aber noch viel vollkommener ( ;) ) unbefriedigend, wenn das Video in FFmpeg-basierten Playern wiedergegeben wird.

Quote from: eumagga0x2a on October 17, 2023, 06:49:41 PMKorrekt, je nach Struktur des Streams sind sie nicht zu vermeiden – ein Nachteil von Open GOP.

Ok, danke. Ich bin fälschlicherweise davon ausgegangen, dass Avidemuxx diese open GOPs erkennt und von deren Verwendung warnt und einen dann solange springen lässt, bis der GOP geschlossen ist und ein Schneiden in Copy-Mode gefahrlos (also ohne Klötzchen) möglich ist.
Aber dem ist wohl nicht so. Damit ist der Copy-Mode für mich auch weiterhin nicht nutzbar. Vielleicht könnte Avidemux eine Meldung ausgeben, die klarstellt, dass ein Schneiden in diesem Video ohne Fehler (Klötzchen) im Copy-Mode absolut nicht gewährleistet werden kann.

Dann wäre das klar und wenn die Quelle keine offenen GOPs benutzt, kann auch gefahrlos in Copy-Mode an den I-Frames geschnitten werden.     

Quote from: Strunz on October 17, 2023, 07:12:44 PMIch bin fälschlicherweise davon ausgegangen, dass Avidemux diese open GOPs erkennt und von deren Verwendung warnt und einen dann solange springen lässt, bis der GOP geschlossen ist und ein Schneiden in Copy-Mode gefahrlos (also ohne Klötzchen) möglich ist.

Dies wäre wirklich vollkommen unpraktisch. So gut wie alle ausgestrahlten DVB-Programme enthalten nur Open GOP Videostreams, wo äußerst selten mal ein IDR-Frame vorkommt. IDR Frames sind Gift für Qualität, weil die maximale Bitrate eines Streams im Multiplex beschränkt ist und ein IDR-Frame (außer wenn es kaum Bildinformationen enthält, zum Beispiel ist schlicht tiefschwarz) eine vergleichsweise sehr schlechte Qualität haben müsste, um dieses Limit nicht zu sprengen.

Quote from: Strunz on October 17, 2023, 07:12:44 PMVielleicht könnte Avidemux eine Meldung ausgeben, die klarstellt, dass ein Schneiden in diesem Video ohne Fehler (Klötzchen) im Copy-Mode absolut nicht gewährleistet werden kann.

Diese Meldung würde je nach Stream bei (fast) allen Keyframes fällig sein und wäre damit mehr ein Ärgernis als eine Hilfe. Ein sicheres Mittel, die Anwesenheit von "early B-frames" festzustellen, wäre die Skriptkonsole in Avidemux zu benutzen:

ed = Editor()
for frame in range(300):
    ed.printFrameInfo(frame)
Wenn in der Ausgabe für die ersten 300 Frames, die daraufhin ans Avidemux-Log (unter Windows in %localappdata%\avidemux\admlog.txt) angehängt wird, ein B-frame ("B") direkt auf ein Keyframe ("I") folgt, ist es Open GOP wo kein sauberes Löschen von innenliegenden Segmenten möglich ist. Und wenn einmal Open GOP vorliegt, kann man mit hoher Wahrscheinlichkeit davon ausgehen, dass auch alle nachfolgenden GOPs so beschaffen sind.

Flags "0110" weisen spezifisch auf ein IDR Frame hin, Flags "0010" generell auf ein Keyframe.