Meine neue Grafikkarte kann 4 gleichzeitige Kodierungsvorgänge ausführen. Ich habe das vorhin mit FFmpeg Batch AV Converter überprüft. Ich führe dasselbe gerade mit MCEBuddy aus und meine CPU-Auslastung beträgt 100 %, wobei ffmpeg als Encoder verwendet wird; die MCEBuddy-Oberfläche reagiert nicht mehr und mein Rechner ist träge. Ich möchte weiterhin MCEBuddy nutzen, kann es aber nicht, wenn mein Rechner dabei gelähmt ist. Ich musste die Oberfläche schließen, um überhaupt etwas mit meinem Rechner machen zu können. Danach öffnete ich die Oberfläche erneut, und sie zeigte den Fortschritt aller vier Konvertierungen für etwa 5 Sekunden an, bevor sie wieder blockierte und nicht mehr reagierte. Das Programm ist so nicht nutzbar. Mache ich etwas falsch, und wie behebe ich das?
Das Profil für MKV HEVC ist nicht mit der Hardware-Kodierung kompatibel. Wie übergibt MCEBuddy die Parameter an ffmpeg? Oder verwendet es einfach die Standardeinstellung in ffmpeg? Gibt es eine Möglichkeit, die Parameter für die Hardware-Kodierung zu ändern?
Ich bin wieder auf 2 gleichzeitige Konvertierungen zurückgegangen, das hält sich unter 90%, während andere Dinge parallel laufen, sodass mein Computer wenigstens noch benutzbar ist. Ich liebe MCEBuddy, aber ich möchte wissen, wie ich die CPU-Auslastung bei 4 gleichzeitigen Konvertierungen senken kann, um trotzdem einen Geschwindigkeitsvorteil zu haben. Ich habe ein benutzerdefiniertes Profil im anderen Programm verwendet und konnte 4 in etwa einer Stunde ohne Probleme und mit einer CPU-Auslastung von etwa 65% erledigen.
Wenn Hardware-Beschleunigung im Konvertierungsauftrag aktiviert ist, wird Hardware verwendet, falls verfügbar. Wenn du eines der Logs anhängst, bei denen so viel CPU verbraucht wird, können wir möglicherweise erkennen, was vor sich geht, und entsprechende Vorschläge machen.
Standardmäßig versucht dieses Profil, zuerst Handbrake zu nutzen; je nach GPU kann dies jedoch fehlschlagen, da das „medium“-Preset nicht verfügbar ist.
Außerdem wird die Audiospur neu kodiert, was etwas CPU beansprucht, da sie nicht von der GPU übernommen wird – allerdings sollte das nur ein sehr geringer Anteil sein. Ich bevorzuge es, die Audiospur zu kopieren.
Hier ist das MKV-HEVC-Profil.
Description=HEVC in MKV (H.265/AC3) conversion. Creates a smaller file (50% smaller than H.264) with comparable quality but very slow.
order=handbrake,ffmpeg
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec libx265 -preset medium -crf 26 -map 0:v -sn
ffmpeg-audio=-acodec ac3 -ab 160k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 256k -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
handbrake-general=--decomb --loose-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e x265 --encoder-preset medium -q 26
handbrake-audio=-E ffac3 -R auto -B 160 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E ffac3 -R auto -B 256 -D 0 -a 1,2,3,4,5
handbrake-ext=.mkv
handbrake-audiodelay=skip
PreConversionCommercialRemover=true
Ich wollte etwas mehr aus dem Profil herausholen und den Encoder fest auf die von mir verwendete GPU setzen. Ändere einfach die Reihenfolge mit order=, falls du ffmpeg bevorzugst. Hier ein paar Beispiele:
Intel:
[HEVC MKV Intel]
Description=HEVC in MKV hardset to use Intel.
order=handbrake,ffmpeg
DisableEncoderReordering=true
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec hevc_qsv -preset slow -crf 26 -vsync 2 -map 0:v -sn
ffmpeg-audio=-acodec ac3 -map 0:a
ffmpeg-audioac3=-acodec copy -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
ffmpeg-UsingHardwareEncoding=true
ffmpeg-DisableSoftwareEncoderFallback=true
handbrake-general=--decomb --auto-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e qsv_h265 --encoder-preset quality -q 26
handbrake-audio=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-audioac3=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-ext=.mkv
handbrake-audiodelay=skip
NVidia
[HEVC MKV AnyStream NVidia]
Description=HEVC in MKV hardset to use NVidia.
order=handbrake,ffmpeg
DisableEncoderReordering=true
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vf yadif=0:-1:1,hqdn3d -vcodec hevc_nvenc -preset hq -crf 26 -vsync 2 -map 0:v -sn
ffmpeg-audio=-acodec ac3 -map 0:a
ffmpeg-audioac3=-acodec copy -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
ffmpeg-UsingHardwareEncoding=true
ffmpeg-DisableSoftwareEncoderFallback=true
handbrake-general=--decomb --auto-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e nvenc_h265 --encoder-preset hq -q 26
handbrake-audio=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-audioac3=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-ext=.mkv
handbrake-audiodelay=skip
handbrake-UsingHardwareEncoding=true
handbrake-DisableSoftwareEncoderFallback=true
AllowAllCopyRemuxing=true
Neben der Verwendung von Hardware-Encodern und der Optimierung von Profilen können Sie sich auch dieses Thema für Details ansehen, wie die von der Video-Codierung genutzten Ressourcen begrenzt werden können:
SystemIdleProcess…ist [HEVC MKV AnyStream NVidia] ein Profil, das ich meiner profiles-Datei hinzufügen muss, um es auszuprobieren? Falls ja, würde ich es einfach unter dem aktuellen HEVC-Profil hinzufügen, das Software-Encoding verwendet?
Ich habe die Schwachstelle im aktuellen hardware-beschleunigten Profil in MCEBuddy beim Anschauen eines Films gestern Nacht entdeckt. Das Problem tritt bei schwachen Lichtverhältnissen auf, wenn der größte Teil des Bildes in Schwarz-, Weiß- und Grau-Tönen gehalten ist, weil es sehr dunkel ist. Es entsteht ein Halo- oder Bänding-Effekt, wie Ringe oder Farbverläufe, die aussehen wie eine Zielscheibe, wobei entweder die Bildmitte der Mittelpunkt ist oder sich um eine Person im Dunkeln bewegt. Sobald echte Farben in die Szene kommen, verschwindet dieser Effekt oder wird so stark minimiert, dass er nicht mehr wahrnehmbar ist. Bei guten Lichtverhältnissen ist das Bild nahezu perfekt. Ich habe immer wieder zwischen diesem H.265-Encode und demselben Film in H.264 gewechselt, und bei letzterem ist der Effekt nicht sichtbar.
Ich werde diesen Film nutzen, um mit Kodierparametern zu experimentieren, da ich möchte, dass der Effekt verschwindet, aber die Dateigrößen möglichst klein bleiben. Hast du Vorschläge, mit welchen Parametern ich spielen sollte, um das zu korrigieren? Ich dachte, ich würde den Film einfach 5- oder 6-mal mit leicht erhöhter Qualität kodieren, bis der Effekt verschwindet, und das dann als mein neues Profil verwenden – zumindest für Horrorfilme, da normale Lichtverhältnisse bei den aktuellen Einstellungen bereits großartig aussehen. Das ist das erste Mal, dass ich diese Anomalie feststelle.
EDIT…Ok, ich habe das Profil hinzugefügt, es in MCEBuddy ausgewählt und lasse gerade nur diesen Film als Basislinie laufen.
Danke
Ich weiß genau, wovon du bei den dunklen/schwarzen Szenen redest. Ich hatte bisher noch nicht viel Zeit, um daran zu experimentieren, aber du bist auf dem richtigen Weg, die Qualität zu erhöhen (technisch gesehen den Qualitätswert zu verringern, 26 im Profil), bis das Problem verschwindet. Ansonsten habe ich wirklich keine Vorschläge für Parameter-Anpassungen. Eventuell musst du für solche Filme/Serien auch Software verwenden. Und vielleicht sogar ein main10-Profil nutzen, um einen ordentlichen HDR10-Rip zu bekommen. Oder H264 könnte der richtige Weg sein. Ich habe ehrlich gesagt keine Antwort darauf.
Danke für die Hilfe; wenn wir beide experimentieren, finden wir vielleicht eine Antwort. Wenn ich eine Lösung entdecke, werde ich möglicherweise einfach ein Profil für Horrorfilme erstellen, denn gerade diese enthalten viele dunkle Szenen, besonders mit Bewegung. Ich habe es nur bemerkt, weil ich gestern „The Amityville Murders“ geschaut habe – die zweite Hälfte ist fast durchgehend dunkel. In normalen Filmen ist mir der Effekt auch schon aufgefallen: sehr dunkle Szenen mit viel Schwarz und Bewegung, aber da sie nur eine Sekunde oder kürzer dauern, lohnt sich keine größere Datei für etwas, das die meisten nicht wahrnehmen … ich sehe alles.
Meine H.264-Codierung des Films ist nur in dunklen Szenen besser, aber sie ist auch per Software erfolgt; vielleicht teste ich einfach eine hardware-beschleunigte H.264-Version und schaue, ob das Problem bleibt. So oder so werde ich eine Lösung finden – oder eben akzeptieren, dass ich mit dem Effekt leben kann, wenn die Datei sonst zu groß wird. Ich schaue seit Wochen jeden Abend Horrorfilme und erst jetzt ist mir dieses Problem aufgefallen.
Ich habe es in Bright bemerkt und mir geht es genauso, meine Frau hat es nicht gestört oder bemerkt, aber ich fand es furchtbar.\nEin Trick, um Zeit zu sparen, ist die Verwendung der MCEBuddy Custom Cuts-Anwendung, um die anderen Teile des Films zu entfernen, sodass du nur die Szene(n) erhältst, mit denen du testen möchtest. Oder verwende andere Software, um den Rest herauszuschneiden, sodass du nur die Szene(n) als Quelldatei hast, mit denen du testen möchtest.
Das ist eine gute Idee, ich kann einfach einen 5-Minuten-Ausschnitt herausschneiden, bei dem ich es am meisten bemerkt habe, und ich erinnere mich an diese Zeit, damit ich alle Encodes in unter einer Stunde erledigen kann.
Ich habe den Film einmal mit deinem Profiv wie es ist durchlaufen lassen, einmal mit CRF 23 und einmal mit CRF 20, und es gab keinen Unterschied zwischen den drei resultierenden Dateien. Alle hatten dieselbe Größe und dieselbe Qualität, mit dem vorher bestehenden Problem.
Hmm… das ist seltsam. Bist du sicher, dass es ffmpeg verwendet hat? Kannst du eine Protokolldatei für eine der Dateien, die du konvertiert hast, anhängen?
[Hochladen: The Amityville Murders STZEH.ts-Convert to MP4-2020-11-04T14-25-49.log…]
Das ist das Protokoll für die letzte Konvertierung, bei der ich das CRF auf 20 gesetzt habe
Ich kann es aus irgendeinem Grund nicht hochladen, es sagt immer, dass die Zeitdifferenz zwischen der Anfragezeit und der aktuellen Zeit zu groß ist.
…Aber laut dem Protokoll verwendet es ffmpeg… warum aber verwendet es comskip? Ich habe dieses Programm nie ausgeführt, wie schalte ich es ab?
Es ruft möglicherweise comskip auf, macht aber nichts damit. Mach dir keine Sorgen darüber. Siehst du „MCEBuddy.AppWrapper.Handbrake“ irgendwo gegen Ende des Logs?
Nein, es gibt nichts Derartiges mit Handbrake gegen Ende; es wird zwar am Anfang Handbrake verwendet, um Dinge zu prüfen, aber danach geht es zu MCEBuddy.Transcode.ConvertWithFfmpeg
Hier sind einige weitere Optionen für die nvenc_hevc-Encoder-Presets.
-preset <int> E..V..... Setze das Encoding-Preset (von 0 bis 11) (Standard: medium) default 0 E..V..... slow 1 E..V..... hq 2 Durchläufe medium 2 E..V..... hq 1 Durchlauf fast 3 E..V..... hp 1 Durchlauf hp 4 E..V..... hq 5 E..V..... bd 6 E..V..... ll 7 E..V..... niedrige Latenz llhq 8 E..V..... niedrige Latenz hq llhp 9 E..V..... niedrige Latenz hp lossless 10 E..V..... verlustfrei losslesshp 11 E..V..... verlustfrei hp
Slow führt 2 hq-Durchläufe durch, was bessere Ergebnisse liefern könnte. Aber ehrlich gesagt könnten wir auf dem Holzweg sein. Vielleicht einfach mal im Internet nach ffmpeg und nvenc_hevc suchen.
Ehrlich gesagt habe ich in letzter Zeit hauptsächlich Intel-Hardware-Encoding verwendet, weil das auf meinem sekundären Rechner ist, auf dem ich die meisten meiner Aufnahmen/Encodings mache.
Ich habe den Grund gefunden, warum das Ändern des CRF-Werts keinen Einfluss auf das resultierende Video hatte … CRF gilt nur für Software-Encoding, man muss einen CQ-Wert mit NVENC verwenden.
Außerdem haben all diese Profile, die du gepostet hast, noch einen weiteren Fehler … sie verwenden Software-Encoding für alles vor dem NVENC-Parameter, zum Beispiel für die Deinterlacing. Man kann YADIF in NVENC verwenden, und ich habe es in FFmpeg Batch getestet – wenn man die Deinterlacing-GPU machen lässt, sind die Encodierzeiten halb so lang wie bei MCEBuddy … Ich habe nur noch nicht herausgefunden, wie ich alle Parameter erfolgreich an NVENC in MCEBuddy übergeben kann, so wie die Profile strukturiert sind. Ich bekomme ständig Fehler.