Avidemux crashed plötzlich beim Laden

[axst]

Hallo,

Avidemux V2.5.6 wurde von mir fast täglich benutzt, um bei aufgenommenen Streams die Werbung herauszuschneiden. Seit zwei Tagen crashed es beim Laden jeglicher Video-Datei !!!

Wer kann mir einen Tipp geben, woran es liegen könnte?

Anbei mal das aktuelle Admin.Log...

Gruß, Andreas

[eumagga0x2a]

Ich habe gedacht, 2.5.6 wäre ein Vertipper, aber nein. Alles vor 2.7.6 wird nicht unterstützt, die 2.5er Generation schon seit bald einem Jahrzehnt nicht mehr.

Bitte auf den letzten verfügbaren Nightly Build umsteigen. Wenn damit Probleme auftreten, bitte berichten. Windows 8 ist zwar auch längst aus dem Support gefallen und ich habe keine Möglichkeit, die Lauffähigkeit darauf zu testen, aber die konkrete Installation ist wenigstens 64-bit und sollte somit aktuelle Nightlies ausführen können.

Mit Microsoft Visual Studio (VC++) kompilierte Versionen: https://avidemux.org/nightly/vsWin64/

Mit MinGW kompilierte Versionen: https://avidemux.org/nightly/win64/

Der gegenwärtig letzte VC++ Build wurde am 29.12.2020 erzeugt, ihm fehlt deswegen die erst am 3. Januar 2021 eingepflegte wichtige Korrektur [editor/audio] Enforce blockalign for (L)PCM only, daher bitte zum sowieso frischeren MinGW Build greifen.

[axst]

So, ich habe jetzt auf die nightly Version geupdated (gemäß "never change a running system" war ich mit der 2.5.6 bislang sehr zufrieden, aber man muss ja für neues offen sein ;-) ).
Ich habe jetzt das Problem (welches auch schon im Forum auftaucht), dass ca. die Hälfte meiner zu schneidenden Videos (Stream-Aufnahmen mittels VLC direkt aus der Fritz!Box im TS-Format, teils mit "TS Doctor" vorbehandelt) den Fehler "Video zu kurz - das gespeicherte Video ist unvollständig ... Dies kann eine Folge ungültiger Zeitstempel im Video sein" bekomme; oft in den ersten Minuten, aber auch mal mitten in der Datei.
Meine Einstellung ist: Video Decoder: Lavacodec RGB, Video-Codec Mpeg4 AVC (x264), Audio-Codec MP3 (lame) 192kbps, Ausgabe: MP4 Muxer. So hatte ich es immer in der 2.5.6 gehalten.
Gibt es mittlerweile eine Lösung (oder Ursache) für das Problem?
Gruß, Andreas

[eumagga0x2a]

Bitte von so einer TS-Datei, die den Fehler in den ersten Minuten auslöst, die ersten rund 200 MiB als Sample mittels WeTransfer, Mega, Dropbox oder Google Drive bereitstellen. Wenn ein längeres Stück nötig ist, um das Problem zu reproduzieren, dann länger. Dabei bitte mit einem Tool wie head operieren, das die Daten unverändert belässt (es muss sowas auch für Windows geben).

Code Select Expand

head -c 200M input.ts > sample.ts
Diese Fehlermeldung gibt ein libavcodec-basierter Muxer wie MP4 Muxer aus, wenn DTS (decode timestamp) von zwei aufeinanderfolgenden Paketen, die ihm zum Muxen übergeben werden, gleich sind oder der zweite ist kleiner als der erste.

Meine Einstellung ist: Video Decoder: Lavacodec

Multithreading bitte auf automatisch stellen, wenn schon DXVA2 nicht benutzt wird (je nach dem, bringt Multithreading mehr Geschwindigkeit)

RGB

Bitte "DXVA2" (eigentlich "DirectX") oder wenigstens OpenGL aktivieren und "OpenGL" (angezeigt "QtGl") als Videoanzeige wählen. Bei "Qt" (angezeigt "RGB") mahlt die CPU jeden Pixel auf den Bildschirm, eine unnötige Bremse.

Video-Codec Mpeg4 AVC (x264)

Warum neu kodieren?

Audio-Codec MP3 (lame) 192kbps,

Ebenso, warum? Vor allem, warum MP3 und nicht AAC?

Ausgabe: MP4 Muxer.

Wollte empfehlen, die Zeitbasis auf 90 kHz zu stellen, als ich entdeckte, dass dieses Menü im Konfigurationsdialog flöten gegangen ist 

Der Fix wird im nächsten Nightly Build verfügbar sein.

[axst]

Bitte von so einer TS-Datei, die den Fehler in den ersten Minuten auslöst, die ersten rund 200 MiB als Sample mittels WeTransfer, Mega, Dropbox oder Google Drive bereitstellen.

Ich habe (mangels "head") ein Teilstück mittels "TS Doctor" herauskopiert und damit noch einmal probiert. Interessanterweise läuft es ungeschnitten durch, lösche ich aber die paar Sekunden Werbung vorne heraus (siehe ...py), gibt's die Fehlermeldung.

Alle Dateien (Original, ...py, ...idx und produzierte ...mp4 hier:

https://drive.google.com/file/d/1IS4LKHDSOtAkdciQ2G6YcrfLTI5ni1oa/view?usp=sharing

Multithreading bitte auf automatisch stellen, wenn schon DXVA2 nicht benutzt wird (je nach dem, bringt Multithreading mehr Geschwindigkeit)

Hab ich nun auf DXVA2 umgestellt (irritierend ist, dass dies erst beim Neustart angezeigt wird).

Warum neu kodieren?

Video: Weil ich a) einheitlich auf FHD hochskaliere (die originalen (non-hd) .ts-Streams sind nicht 1:1) und b) dann ca. 1GB pro Stunde erreiche (zumindest bislang mit der 2.5.6).
Audio: ok, hat bislang immer gut funktioniert, benutze ich auch bei meinen MP3 so...

Gruß, Andreas

[eumagga0x2a]

Danke für das Sample, damit wird gleich klar, was da los ist. Die Uhr, nach der die Zeitstempel in der Quelle gesetzt sind, geht falsch – sie geht nach, weswegen Frames zu frühe Zeitmarkierungen bekommen. Nach knapp einer Minute weicht sie bereits erheblich um eine Millisekunde von der deklarierten Bildrate (25 fps) ab. Wenn irgendwann später beim Muxen die Zeitstempel auf die deklarierte Zeitbasis 1000/25000 (oder einfach 1/25) gerundet werden, bekommen dadurch zwei Frames die gleiche Zeit in den Einheiten der Zeitbasis – das Speichern schlägt fehl.

Bei direkten Aufnahmen von DVB-C mit einer DVB-C-Karte bzw. von DVB-S mit einem Receiver ist mir so ein Problem mit Zeitstempeln noch nie vorgekommen. Um den Schuldigen zu finden, wäre es wünschenswert den Stream zu analysieren bevor VLC ihn zu sehen bekommt.

Die Abhilfe ist denkbar einfach – den "Resample FPS" Filter zur Filterkette hinzufügen, damit er die deklarierten 25 FPS durch Weglassen der überzähligen Bilder erzwingt.

Hab ich nun auf DXVA2 umgestellt (irritierend ist, dass dies erst beim Neustart angezeigt wird).

Bei MPEG-2 bringt die Aktivierung von DXVA2 nichts, bitte rückgängig machen und Multithreading wieder einschalten.

"DXVA2" als Anzeige (eigentlich DirectX bzw. D3D, der Name der Videoausgabe in Avidemux stiftet Verwirrung) sollte unter Windows natürlich immer verwendet werden, weil mit Abstand die effizienteste unter den verfügbaren Optionen, ganz zu schweigen von der nicht-beschleunigten "Qt"-Ausgabe, wo die CPU jeden Pixel auf Bildschirm malt.

Nun aber Grundsätzliches zum Vorgehen, soweit das beigefügte Project Script aussagekrägtig ist:

Code Select Expand

adm.setPostProc(3, 3, 0)
Das runiniert das Ergebnis wenn das Video interlaced ist wie hier. Bitte Post-Processing unbedingt deaktivieren.

Code Select Expand

adm.videoCodec("x264", "useAdvancedConfiguration=True", "general.params=AQ=20", "general.threads=99", "general.preset=", "general.tuning=", "general.profile=", "general.fast_decode=False", "general.zero_latency=False", "general.fast_first_pass=True"
, "general.blueray_compatibility=False", "general.fake_interlaced=False", "level=-1", "vui.sar_height=1", "vui.sar_width=1", "MaxRefFrames=3", "MinIdr=25", "MaxIdr=250", "i_scenecut_threshold=40", "intra_refresh=False"
, "MaxBFrame=3", "i_bframe_adaptive=1", "i_bframe_bias=0", "i_bframe_pyramid=2", "b_deblocking_filter=True", "i_deblocking_filter_alphac0=0", "i_deblocking_filter_beta=0", "cabac=True", "interlaced=False"
Wenn die Quelle interlaced ist, sollte unbedingt entweder Interlacing im Encoder aktiviert (nur wenn die Abmessungen des Videos nicht verändert wurden) oder ein Deinterlacer als der allererste Filter in der Filterkette vorgeschaltet werden. Das ist übrigens einer der Gründe, warum Nachbearbeitung (Post-Processing), die vor den üblichen Videofiltern greift, hier so fatal ist.

Code Select Expand

adm.addVideoFilter("swscale", "width=1920", "height=1080", "algo=2", "sourceAR=3", "targetAR=0", "lockAR=True", "roundup=False")
Das Hochskalieren an sich bewirkt zwei Dinge: die Qualität wird schlechter und die Datenmenge beim Neukodieren erhöht sich. Der MP4-Muxer erlaubt es, für anamorphe Videos das korrekte Seitenverhältnis, das ein Player zu wählen hat, vorzugeben. Dies sollte man nutzen, nicht die Quelle aufblähen.

Oder unterstützt das Zielgerät weder das richtige Hochskalieren noch das richtige Interpretieren der MP4-Metadaten? Dann wäre es sinnhaftig, wenigstens "Spline" als Algorithmus zum Skalieren mit swScale zu nehmen.

Also, die Reihenfolge der Filter unter Windows sollte so aussehen:

1. "Resample FPS" zu "PAL (25 fps)"

2. Yadif in der Standardeinstellung als Deinterlacer – aber echt nur hier, weil das Video ein Kinofilm ist, der mit 25 Bildern pro Sekunde gedreht wurde. Bei einer Fernsehshow, die mit 50 FPS aufgenommen wurde, sollte "Bild pro Halbbild" in Yadif-Konfiguration gewählt werden. Die Ausgabe hätte dann auch 50 FPS.

Wenn Ausgabe mit doppelter FPS gewählt wurde, dann sicherheitshalber noch eine "Resample FPS"-Instanz nach Yadif setzen, die Einstellung: "PAL (50 fps)".

3. swscale (halte ich für kontraproduktiv, aber sei es drum) mit "Spline" als Algorithmus.

[axst]

Super, das war der passende Tipp (mit Resample). "general.params=AQ=20" habe ich mittlerweile auf 25 gesetzt, sonst werden die Dateien zu gross. Ansonsten experimentiere ich weiter (in Richtung spline etc.), aber jetzt laufen die Konvertierungen wenigstens wieder durch. Danke !!!