Schneiden trotz Frame-Typ I-TTF fehlerhaft

[eumagga0x2a]

aber 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).

Du 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.

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?

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.

[Strunz]

Korrekt, 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.     

[eumagga0x2a]

Ich 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.

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.

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:

Code Select Expand

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.