Binärdateien aktualisieren

Goose RBoy,

Dieser Thread ist fast 1 Jahr alt. Die Stabilität muss sich inzwischen verbessert haben. Können wir ein neues Build von ffmpeg bekommen? Viele andere Projekte sagen, dass es stabil genug für sie ist. Warum nicht mcebuddy?

Ich habe mein Abonnement gerade erneuert. Ich helfe gerne finanziell und beim Testen, arbeite an neuen Funktionen mit.

Hallo Goose, RBoy

Wir haben einige Patches an ffmpeg übermittelt. Wird der Testzyklus für die nächste Version von ffmpeg neu gestartet?

Klingt gut. Während du wartest, dass deine Patches genehmigt werden, warum wendest du sie nicht selbst an und erstellst dein eigenes Fork von ffmpeg, indem du es crosskompilierst?

Ich möchte hinzufügen, dass ich meine Lizenz ebenfalls gerade erneuert habe.
Frische Nightly Builds für MKV-Merge und -Extract eingespielt,
Handbrake CLI, FFMPEG (der Build 2.8.2 von 20230930 wird von den Autoren als stabil bezeichnet und enthält neue Unterstützung für NVdecoder und NV-AV1-Encoding) sowie avidemux.

Meine ersten Tests deuten nicht darauf hin, dass comskip mit NVdec spürbar schneller ist als mein alter i5-4430 Haswell-CPU.

Nach der Installation des neuen MCEBuddy 2.6.2 vom 14. Oktober und dem Update der oben genannten Tools habe ich jedoch bemerkt, dass MCEBuddy buchstäblich /durch/ einen Stapel anstehender Konvertierungen gerast ist.

Ich muss also noch etwas tiefer graben, um herauszufinden, was den gewaltigen Schub ausgelöst hat, aber mein erster Eindruck ist, dass entweder MCEBuddy den Turbo aktiviert hat oder eines der aktualisierten Tools dafür verantwortlich ist. Ich nutze comskip und handbrake, und handbrake bringt seine eigene interne statisch gelinkte FFMPEG mit, sodass mein MCBuddy-Update dafür keine Rolle spielt.

Was auch immer ihr macht – macht weiter so.

Danke, Goose und RBoy, für dieses großartige und unverzichtbare Automatisierungstool.

Habe gerade das hier bemerkt (Making sure you're not a bot!)

6.1 sollte sehr bald erscheinen, wir warten nur noch darauf, dass sie die Homepage aktualisieren.

Ich lebe gefährlich und nutze diese (ungefähr wöchentlichen) Builds von Builds - CODEX FFMPEG @ gyan.dev

6.1-Builds sind jetzt hier verfügbar Builds - CODEX FFMPEG @ gyan.dev. Bitte halten Sie uns auf dem Laufenden. Danke.

außerdem wurde handbrakecli gerade auf 1.7.0 hochgestuft, aber wir warten immer noch auf ein Binary.

Die nächtlichen Handbrake-Builds sind nun die 1.7.0-Builds. Bemerkenswert ist, dass wir nun NVENC AV1 (nVidia-Hardware-Kodierung für AV1) haben.

Dies ist jedoch nur auf den neuen Ada-(RTX40-Serie)-Karten verfügbar.

Es ist unbekannt, ob nVidia den Encoder auf die RTX10-Serie (Pascal), RTX20-Serie (Turing) oder RTX30-Serie (Ampere) zurückportieren wird.

Ich benutze Handbrake nicht oft, hauptsächlich ffmpeg, aber meinst du nicht svt oder av1?

Gans, Rboy, wie ist die 6.1?

Ja, ich meinte AV1. Habe es korrigiert. Der Encoder, den ich nutzen kann, ist SVT und CPU-basiert. Keine GPU für mich auf einer 2060. Bleibe also vorerst bei h.265.

Wir haben mit der Arbeit an den neuen Versionen begonnen. Dies ist eine große Änderung, da die neuen Binärdateien ältere Grafikkarten nicht mehr unterstützen, sodass wir in diesem Release viel mehr Arbeit investieren müssen, um die Unterstützung für ältere GPUs aufrechtzuerhalten, während wir auch Unterstützung für neue GPUs und Codecs hinzufügen. Alle anderen mit neueren GPUs (AMD, Nvidia, Intel), die AV1 unterstützen, können mir gerne eine private Nachricht senden, wenn sie Teil des Testprozesses sein möchten.

Uff! Wusste nicht, dass FFMPEG die Unterstützung für ältere Karten einstellt. Oder mencoder oder handbrake, falls die ebenfalls die Unterstützung für ältere Karten einstellen.

Ich frage mich, wie viele MCEBuddy-Nutzer diese älteren Karten haben, wenn man bedenkt, dass neuere Low-End-Karten in etwa dasselbe kosten wie MCEBuddy.

Und es ist ja nicht so, dass die Besitzer dieser älteren Karten aufhören müssen, die älteren Versionen von MCEBuddy zu verwenden, die diese Karten unterstützen, oder dass diese aus den Archiven entfernt wurden.

Für mich ist das kein zwingendes Argument dafür, dass die zukünftige Entwicklung von MCEBuddy behindert oder verzögert werden muss, um GPUs (oder CPUs) zu unterstützen, die nicht mehr hergestellt oder von den Herstellern selbst unterstützt werden – und das nur auf Basis der Vermutung, dass sie noch von Leuten verwendet werden, die sich zwar eine neue Lizenz leisten können, aber keine neuere Low-End-Grafikkarte, die vermutlich um Größenordnungen leistungsfähiger ist als die veraltete Karte und dasselbe kostet.

Braucht heute noch jemand Unterstützung für Diskettenlaufwerke?

Ich bin einfach neugierig, wie groß die Gruppe der MCEBuddy-Nutzer ist, die diese Karten oder CPUs besitzen, für die die Unterstützung eingestellt wird, und nicht einfach auf Software-Codecs umsteigen können – oder ob es bestimmte Karten oder CPUs gibt, die nicht upgegradet werden können, keine Software-Codecs nutzen können und trotzdem ihre Version von MCEBuddy upgraden müssen?

Mike808, Sie verwenden eine ältere Grafikkarte. Warum nicht in dieser Weihnachtszeit ein Upgrade durchführen? Newegg bietet einige gute Angebote für die Arc A380, und die RTX 4060 ist auch nicht schlecht.

Crosslinking:

@Goose Ich dachte, AMD hat noch kein AV1 Encoding, nur Decoding. Haben sie das in ihren Treibern nachgerüstet?

RBoy Goose, danke für all die Arbeit daran, habe dir gerade eine Spende geschickt.

Treiber/APIs unterstützen es, aber die Hardware muss verfügbar sein (RDNA3-Architektur wie die Navi-3x- und Radeon-RX-7000-Serie-GPUs), damit mcebuddy sie nutzen kann.

Siehe dazu: GPU/Hardware Encoding/Acceleration FAQs