2.7.0 r180319: Videofilter Manager / Aktive Filter II

[3komma14]

und wieder ein Hello in die Runde ...
ein dickes Problem im o.g. Filterfenster. Ab einer bestimmten Anzahl (ab 6 und mehr) von Filtereinträgen bricht die Performance ein und nix geht mehr, will sagen nach minutenlanger Sendepause brech ich ab. Betrifft alle Filmdateien der Ostertage und das war ne Menge ;-)
Betrifft sowohl w32 als auch w64 Systeme.
PiT

[eumagga0x2a]

Mehr Filter kosten grundsätzlich mehr Performance. Bitte die Konfiguration als Projekt speichern und die .py-Datei an die Antwort anhängen.

[3komma14]

danke fürs feedback
.py im Anhang

[eumagga0x2a]

Es sieht so aus, dass die Vorschau im Filtermanager mit steigender Anzahl von abschnittsweise angewendeten (partialized) Filtern Probleme bekommt (bei mir klappt es gerade so mit 5 normalen + 8 partialized Filtern im Stapel, danach versagt die Suche im Video, die Vorschau öffnet sich nicht und Avidemux hängt). Die Vorschau im Hauptfenster hat keine Probleme mit dem aberwitzigen Stapel aus 20 Filtern, somit dürfte auch dem erfolgreichen Kodieren des gefilterten Videos nichts im Wege stehen.

Übrigens, der x264 Encoder ist sehr leistungshungrig und langsam, das Encodieren in Hardware z.B. mit einer Nvidia-Grafikkarte ab Kepler wäre um Vielfaches schneller auf Kosten der höheren Bitrate und damit der Dateigröße.

[3komma14]

gar nicht gut, dass du dieses Laufverhalten bestätigst. Ich lese da zwischen den Zeilen
"des isch halt so" wegen des Encoders. Ich wage einen Einspruch, denn
1. funzt das mit der 2.5, gerade bei partiell angelegten Filtern fehlerfrei, auch bei 10 partiell angelegten Filtern
2. liegt die CPU-Last bei mir grad mal bei 50 % während des Hängers
3. bekomm ich wenigstens auf einer win7/64 Maschine eine Fehlermeldung in der Form
   " ... hat einen Fehler festgestellt und Avidemux wird beendet.
Ist alles nur meine Meinung :-)

PiT

[Jan Gruuthuse]

avidemux 2.5 = frame editor, ab avidemux 2.6. zeitbasierten Editor.

[eumagga0x2a]

50% auf einem Dual-Core bedeuten Vollast für eine Anwendung ohne Multithreading.

Ich werde in den nächsten Tagen nachschauen, ob wir bei der Initialisierung der seekable preview was falsch machen.

[3komma14]

danke schön. Bei der Gelegenheit mal nachgucken warum in der Vorschau des Videofilters keine korrekte Gesamtfilmlänge gezeigt wird, nachdem unerwünschte Teile gelöscht wurden. Stattdessen wird immer die Filmlänge der Originalvorlage eingelesen. Die Vorschau im Hauptfenster machts richtig ;-)

[eumagga0x2a]

Ja, es sieht auf den ersten Blick so aus, dass nachdem die Filterkette aufgebaut ist, nachfolgende Änderungen der Länge nicht mehr abgerufen werden können. Ich werde es checken, danke für den Hinweis.

[eumagga0x2a]

Der Hänger beim Öffnen der Vorschau im Filtermanager mit vielen abschnittsweise angewendeten (partialized) Filtern in der Filterkette sollte durch [partial] Seek with the partialized filter only when in range nicht mehr auftreten.

Mit der nicht aktualisierten Gesamtlänge ist es nicht so einfach. Grundsätzlich rechnet Avidemux nicht damit, dass sich nach dem hinzufügen von zeitabhängigen Filtern die Länge des Videos noch ändern könnte. Dadurch kann ihre Konfiguration ungültig werden – und was dann?

[eumagga0x2a]

Bitte mit r180405 testen, ob der Fix wirklich wirksam ist.

http://avidemux.org/nightly/win64/

[3komma14]

Re: Bitte mit r180405 testen

Gerade installiert und getestet. Sieht deutlich besser aus bei 3x2 partiell angelegten Filtern und einem "geblackten Abschluss-Iframe" :-)
bis hier hin vielen Dank :-)

Jezt vllt noch darüber nachdenken im Vorschaufenster des Filtermanagers die Positionen direkt anzuspringen, die mit partiell angelegten Parametern hinterlegt sind. Jedesmal von vorne sich zur gewünschten Stelle zu bewegen ist verzwickt. Und ein bisserl drüber hinaus ist frameweises zurück blättern gar net möglich.  ;-)
PiT

[eumagga0x2a]

Jezt vllt noch darüber nachdenken im Vorschaufenster des Filtermanagers die Positionen direkt anzuspringen, die mit partiell angelegten Parametern hinterlegt sind.

Im gefilterten Video können wir nur zu Keyframes suchen. Frame-genaue Suche wäre unerträglich langsam.

Jedesmal von vorne sich zur gewünschten Stelle zu bewegen ist verzwickt.

Ich sehe das ein, es lässt sich leider nichts machen. Deswegen empfehle ich dafür das Hauptfenster zu verwenden, zumindest solange keine Filter eingesetzt werden, die Timing verändern.

Und ein bisserl drüber hinaus ist frameweises zurück blättern gar net möglich.  ;-)

Richtig, was anderes gibt die aktuelle Schnittstelle nicht her, und auch aus guten Gründen.