2.7.5 geht bei schwierigem Video noch, darüber hinaus nicht mehr.

[eumagga0x2a]

Was 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.

Hab das TS-File gelöscht

Das ist sehr schade.

[eumagga0x2a]

Ich nutze mpc-hc.

Ah, es gibt also einen Fork.

[Strunz]

Ich nutze 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.

[Strunz]

Das 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. 

[eumagga0x2a]

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.

[Strunz]

Bitte mit dem letzten Nightly probieren.

Wow, danke! Das ging schnell und sieht jetzt gut aus.

[eumagga0x2a]

Code Select Expand

        _
       ( |
     ___\ \
   (____()  `-|
  (______()   |
  (_____()    |
   (___()__.--|

[Strunz]

Code Select Expand

        _
       ( |
     ___\ \
   (____()  `-|
  (______()   |
  (_____()    |
   (___()__.--|

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.

[eumagga0x2a]

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.

[Strunz]

@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.

[eumagga0x2a]

Die Logik ist die geringstmögliche Überraschung des Users.

Auch 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.

man 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.

[Strunz]

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.

[eumagga0x2a]

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.

und 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.

[Strunz]

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!

[Strunz]

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.