Avidemux Forum

Ich habe hier eine Quelle, auf die ich keinen Einfluss habe, die regelmäßige wohl nicht ganz konforme Videos raushaut. Avidemux 2.7.5 kann diese Videos aber noch einlesen und umwandeln (ohne große Bearbeitung). Darüber hinaus, auch in der neusten Beta, ist das aber nicht mehr möglich.
Ein Beispiel, wo direkt (nicht nur) am Anfang ein Ruckler entsteht. Als Encoder wurde x264 gewählt und der Haken bei Frame/Interlacing gesetzt.

Während das Ergebnis mit 2.7.5 anschließend flüssig im MPC-HC abspielt, ist dies mit allen folgenden Versionen nicht mehr möglich.

In früheren Versionen wurden Änderungen der Codec-Parameter mitten im Stream schlicht ignoriert. Das ist grundsätzlich sehr problematisch und nicht wirklich unterstützt. Ich schaue mir das Sample-Video (MPEG-TS mit falscher Dateiendung) später näher an.

Beim Neukodieren würde ich lieber deinterlacen.

Quote from: eumagga0x2a on December 13, 2020, 06:24:35 PMIch schaue mir das Sample-Video

Danke dafür.

Interessant, das Problem hat mit dem kurzen Einschub von frame-kodiertem Video in sonst field-kodiertes Material nichts zu tun. Es liegt an inkorrekten Zeitstempeln im Videostream, wobei die Fehler das Programm auf dem aktuellen Entwicklungsstand verwirren, während sich 2.7.4 in der Tat glücklich über sie hinwegsetzt. Wenn man die Zeitstempel vom ersten Keyframe abgesehen gänzlich invalidiert, kann ein aktueller Nightly zwar nicht mehr im Video navigieren, dafür aber es glatt abspielen.

Frame kodiert? Oh man, das klingt nicht gut, aber ist nicht ausschlaggebend? Wirklich schneiden konnte ich in dem Video eh nicht, an irgendeiner Stelle ist jedes Programm irgendwann ausgeschieden. Glaube die Quelle nutzt regelmäßig die kostenpflichtige Software TS-Doctor.
Ich hatte auch schon Videos, da hat Avidemuxx von sich aus angeboten, die Zeitstempel neu anzulegen, das war aber wieder eine andere Quelle.

Wie oben geschrieben, es spielt keine Rolle, ob field-encoded oder frame-encoded. Die Zeitstempel sind falsch. Mit einem dummen Privat-Patch

diff --git a/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsReadIndex.cpp b/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsReadIndex.cpp
index f9c15875e..8a491f29e 100644
--- a/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsReadIndex.cpp
+++ b/avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsReadIndex.cpp
@@ -172,6 +172,11 @@ bool tsHeader::processVideoIndex(char *buffer)
                     case 'D': frame->type=4;break;
                     default: ADM_assert(0);
                 }
+                if(frame->type==2 || frame->type==3)
+                {
+                    frame->pts=ADM_NO_PTS;
+                    frame->dts=ADM_NO_PTS;
+                }
                 switch(picStruct)
                 {
                         case 'F':
womit PTS und DTS für alle Nicht-Keyframes invalidiert werden, kann das Video problemlos abgespielt* und entsprechend auch neu kodiert werden.

*) edit: Das Navigieren im Video ist weiterhin möglich, da Keyframes ihre Zeitstempel behalten.

Quote from: Strunz on December 14, 2020, 07:20:05 PMIch hatte auch schon Videos, da hat Avidemuxx von sich aus angeboten, die Zeitstempel neu anzulegen

Ja, spätestens wenn Quellen wie OTR auf die geniale Idee kommen, H.264 (mit B-frames!) in AVI zu packen.

Quote from: eumagga0x2a on December 14, 2020, 07:40:35 PMPrivat-Patch

Hab leider von Coden keinerlei Ahnung, aber danke.
Ich werde bei der alten Version bleiben bzw. man kann ja auch mindestens x86 und x64 nebeneinander installiert haben, dann halt in unterschiedlichen Versionen, ganz nach Bedarf.

Danke Dir!

Angesichts der Menge von behobenen Fehlern seit 2.7.4/5 ist es, denke ich, keine Lösung. Ich werde schauen, was sich machen lässt. Der Patch diente nur Eingrenzung des Problems, nicht mehr.

Man kann beliebige Anzahl von Avidemux-Versionen als Portable (avidemux.exe in avidemux_portable.exe umbenannt) nebeneinander installiert haben (allerdings nicht gleichzeitig ausführen), einfach den Installer entpacken oder gleich einen als ZIP verpackten Build benutzen.

Das Problem sollte nun gefixt sein, bitte einen künftigen Nightly ausprobieren.

Vielen Dank für den Bugreport.

Danke, werde ich machen sobald verfügbar.

Vielen Dank nochmal für den Support, wird Zeit für eine neue Final würde ich mal behaupten. Freue mich schon auf avidemux in 2021.

PS: Hab mit der neusten Build (Avidemux_2.7.7 VC++ 64bits 2012299) das Problem, dass ein ts-File kein Audio mehr hat, nachdem es mit Avidemux wieder als TS exportiert wurde, das gilt zumindest für MPC-HC und StaxRip, im VLC dagegen gibt es keine Probleme. Das selbe File als mkv exportiert macht im MC-HC ebenfalls Probleme, in VLC nicht.
Auch schon beim Abspielen von Audiospuren im TS gibt es Probleme.

Keine Ahnung ob aber überhaupt eine Rückmeldung zu Nightlys gewünscht ist bzw. an welcher Stelle.

Quote from: Strunz on December 30, 2020, 12:13:33 PMKeine Ahnung ob aber überhaupt eine Rückmeldung zu Nightlys gewünscht ist bzw. an welcher Stelle.

Sogar sehr erwünscht – auf Deutsch hier oder auf Englisch in "Main version".

Quote from: Strunz on December 30, 2020, 12:13:33 PMHab mit der neusten Build (Avidemux_2.7.7 VC++ 64bits 2012299) das Problem, dass ein ts-File kein Audio mehr hat, nachdem es mit Avidemux wieder als TS exportiert wurde, das gilt zumindest für MPC-HC und StaxRip

Besteht das Problem auf mit dem neuesten Nightly (im Moment ist das ein MinGW-Build aus https://avidemux.org/nightly/win64/ aber das sollte keine Rolle spielen), nachdem die entsprechende Index-Datei gelöscht wurde? Falls ja, bitte ein Stück von der ursprünglichen TS-Datei als Sample zur Verfügung stellen.

Die Erfahrung mit MPC dürfte nur schlechter werden, da das Projekt seit drei-vier Jahren tot ist.

Quote from: eumagga0x2a on January 04, 2021, 01:18:23 PMSogar sehr erwünscht – auf Deutsch hier oder auf Englisch in "Main version"

Cool.
Ich nutze mpc-hc.
Was meinst Du mit index gelöscht? Hab das TS-File gelöscht, glaube aber es betrifft alle TS-Files, wird sich also alsbald was neues finden.