Wenn man sich die FFMPEG-Version in MCEBuddy ansieht, steht dort „N-95085-g525de95679“, was wenig über die Daten/Versionen von FFMPEG aussagt. Es ist mit gcc 20190918 erstellt worden, doch ist unklar, ob das das Erstellungsdatum des GCC-Compilers ist, mit dem diese FFMPEG-Version gebaut wurde, oder das Datum, an dem FFMPEG aus dem Git-Quellcode bezogen und kompiliert wurde.
Ich sehe, dass Gyan Doshi wöchentliche Builds veröffentlicht, die NVENC- und NVDEC-Encoder/Decoder enthalten.
Siehe hier: Builds - CODEX FFMPEG @ gyan.dev
Handbrake scheint Version 1.3.3 mit NVENC-Version 12.0 zu sein.
Die aktuelle Version ist 1.5.1. Ich weiß nicht, ob Handbrake den NVDEC-Decoder enthält oder nur den NVENC-Encoder.
Meine Frage ist: Können wir die .exe-Dateien für FFMPEG und HandbrakeCLI durch aktuellere Versionen austauschen?
Wenn nicht, wann können wir erwarten, dass diese kritischen Hilfsprogramme in MCEBuddy auf aktuelle Versionen aktualisiert werden?
Ist es möglich, die GPU-Decoder für Comskip zu nutzen?
Wir testen neuere Versionen der verschiedenen Tools. Wir müssen auf Stabilität und Leistung (und Kompatibilität) testen. Häufig haben neuere Versionen Fehler oder manchmal eine schlechtere Leistung; zum Beispiel haben wir unterschiedliche Builds von Handbrake für Intel-QSV-Konvertierungen und für NVEnc-Konvertierungen. Jeder Testzyklus dauert Wochen bei 24x7-Tests auf vielen Maschinen und 100.000en von Dateien, bevor sie für die allgemeine Verwendung mit MCEBuddy zertifiziert werden.
Aber für den persönlichen Gebrauch kannst du absolut eine direkte Ersetzung vornehmen, es ausprobieren und dein Feedback teilen.
Auch ich warte sehnsüchtig auf ein aktualisiertes FFMPEG.
Ich verwende MCEBuddy nicht mehr zur Neukodierung meiner Aufnahmen, weil es das in ATSC 3.0 verwendete AC-4-Audio nicht verarbeiten kann. Stattdessen lasse ich die Dateien einfach kopieren und umbenennen und lasse Emby sie transkodieren, da Emby über ein aktualisiertes FFMPEG verfügt, das damit umgehen kann. Aber ich würde wirklich gerne wieder MCEBuddy nutzen, da ich damit viel mehr Konfigurations- und Kontrollmöglichkeiten habe.
Ffmpeg-Release-Versionen unterstützen ac-4 noch nicht. Es befindet sich noch in der Entwicklung, aber wenn Sie die Vorab-Entwicklerversionen haben, können Sie diese einfach einfügen und mit MCEBuddy verwenden.
Die Emby-Builds basieren auf einem FFMPEG-5-Baum.
In den Transcode-Protokollen sehe ich:
*01:56:01.333 ffmpeg version 5.1-emby_2022_10_11 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC*
*01:56:01.334 built with gcc 10.3.0 (Rev5, Built by MSYS2 project)*
Ich habe versucht, sie zu ersetzen und durch die MCEBuddy-Builds auszutauschen, aber dann würden die Aufträge nicht ausgeführt. Es ist schon eine Weile her, aber soweit ich mich erinnere, konnte die Befehlszeile, die MCEBuddy an FFMPEG übermittelte, die Aufgabe nicht erfüllen.
Ich habe Handbrake-CLI v1.5.1 eingesetzt und bisher läuft alles gut. Keine Probleme. Win10x64 22H2 (19045.2364), i5-4430, RTX-2060.
Es scheint, als würden die GPU-Lüfter nicht auf Volldrehzahl laufen. Die GPU-Auslastung liegt bei etwa 60–70 %, vielleicht ein kleines bisschen darunter. Die CPU-Auslastung beträgt während der Kodierung etwa 95 %.
Ich habe dieselbe Datei nicht mit beiden Versionen durchlaufen lassen, aber dieselbe Sendung desselben Senders, die zuvor mit MCE Buddy und Handbrake 1.3.1 verarbeitet wurde, scheint ein geringeres Chroma zu haben als die Sendung, die mit 1.5.1 verarbeitet wurde – das fiel mir auf, als ich beide nebeneinander abspielte und die Videos synchronisierte, um die Unterschiede zwischen den beiden Handbrake-Versionen zu sehen.
Ich weiß nicht, ob die Verarbeitungszeit zwischen den Handbrake-Versionen langsamer oder schneller ist. Ich transkodiere nach H.265 und AC3 in einen MKV-Container.
Update zu meinen (begrenzten, 1 Datenpunkt, Intel i5-Haswell, RTX2060) Drop-in-Updates:
Handbrake CLI 1.6.1 – OK, von 1.3.3. CLI-qsv (1.0.7) wurde nicht berührt, obwohl 1.6.1 Unterstützung angibt; wird die qsv-Version also nicht mehr benötigt?
MKVMerge und MKVExtract 74.0.0 – OK, von 17.0.0 (portable Version herunterladen und einzelne Utilities extrahieren)
AVIdemux 2.8.1 – OK, von 2.7.1 (App umstrukturiert, nur das plugins-Verzeichnis beibehalten)
Comskip – 0.80.003. Die aktuelle Donator-Version ist 0.82.012.
Unklar, ob es das externe ffmpeg nutzt oder eine eigene eingebettete Version verwendet.
Hoffentlich greift es auf die von MCEBuddy bereitgestellte Version zurück.
Nur ein Hinweis zur Veröffentlichung von HandBrake 1.7, die soeben auf GitHub erschienen ist. Bemerkenswert ist, dass das eingebettete FFMPEG auf v6.1 aktualisiert wurde und Unterstützung für AV1 – einschließlich NVENC – bietet. Die finale Version soll in den nächsten Tagen offiziell erscheinen, sie ist bereits in den Nightly-Builds enthalten.
Bemerkenswert dabei ist die Einbindung von NVENC SV1 (nVidia-Hardware-Kodierung für SV1).
Dieses Feature ist nun in den Handbrake-Nightly-Builds enthalten, und Handbrake 1.7.0 sollte in Kürze erscheinen.
NVENC-SV1-GPU-Kodierung ist jedoch nur auf den neuen Ada-(RTX-40-Serie)-Karten verfügbar.
Es ist unklar, ob nVidia den Encoder auf die RTX-10-Serie (Pascal), RTX-20-Serie (Turing) oder RTX-30-Serie (Ampere) zurückportieren wird. Ich besitze keine RTX-40-Serie-Karte, daher sehe ich die Option nicht.
Sollte ich eine RTX-40-Serie-Karte erwerben, wäre das für mich der Wendepunkt, um von x265 zu wechseln.
Das offene Audio-Codec-Pendant zu SV1 ist Opus. Leider gibt es bisher nur geringe Unterstützung für diesen Codec in Geräten, und es besteht eine erhebliche Verankerung und Unterstützung für patentbelastete Codecs wie AAC, AC3, E-AC3 und Dolby 5.1.
Daher sieht meine zukünftige Medienkodierung derzeit nach SV1 und AAC aus.