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.
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 (https://github.com/mean00/avidemux2/commit/8d5d43c97ecafe68d715bcfbc0339477da45bc77) 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" (https://avidemux.org/smif/index.php/board,23.0.html).
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/ (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" (https://avidemux.org/smif/index.php/board,23.0.html)
Cool.
Ich nutze mpc-hc (https://github.com/clsid2/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. ;)
Quote from: Strunz on January 04, 2021, 01:26:08 PMWas meinst Du mit index gelöscht?
Beim ersten Laden jeder MPEG-TS (und auch MPEG-PS) Datei in Avidemux wird ein Verzeichnis aller für uns relevanten Elementary Streams und Frames erstellt und als gleichnamige Datei im selben Ordner mit angehängter Endung .idx2 gespeichert. Existiert bereits die Index-Datei, wird der Stream nicht neu analysiert sondern schlicht das, was in der Index-Datei steht, blind auf die TS-Datei angewandt.
Ein neuer Avidemux-Build wird also die Fehler, die aus der Indexierung durch eine ältere Version stammen, ohne Inkrementierung der Index-Version im neuen Build stillschweigend übernehmen.
Quote from: Strunz on January 04, 2021, 01:26:08 PMHab das TS-File gelöscht
Das ist sehr schade.
Quote from: Strunz on January 04, 2021, 01:26:08 PMIch nutze mpc-hc (https://github.com/clsid2/mpc-hc).
Ah, es gibt also einen Fork.
Quote from: eumagga0x2a on January 04, 2021, 01:50:32 PMQuote from: Strunz on January 04, 2021, 01:26:08 PMIch nutze mpc-hc (https://github.com/clsid2/mpc-hc).
Ah, es gibt also einen Fork.
Jau und der arbeitet auch mit dem Macher von MPC-BE zusammen, z.B. ist der MPC Video Renderer integriert.
Quote from: eumagga0x2a on January 04, 2021, 01:46:48 PMDas ist sehr schade.
Hab gerade mal was kurzes aufgenommen, läuft im MPC-HC ohne Probleme.
Dann mit Avidemux_2.7.7 VC++ 64bits 201229 an zwei Keyframes geschnitten und wieder als .ts gespeichert.
Während VLC es wieder ohne Probleme abspielt, kann MPC-HC es nicht mehr abspielen. Vielleicht kannst Du dir es ja mal anschauen.
Gerade Schneiden von DVB-Material und YouTube-Material ist mein Hauptanwendungsgebiet mit diesem großartigen Programm.
Wenn ich die Datei im Copy-Modus mit einem aktuellen Build speichere, sind MP2-Tracks in Ordnung, was man nicht von der _edit.ts Datei sagen kann. Bitte mit dem letzten Nightly probieren.
Quote from: eumagga0x2a on January 04, 2021, 02:35:13 PMBitte mit dem letzten Nightly probieren.
Wow, danke! Das ging schnell und sieht jetzt gut aus.
_
( |
___\ \
(____() `-|
(______() |
(_____() |
(___()__.--|
Quote from: eumagga0x2a on January 04, 2021, 04:02:12 PM _
( |
___\ \
(____() `-|
(______() |
(_____() |
(___()__.--|
Eine Frage: Dass Avidemuxx beim Schneiden den letzten markierten Keyframe immer noch behält, anstatt ihn wie bei allen vorigen Aktionen zu löschen, hat das irgendeinen Hintergrund? Es ist da nicht wirklich konsistent in der Bedienung.
just curious.
Beim Löschen einer Auswahl im Video muss ihr Endpunkt bleiben. Der einzige Sonderfall ist wenn der Endpunkt entspricht dem letzten Frame.
Beim Speichern einer Auswahl empfinde ich das Weglassen des Frames, an dem man die Endmarkierung gesetzt hat, als hochgradig unnatürlich. Um die Markierung zu setzen, muss ich dieses Bild ansteuern. Ich habe es vor Augen und kann entscheiden, ob ich es auch in der Ausgabe vorfinden möchte. Will ich ein früheres Bild, gehe ich zum früheren Bild. Sonst endet die Ausgabe stets auf einem Bild, das ich nicht gesehen habe = no go.
Wenn es mir wichtig ist, das Keyframe der nächsten GOP nicht mitzunehmen, muss ich halt die Taste mit dem Pfeil nach links drücken.
@eumagga0x2a Wobei ja bei Avidemux markiert wird, was gelöscht wird und ich meine, dieses spezielle Verhalten ist nur beim letzten Cutpoint anders als sonst. Auch ist es natürlich so, dass wenn man bestimmter Szenen rausschneiden will, man tatsächlich kein Bild aus einer neuen Szene (neuer Keyframe) braucht.
Ich muss also immer manuell den letzten Frame zusätzlich rausschneiden. Ich glaub früher ist Avidemux selbst immer einen Frame zurück gesprungen, um halt den letzten Keyframe, einen möglichen Szenenwechsel, nicht mit drin zu haben.
Und was Du sagst müsste ja für jeden Cut gelten, es tut sich aber nur beim letzten so auswirken.
Nun gut, damit kann ich natürlich trotzdem gut leben, auch wenn ich die Logik nicht nachvollziehen kann.
Die Logik ist die geringstmögliche Überraschung des Users.
Quote from: Strunz on January 06, 2021, 11:42:06 AMAuch ist es natürlich so, dass wenn man bestimmter Szenen rausschneiden will
Rausschneiden (die Auswahl löschen) oder speichern? Cut = die Auswahl in die Zwischenablage kopieren + diese Auswahl löschen mit einem einzigen Schritt.
Quote from: Strunz on January 06, 2021, 11:42:06 AMman tatsächlich kein Bild aus einer neuen Szene (neuer Keyframe) braucht. Ich muss also immer manuell den letzten Frame zusätzlich rausschneiden.
Man kann nicht annehmen, dass Keyframe mit einem Szenewechsel übereinstimmt. Daher muss ich immer ein Frame zurückgehen, um zu sehen, ob dies so ist – dann kann ich auch gleich dort die Taste "O" drücken, wenn ich Keyframe nicht will. Der Grundsatz ist, nur mit Frames zu operieren, die ich gesehen habe.
Bei Löschen einer Auswahl am Ende des Videos wird das letzte Frame mitgelöscht, weil es sonst gar nicht möglich ist, es zu löschen (man kann dieses Problem natürlich durch Speichern umgehen, aber je nach Aufgabe kann es unpraktisch sein). Das war eins der Bedienungsmängel im Avidemux, die mich nicht nur zur Weißglut sondern auch dazu getrieben haben, Programmieren zu lernen, um dies in Avidemux zu ändern.
Witzig, irgendwie hab ich den Eindruck, dass wir leicht aneinander vorbei reden. Mein Workflow mit Avidemux ist es in der Regel unbenötigte Szenen rauszuschneiden mittels Markierung und dann Löschen und halt bei der letzten Aktion wird das nicht mehr auf den letzten Frame angewendet, bei allen vorherigen schon! So sind eigentlich auch die Buttons zu verstehen.
Vielleicht ist mein Wokrflow aber auch unnatürlich? Werde mal versuchen nachzuvollziehen, was Du eigentlich sagst. :)
Ich habe sehr selten mit MPEG-TS zu tun, wo ein Stück aus der Mitte entfernt werden muss. Daher ist meine Vorgehensweise meist primitiv – die überflüssigen Tonspuren abwählen, ein als Startpunkt geeignetes Keyframe und einen bestmöglichen Endpunkt finden, das Video im Copy-Modus als MP4 oder MKV zu speichern.
Wenn man ein Stück Video aus der Mitte löschen muss, hat man sich mit der ganzen unerfreulichen Problematik von Open GOP in üblichen digitalen Fernsehübertragungen mit H.264- oder HEVC-komprimierten Video auseinandersetzen, sofern man nicht neu kodiert.
Quote from: Strunz on January 06, 2021, 12:13:02 PMund dann Löschen und halt bei der letzten Aktion wird das nicht mehr auf den letzten Frame angewendet
Ich habe auch den Eindruck, dass wir aneinander vorbei reden. Die einzige Inkonsistenz der aktuellen Implementierung ist, dass beim Löschen und beim Kopieren der Startpunkt einer Auswahl als zur Auswahl gehörend und der Endpunkt als nicht mehr zur Auswahl gehörend interpretiert wird, mit Ausnahme des allerletzten Frames des Videos beim Löschen, welches auch dann als zur Auswahl gehörend angesehen wird, wenn Markierung B darauf gesetzt ist (welchen Sinn ergibt es, dieses Frame stehen zu lassen?).
Beim Speichern gehört dagegen auch der Endpunkt zur Auswahl. Der Grund für diese Abweichung vom Kanon ist, dass der User dieses Frame (normalerweise ist es ein Keyframe) in der Regel gerade sieht, die Frames davor aber nicht. Um zu überprüfen, dass das letzte Bild in der Ausgabe stattdessen das Frame davor sein soll, muss man zu diesem Frame gehen, also immer ein zusätzlicher Schritt.
Nun kommen die Tücken der Open-GOP-Struktur des Streams ins Spiel. Das Frame in der Anzeigereihenfolge direkt vor dem Keyframe befindet sich im Videostream in der Regel
nach dem Keyframe. Das heißt, möchte man die Ausgabe vor dem Keyframe abbrechen, würde das Keyframe dennoch zwingend mitkommen. Die Anzahl von solchen
early B-frames kann ziemlich hoch sein – schon oft 7 und mehr angetroffen (nein, nicht im deutschen ÖR, aber im britischen). Daher würde der tatsächliche Endpunkt der Ausgabe in den seltensten Fällen mit dem Frame übereinstimmen, welches der User eigentlich gemeint hat.
Was Workflow angeht, statt den Vorlauf und Nachlauf zu löschen, lasse ich diese Bereiche bevorzugt durch das Setzen der Start- und Endmarkierung vor dem Speichern aus.
Gut, dann liegt es am unterschiedlichen Workflow und wenn ich dich recht verstanden habe, dann hast Du diese Inkonsistenz willentlich eingefügt, was den letzten Frame betrifft, weil Du halt das Ende im Video markieren willst und nicht etwas danach. Es entspricht zwar so nicht mehr den Buttons, aber da es ja tatsächlich nur das absolute Ende betrifft und nicht jede mögliche Aktion dazwischen, ist es ja kein wirkliches Problem. Gotya!
Ich nutze Avidemux tatsächlich vorwiegend für schneideintensive Anwendungen, hier ist es mit diesem Regler usw. einfach besser als bei allen anderen kostenlosen Programmen, die ich so kenne.
Wenn es mehr um das Umwandeln eines Stückes am Block geht, dann gibt es ja zahlreiche Alternativen, die ich dann eher nutze, z.B. Staxrip, weil diese öfters aktualisiert werden und man sie schon von früher kannte.
Gerade was TV-Aufnahmen in Auszügen betrifft, hat Staxrip z.B. den QTGMC-Deinterlacer an Board, der tolle Ergebnisse liefert.
Aber Schneiden ist mit diesem Programm eine Qual! Mit Handbrake gar unmöglich.
Deswegen wird Avidemux immer ein wichtiger und fester Bestandteil im Portfolio bleiben. Danke für dein Engagement hierbei!
Danke @eumagga0x2a! Die neuste Nightly läuft absolut sauber und wenn ich mich nicht irre, dann springt jetzt Avidemux auch wieder den letzten Frame zurück, wenn gelöscht wird. Keine Frage, mir gefällt's.
Hallo @eumagga0x2a ,
ich mache mal hier weiter, statt einen neuen Thread aufzumachen.
Bin auf folgendes Problem gestoßen, dabei wurde die neuste Nightly vom 15.02.21 für Windows verwendet.
Der Ton war async. Ich habe das bestehende File geladen, dabei gab es eine Warnung, ich solle doch alles neu indexieren lassen oder so ähnlich. Habe ich auch gemacht und anschließend viele Schnitte gesetzt und mit x264 interlaced encodet. Avidemux hat selbst einen Audio-Shift von 80ms eingetragen. Habe, nach dem ich async festgestellt hatte, das Ganze auch noch mal ohne den Shift encodiert, das löste das Problem aber nicht. Denke, der Delay liegt so bei 240ms, getestet mit MPC-HC.
Also im ursprünglichen TS-File gibt es beim Abspielen kein Problem mit dem Sync, nach dem umwandeln dann aber. Vielleicht kannst Du es dir mal ansehen.
Bitte WeTransfer, Mega, Dropbox oder Google Drive benutzen. Zippy ist in meinem Land nicht verfügbar.
Quote from: Strunz on February 18, 2021, 12:56:16 PMAvidemux hat selbst einen Audio-Shift von 80ms eingetragen.
Das ist nur dann möglich, wenn Avidemux feststellt, dass die Zeitstempel im Stream Makulatur sind und versucht, die Reihenfolge der Frames durch komplette Dekodierung des Videos zu rekonstruieren. Diese Verzögerung berücksichtigt nur den zusätzlichen Versatz durch die Präsenz von B-Frames.
Bei mir ist der Ton sowohl in der Original-TS-Datei als auch nach einem Schnitt, exportiert als MP4 mit neukodiertem (im Interlaced-Modus, was ich normalerweise nie tun würde) H.264 stream, perfekt synchron (wie eine zweite Schnittgeneration auch, neu encoded wie auch in copy mode).
Die beigelegten Beispiel-MP4s sind natürlich arg schlecht synchronisiert. Habe im Moment keine Idee, wie das zustande gekommen ist.
Ich habe natürlich unter Linux getestet, die Plattform sollte jedoch keine Rolle spielen.
@eumagga0x2a Habe daraufhin noch etwas weiter getestet und das Problem existiert auch ohne Schneiden und konnte es letztlich auf diese PTS-Rekonstruktion (unter Windows), die mir empfohlen wird, zurückführen. Wenn ich diese nicht mache, gibt es auch das Problem nicht...
Wäre daher toll, wenn Du dir das nochmal ansehen könntest. ;D
Es gibt keine PTS-Probleme (und keine Sync-Probleme) mit dem TS-Sample. Manche Anbieter (OTR?) packten H.264 Ströme in AVI, damit hatten die Nutzer den Salat. Nicht aber hier.
Auf jeden Fall bräuchte ich eine genaue Anleitung, wie ich zu den geschilderten Problemen komme. Soweit ist alles wunderbar synchron und auch fehlerfrei.
Quote from: eumagga0x2a on February 18, 2021, 05:04:58 PMEs gibt keine PTS-Probleme (und keine Sync-Probleme) mit dem TS-Sample.
Das sieht Avidemux unter Windows (https://avidemux.org/nightly/win64/avidemux_2.7.7%20r210215_win64.exe) aber leider anders (https://abload.de/img/capture6sjnb.png).
Dieser Dialog erscheint direkt beim öffnen des "Samples".
Auch wenn die zugehörige *.idx2-Datei gelöscht wurde?
Sprechen wir von derselben Datei, 793886212 Bytes lang, MD5: 0af655be18ada18f793a24d9a9e41664?
Quote from: eumagga0x2a on February 18, 2021, 05:24:03 PMAuch wenn die zugehörige *.idx2-Datei gelöscht wurde?
Ja, es kam schon beim ersten Mal und es kommt
immer mit meiner Version von Avidemux.
Hab hier kein MD5 mehr... (793.886.212 bytes)
SHA1: 6E6B12D86BAE2D6FC69B087D24D50663D968603F
Okay, SHA1 stimmt, muss dann wirklich unter Windows schauen.
Habe nun unter Windows 10 sowohl mit dem offiziellen Build als auch mit meinem eigenen sowohl mit DXVA2 als auch mit Dekodierung rein in Software getestet. Bei mir zeigt Avidemux keine Abfrage wegen ungültiger PTS, alles bestens synchron.
???
Habe Avidemux deinstalliert, alles aus appdata gelöscht, sowohl unter local als auch roaming. Avidemux wieder installiert, Sample extrahiert und random umbenannt und anschließend geladen. Es kommt wieder der selbe Dialog. Hast Du mit der von mir verlinkten Nightly getestet?
SHA1: AFD6116BACAE73CC9ADF168A2CD3042F9B9B7053
Ja, genau mit diesem Build (unter anderem).
Also wenn dir noch was einfällt, was das erklären könnte, nur raus damit. Ich kann es leider nicht, würde es aber gerne gefixt wissen. :)
Bitte die *.idx2-Datei wieder löschen, die TS-Datei laden, dann Avidemux beenden und admlog.txt an die Antwort anhängen.
Okay, hab vorher nochmal alle avidemux-Ordner in appdata gelöscht.
Hier passiert es:
[checkForValidPts] 18:47:29-160 Checking file for broken PTS...
[checkForValidPts] 18:47:29-160 Checking 100 frames out of 19975.
[tsDemux] Wanted frame 1, going back to frame 0, last frame was 13,
[adm_lavLogCallback] 18:47:29-166 [lavc] reference count overflow
[adm_lavLogCallback] 18:47:29-166 [lavc] decode_slice_header error
[adm_lavLogCallback] 18:47:29-166 [lavc] no frame!
[adm_lavLogCallback] 18:47:29-179 [lavc] illegal modification_of_pic_nums_idc 7
[adm_lavLogCallback] 18:47:29-179 [lavc] decode_slice_header error
[adm_lavLogCallback] 18:47:29-179 [lavc] no frame!
[adm_lavLogCallback] 18:47:29-180 [lavc] illegal modification_of_pic_nums_idc 7
[adm_lavLogCallback] 18:47:29-181 [lavc] decode_slice_header error
[adm_lavLogCallback] 18:47:29-181 [lavc] no frame!
[adm_lavLogCallback] 18:47:29-183 [lavc] Reference 3 >= 2
[adm_lavLogCallback] 18:47:29-183 [lavc] error while decoding MB 1 0, bytestream 22463
[adm_lavLogCallback] 18:47:29-184 [lavc] reference count overflow
\00C, 8160 MV errors in B frame
[adm_lavLogCallback] 18:47:29-184 [lavc] reference count overflow
[adm_lavLogCallback] 18:47:29-184 [lavc] decode_slice_header error
[adm_lavLogCallback] 18:47:29-184 [lavc] no frame!
[DecodeNextPicture] 18:47:29-204 >>>>> PTS going backward by 360 ms
[DecodeNextPicture] 18:47:29-205 Dropping frame!
[DecodeNextPicture] 18:47:29-207 >>>>> PTS going backward by 360 ms
[DecodeNextPicture] 18:47:29-207 Dropping frame!
Wie sieht es bei deaktiviertem libavcodec-Multithreading aus?
Vielleicht wäre es interessanter, die maximale Anzahl von Threads schrittweise zu senken, bis das Problem verschwindet. Mein Windows-Laptop hat max. 4 logische Kerne.
Hehe, wenn man es manuell mit dem Regler verstellen will, dann ist 8 das Maximum.
Damit tritt das Problem auch nicht auf.
Was aber, wenn man mehr Cores hat? ;)
Ich habe tatsächlich 12 echte Kerne, ohne SMT. Letzteres habe ich generell deaktiviert, da es beim encoden nix bringt.
Das Problem hat definitiv mit libavcodec-Multithreading zu tun und verschwindet bei mir nur wenn ich die maximale Anzahl von Threads auf 4 senke. Über 4 wird ein Frame nicht richtig dekodiert, aber die Schwelle, um PTS als unzuverlässig zu deklarieren, liegt bei zwei.
Quote from: Strunz on February 18, 2021, 07:06:00 PMWas aber, wenn man mehr Cores hat
Ich habe es versäumt, die maximale Anzahl von Threads selbst mit Automatik auf 8 zu begrenzen. Je nach Codec, beginnt libavcodec bei noch mehr Threads zu spinnen.
Also 8 ist noch ok? Das liest sich ja wirklich kompliziert. Hab ja Null Ahnung wie das alles im Hintergrund läuft, bin echt nur einfacher Nutzer. Aber danke für den "fix", werde es auf 8 belassen.
Betrifft das auch das encoding? Werde es einfach mal schnell testen.
Edit: Taskmanager sagt trotzdem 100%, das zählt für mich. :)
Encoding ist eine andere Geschichte, dort kocht jeder Encoder sein eigenes Süppchen.
Bei diesem Sample sind auf meinem Laptop bereits 5 Threads zu viel. Bitte ins Log schauen, ab welcher Anzahl von Threads die obigen Fehlermeldungen aus admlog.txt verschwinden. Sie dürfen nicht auftreten, überhaupt keine einzige.
Bei mir kommt es ebenfalls ab 5 Threads zu den Fehlern im Log. CPU-Auslastung ist aber auch bei 4 noch zu 100%.
Die LAV-Filters sind das vermutlich nicht? Wenn doch, die werden ja hier (https://github.com/clsid2) auch ständig weiterentwickelt, falls das von Interesse ist. Wenn nicht, war das für die lols. ;)
libavfilter nutzen wir gar nicht.
Quote from: Strunz on February 18, 2021, 07:39:54 PMBei mir kommt es ebenfalls ab 5 Threads zu den Fehlern im Log.
Demnach müsste man die Obergrenze eigentlich bei 4 setzen :-((
Quote from: Strunz on February 18, 2021, 07:39:54 PMCPU-Auslastung ist aber auch bei 4 noch zu 100%.
Hab ich jetzt auch so gemacht.
Quote from: Strunz on February 18, 2021, 07:39:54 PMDie LAV-Filters sind das vermutlich nicht?
Hätte erst den Link anklicken sollen, aber diese Software hat mit Avidemux nichts zu tun und Avidemux nichts mit ihr. Wie ihre Entwickler Multithreading in libavcodec angehen entzieht sich meiner Kenntnis.