Speichervorgang in avidemux_2.7.9 r210731

[tricho]

Hallo,
ich hatte das neuste nightly-Release installiert und hatte damit aus einer xx.mts eine xx.mpg Datei erstellt.
Dabei fiel mir auf das der Speichervorgang in der neuen Nightly deutlicher länger dauert als bei den vorherigen Versionen.
Die Operation ist nur: MTS-Datei laden, Video & Audio auf Copy-Modus, Ausgabeformat "Mpeg-PS Muxer (ff)", Datei speichern.
In avidemux_2.7.9 "r210702" & "r210714" dauert der Vorgang für eine Ausgangsdatei von 4-5 GB etwa 1 Minute. Beim Release "r210731" dauert es etwa 5 Minuten.

Alle Ausgabedateien (also die xx.mpg) sind exakt gleich groß egal welches Release ich verwende. Aber das Speichern dauert bei der "r210731" eben 5 mal länger.
Alle verwendeten Release waren Win64

Soll das so sein?

Beste Grüße 

[eumagga0x2a]

Bitte Dummy als Muxer auswählen und den 210714 Nightly mit dem 210731 vergleichen (auch nicht taufrisch, aber es gibt keine neueren offiziellen Builds). Dauert die Simulation auch viel länger als das wirkliche Muxen? Die Tests bitte mit einer und derselben MPEG-TS-Datei durchführen.

Bitte auch die Größe der Logdatei (%localappdata%\avidemux\admlog.txt) vergleichen. Wenn aus irgendeinem Grund sehr viele Debug-Meldungen geloggt werden, kann das die Geschwindigkeit sicherlich reduzieren.

Mir fällt im Moment keine Änderung ein, die Geschwindigkeit im Kopiermodus beinträchtigen könnte.

[Fred II]

Kann das von tricho geschilderte Problem mit der avidemux_r210731_win64Qt5_69.zip bestätigen.
Mit der avidemux_r210714_win64Qt5_67.zip läuft das Speichern wesentlich schneller ab.

Gruß, Fred II

[eumagga0x2a]

Kann das von tricho geschilderte Problem mit der avidemux_r210731_win64Qt5_69.zip bestätigen.
Mit der avidemux_r210714_win64Qt5_67.zip läuft das Speichern wesentlich schneller ab.

Es wäre dann hilfreich, die erbeteten Infos zu liefern.

[eumagga0x2a]

Zusätzlich wäre ein Vergleich zwischen der grafischen und der CLI-Anwendung sehr interessant, also den Speichervorgang als Job speichern von Jobs GUI abarbeiten lassen – einmal mit CLI, einmal mit Qt.

[Fred II]

Sorry, kann in den nächsten Tagen leider keine Vergleiche mehr machen.

[eumagga0x2a]

Unter Linux gibt es jedenfalls zwischen dem offiziellen Nightly vom 2021-07-02 und einem Build vom aktulellen git master keinen signifikanten Unterschied beim Speichern einer MPEG-TS-Datei mit MPEG-2 Video in Copy Mode zu MPEG-PS (5,7 Sekunden beim offiziellen Nightly gegenüber 5,9 bei meinem privaten Build für eine 1,2 GiB große TS-Datei). Das auf einem rund 8 Jahre alten Rechner, damals unterer Mittelklasse zuzurechnen, von einer internen HDD zu einer anderen internen HDD.

Beim Versuch mit einer 11 GiB großen TS-Datei mit H.264 Video und drei Tonspuren zu MP4 ohne Optimierung waren beide Builds praktisch gleichauf – 1 Minute 59 Sekunden zu 1:57.

Es wäre schon sehr wertvoll, mehr Input zum Problem unter Windows zu erhalten. Avidemux wird unter Linux entwickelt und dort scheint kein Geschwindigkeitsverlust aufzutreten.

[tricho]

So ich habe heute mal die Nightly-Release 210714 und 210731 hergenommen und dieselbe MTS jeweils mit dem MPEG-PS-Muxer und dem Dummy-Muxer im Copy-Modus abgespeichert.

Dauert in beiden Fällen etwa gleich lang (also Muxer versus Dummy). Aber v210714 speichert schneller als v210731. Allerdings hat das admlog bei v210714 eine Länge von etwa 1.000 Zeilen während bei v210731 etwa 1.450.000 Zeilen auflaufen (95,4 MB)...das ist ein ziemlicher Unterschied.

Wie geht es jetzt weiter? Die admlogs habe ich aufgehoben...

[eumagga0x2a]

Allerdings hat das admlog bei v210714 eine Länge von etwa 1.000 Zeilen während bei v210731 etwa 1.450.000 Zeilen auflaufen (95,4 MB)

Dann gehe ich davon aus, dass das Schreiben des riesigen Logs für den Geschwindigkeitseinbruch verantwortlich ist. Dass der Dummy und der MpegPS Muxer gleich schnell (oder langsam) sind, bedeutet, dass Meldungen wahrscheinlich nicht vom Muxer stammen.

Wie geht es jetzt weiter?

Das beste wäre, ein Stück (300 MiB sollten reichen) der MTS-Datei, ohne Eingriffe in den Datenstrom mit einem Tool wie head oder dd auszuschneiden und als Sample über WeTransfer, Mega, Dropbox oder Google Drive bereitzustellen, denn ich vermute, dass das Problem spezifisch für diese Datei ist.

Die admlogs habe ich aufgehoben...

Ausgezeichnet. Dann bitte das zweite Log nach Wunsch konsistent von identifizierenden Infos wie Pfadangaben oder Benutzername befreien, komprimieren und entweder hier anhängen oder ebenfalls über die oben genannten Anbieter bereitstellen. Leider gibt es im Moment keinen aktuelleren offiziellen Nightly zu testen.

[tricho]

Hallo,

Das beste wäre, ein Stück (300 MiB sollten reichen) der MTS-Datei, ohne Eingriffe in den Datenstrom mit einem Tool wie head oder dd auszuschneiden und als Sample über WeTransfer, Mega, Dropbox oder Google Drive bereitzustellen, denn ich vermute, dass das Problem spezifisch für diese Datei ist.

Also diese Hyphothese teile ich nicht, denn der Effekt ist bei jeder beliebigen MTS-Datei zu beobachten die ich ausprobiert habe. Und Fred II hat ja eine ähnliche Beobachtung gemacht. Die einzige Gemeinsamkeit aller Dateien bei mir ist nur, dass die auf dem selben Sat-Receiver aufgenommen wurden...könnte natürlich auch damit zusammenhängen.

Das mit HEAD und DD ist für mich nicht so einfach, weil ich auf meinem Windows PC nichts vergleichbares habe. Da gibts zwar igendwelche workarounds aber weil ich damit auch ungeübt bin befürchte ich eher Datenschrott zu produzieren. Ich hab stattdessen den simplen Ansatz gewählt und eine kurze Aufnahme mit dem schon oben erwähnten Sat-Receiver produziert (ca. 10 Min). Danach getestet und im ADMlog nachgesehen ob damit der Effekt reproduziert werden kann...Ist der Fall!

Ich schick Dir mit PM einen Drive-Link zu der test.mts und den Admlogs. Sag Bescheid wenn Du die Daten hast, dann kann ich den Link wieder schließen. 

Beste Grüße

[eumagga0x2a]

Bitte den letzten Nightly vom 23. August ausprobieren, er enhält bereits eine Änderung, die Debug-Meldungen von getVideoDuration() abstellt. Sie alleine sind für die irrwitzige Größe des Logs und vermutlich damit auch für die Verlangsamung verantwortlich.

[eumagga0x2a]

Ich schick Dir mit PM einen Drive-Link zu der test.mts und den Admlogs. Sag Bescheid wenn Du die Daten hast, dann kann ich den Link wieder schließen. 

Habe nun auch die Test-Aufnahme heruntergeladen und werde reinschauen, falls sich meine Annahme, dass das Problem durch diese Änderung vom 13. August bereits gelöst wäre, als falsch erweisen sollte. Also, bitte testen und Feedback geben.

[tricho]

Ja, ich hab's mit der Version vom 23.08 probiert und der Speichervorgang ist wieder wesentlich kürzer. Der Blick ins ADMlog zeigt aber dass der Speichervorgang mehr Arbeitsschritte benötig als in vorherigen Versionen. Irgendwas ist verändert worden ... (vermutlich verlängert das die Sache jetzt mit der erneuten Änderung aber nur wenig oder garnicht).
Zu sehen ab:

[HandleAction] 11:07:25-775 ************ SAVE_VIDEO **************
[draw] 11:07:26-086 D3D : Draw! .....

Beste Grüße

[eumagga0x2a]

Es gab beim Speichervorgang keine nennenswerten Änderungen, zumindest keine, die mir einfallen würden (abgesehen von unerheblich verbesserten Debug-Meldungen an paar Stellen). Es wäre hilfreich, das Log anzuhängen, damit ich einordnen kann, worum es geht.

[tricho]

Tja Log würde folgen ... aber wie hänge ich eine kurze Txt-Datei an. Ich find da keine Option im Editor oder hab ich was übersehen. Ich könnte es ja als "Quote" oder "Code" reinhängen aber das ist vielleicht etwas übertrieben...