Problem mit dem Ende eines Resultats-Videos

[ted]

Ich hatte eine x264/MKV mit Avidemux geschnitten.
Die gleichen Schnittpunkte dann in einem anderen Video-Programm gesetzt.
Die Längen der Ergbniss-Videos waren 8 Sekunden unterschiedlich.
Viel zu lang für Rundungsfehler und dergleichen.
Also habe ich mich auf die Suche nach den Gründen gemacht und die Ergebnisse näher untersucht. Dabei ist mir folgendes aufgefallen:

PY + MKV:  https://we.tl/t-cRzkt3fjnP
PY ausführen.
Ergebnis in Avidemux laden.
Navigation / Letztes Frame
4 mal 'Ein Frame zurück' -> Bilder 4 bis 1 sichtbar.
1 mal 'Ein Frame vor' -> Bild 1 sichtbar.
1 mal 'Ein Frame vor' -> Bild 2 sichtbar.
1 mal 'Ein Frame vor' -> Bild 2 bleibt stehen!
1 mal 'Ein Frame vor' -> Bild 4 sichtbar.

Wenn man eine Bildserie erstellen lässt, fehlt Bild 3.
Man kann auch einen anderen Schnittpunkt setzen, das Problem taucht immer auf.
Auch mit anderen Videos. Ich habe bewusst ein Video verwendet, wo man nach jedem Frame-Sprung genau 1 Frame weiterkommt. Manche Videos springen zum nächsten Frame erst nach 2 Framesteps (wg Halbbildern?). Dann wird es richtig schwierig, das oben dargestellte Problem nachzubilden und hat mich zuerst sehr verwirrt.

Ich hoffe, die Test-MKV ist korrekt auf dem Server gelandet.
Bevor das obigen Problem nicht erklärt werden kann, werde ich mit weiteren Untersuchungen erst mal warten. Ein Schritt nach dem anderen.

[eumagga0x2a]

WFM (works for me) mit git master + meine Patches, die Handhabung von konstanten und variablen FPS verbessern sollen. Wenn sich das Problem auf Legacy beschränkt, befürchte ich, dass dies ist WONTFIX.

[ted]

> WFM (works for me) mit git master + meine Patches

Entspricht das der aktuellen Beta?

Was ich vergaß:
Mein System: Win7 x32
Verwendet: Avidemux 2.7.5 (191130_e6196241270-fflibs 3.3.9)

[ted]

Es ist frustierend, dass Sie nicht das gleiche Verhalten feststellen können.
Ich will es sicherheitshalber noch einmal ausführlich darstellen:

PY + MKV:  https://we.tl/t-cRzkt3fjnP
PY in Avidemux laden.
Erstes Frame = 00:00:00.080 / 00:00:25.880
Letztes Frame = 00:00:25.840 / 00:00:25.880
Avidemux / Eigenschaften: 
   Gesamtdauer = 00:00:25,880 (kann das richtig sein? Siehe unten)
Ergebnis x.MKV auf die Platte schreiben.
Avidemux beenden.
Avidemux mit x.MKV starten.
4 mal 'Ein Frame zurück' -> Bilder 4 bis 1 sichtbar.
1 mal 'Ein Frame vor' -> Bild 1 sichtbar.
1 mal 'Ein Frame vor' -> Bild 2 sichtbar.
1 mal 'Ein Frame vor' -> Bild 2 bleibt stehen!
1 mal 'Ein Frame vor' -> Bild 4 sichtbar.
Wenn man eine Bildserie erstellen lässt, fehlt Bild 3.

Zusätzlich zu dem oben Geschriebenen:
Ich glaube, mit der Ergebnis-MKV stimmt etwas nicht.
Mediainfo zeigt für x.MKV:  Duration: 25 s 880 ms
Müsste von den 880 nicht die 80 msek vom ersten Frame abgezogen werden?
Denn andere Videoprogs haben wegen dieser falschen Duration am Video-Ende Navigations-Fehler.
Wenn man die x.MKV mit MKVToolkit neu schreiben lässt, hat die 'x (1).mkv' die Dauer 25 s 800 ms, also 80 ms weniger.
Wenn ich mit anderen Video-Programmen die Test.mkv genauso wie mit Avidemux schneide, erhalte ich kürzere Duration-Zeiten. Die Frame-Anzahlen sind jedoch identisch.

[eumagga0x2a]

> WFM (works for me) mit git master + meine Patches

Entspricht das der aktuellen Beta?

Nein. Offizielle 32bit-Builds werden von einem anderen Git-Zweig erstellt, in dem noch ein Uralt-FFmpeg verwendet wird – die letzte Version, die noch mit Windows XP kompatibel ist. Etliche Änderungen und Verbesserungen aus dem git master sind daher schlicht nicht anwendbar.

Windows 7 ist in wenigen Wochen sowieso EOL, die Zeit kommt für den Wechsel auf 64-bits-fähige Hardware.

Die höhere Länge ergibt sich aus dem Vorhandensein von B-Frames im Video. Avidemux benutzt einen vorzeichenlosen Datentyp für Zeitstempel und kann für den durch B-Frames notwendigen Vorlauf keine negativen Zeitstempeln einsetzen. Stattdessen wird das ganze Video verzögert.

[ted]

> Entspricht das der aktuellen Beta?
>> Nein. Offizielle 32bit-Builds werden von einem anderen Git-Zweig erstellt

Dann kann ich meine Beispiele (die Arbeit machen) auch an Adobe schicken, macht in etwa genauso wenig Sinn. Wenn die Verantwortlichen andere Versionen verwenden, als der Normaluser. Release, Beta, Git-Version, fehlt noch was?

Gestern habe ich so viele Stunden damit verbracht, um herauszufinden, warum die von mir beobachteten Probleme bei Ihnen nicht auftauchen, ob man das auch bei mir provozieren kann, ob andere Tools vielleicht das Verhalten ändern, usw. Die Arbeit hätte ich mir sparen können. Normalerweise testet ein Verantwortlicher eine Fehlermeldung mit allen Versionen kurz durch, die zur Verfügung stehen. Oder fragt nach, welche Version verwendet wurde, falls der Melder die Angabe vergisst. So erfährt man dann nebenbei, dass der Tester eine ganz andere Programmversion verwendet. Sehr sinnvoll finde ich das nicht. Für mich wars das hier.

[eumagga0x2a]

Sie pflegen sehr falsche Vorstellungen von der Arbeit an Avidemux.

Zuallererst, alle gemeldeten Fehler werden immer und überall gegen den aktuellen Stand der Entwicklung geprüft, denn wenn der Fehler weiterhin besteht, eine Korrektur immer zuerst dort entwickelt werden muss und findet später eventuell den Weg über Backports zu nachrangigen, speziellen Zweigen wie legacy-compat.

Zweitens, es ist nicht so dass das Testen mit einem anderen Git-Zweig bloß mit den Klicken auf eine .exe getan ist. Avidemux wird unter Linux (und manchmal unter macOS) entwickelt. Um so einen Test durchzuführen, muss ich meine aktuelle Arbeit zu einem vorläufigen Ende führen (es können Tage intensiver Arbeit drin stecken), die Änderungen in Commits aufteilen, den Git-Baum auf einen anderen Zweig umschalten, Avidemux neu kompilieren und damit testen.

Die Entscheidung, keine 32-bits-Versionen vom Git master als offizielle Builds anzubieten, liegt nicht in meiner Kompetenz. Ich kann Ihnen einen privaten Build vom git master erstellen und auf WeTransfer hochladen, das geht, wenn Sie wollen (das geht sogar ohne dass ich meine Arbeit unterbrechen muss, viel leichter als Testen).

[eumagga0x2a]

Bin endlich dazu gekommen, mit legacy-compat zu testen, unter Linux mit dem aktuellen Stand des Zweigs und unter Windows 10 sowohl mit dem letzten offiziellen 32-bits-Nightly als auch mit dem Release. In keiner Konfiguration konnte ich das gemeldete Problem nach dem Befolgen der oben genannten Schritte reproduzieren.