H265 deutlich schneller als normales MP4

Dank @Will_Tschumy (siehe unten für den Link) gibt es einen ausgezeichneten Beitrag zur Einrichtung eines H265-Constant-Quality-Profils.

Ich habe gerade ein paar Seite-an-Seite-Tests (einzeln) mit denselben Quell-TS-Dateien durchgeführt.

Generell konvertierten die H265-Jobs dreimal schneller als die entsprechenden MP4-Jobs. Zusätzlich sind die H265-Dateien fast 50 % kleiner als die MP4-Äquivalente.

Das zeigt, wie wenig ich weiß. Ich hätte das genaue Gegenteil angenommen. Aber jetzt versuche ich herauszufinden, ob es irgendeinen Grund gibt, sich NICHT auf H265 zu standardisieren. Bisher läuft die Wiedergabe einwandfrei, Untertitel funktionieren, etc. Bisher … keine roten Flaggen …

H265 Constant Quality Profile post

Im Moment scheint dies ein glücklicherweise gefundenes Diskussionsthema zu sein.

BrianGGG

Das ist sehr interessant, verwenden beide eine Hardwarebeschleunigung?

Für mein ungeschultes Auge, ja. Beide verwendeten Hardware-Encoding.
Ich habe die Log-Dateien einer identischen Konvertierung mit den beiden Profilen angehängt, falls du kurz einen Blick darauf werfen kannst.

log.zip (2,2 MB)

Nebenbei: So viele dieser Zeilen in einer DEBUG-Logdatei sind ein echter Speicherfresser und machen sie kaum benutzbar. Lohnt sich dafür ein FEATURE-Request?

2018-02-14T04:52:34 MCEBuddy.AppWrapper.MencoderCropDetect

Ja, sie sind in Bezug auf die Konvertierungsparameter ähnlich; der einzige signifikante Unterschied ist, dass die mp4-Version einen zusätzlichen Filter (hqdn3d) und einige andere x264-Optionen im Profil hatte, die das Video entrauschen, und dass die Endbitrate bei etwa 4 Mbps lag, im Vergleich zu 2,4 Mbps für das hevc.

Für einen perfekten Vergleich von mpeg4 vs hevc ändern Sie in Ihrem H265-Profil hevc_nvenc zu h264_nvenc und lassen Sie den Rest unverändert. Testen Sie es nun, und Sie erhalten einen perfekten Vergleich der Geschwindigkeit von hevc vs mpeg4 mit einem NVIDIA-CUDA-Encoder.

Mit der von Ihnen vorgeschlagenen Änderung waren die Laufzeiten für 264 vs. 265 nahezu identisch.

Falls es einfach ist, können Sie mir kurz erklären, was das MP4-Profakt zurückhält (z. B. warum die zusätzlichen evtl. nicht notwendig sein könnten)?

Klar, es handelt sich um den Satz an Optionen, die für die Kodierung verwendet werden. Das MP4-Profil verwendet eine Reihe von Filtern und andere erweiterte Kodierungsoptionen (ich habe sie unten hervorgehoben)

ffmpeg-video=-ss 3 -vf yadif=0:-1:1,hqdn3d -vcodec libx264 -b 1400k -x264opts me=hex:trellis=1:subq=8:partitions=all:8x8dct=1:ref=3:rc-lookahead=50:keyint=25:min-keyint=20:bframes=1:weightb=1:level=4.0:b-pyramid=normal:direct=auto:mixed-refs=1:deblock=-1,-1:no-fast-pskip=1:no-dct-decimate=1:b-adapt=0:threads=auto -map 0:v -sn

Diese sind darauf ausgelegt, die bestmögliche Qualität bei gleichzeitig angemessen kleiner Datei (bestimmt durch die Bitrate von 1,4 Mbps) zu liefern. Daher ist die Kodierung langsamer, aber Sie sollten ein besseres Bild erhalten als mit einem einfachen konstanten Quantizer. Sie können die Optionen googeln oder auf der ffmpeg-Seite nachlesen (gleiches gilt auch für andere Kodierer wie Handbrake und Mencoder).

Kodierung ist immer ein Kompromiss zwischen Geschwindigkeit, Größe und Qualität, und es gibt viele Möglichkeiten, diese Kompromisse zwischen Bitrate, Filtern und Kodierungsparametern zu steuern. Je größer die Datei (höhere Bitrate), desto besser die Qualität; je schneller die Kodierung, desto geringer (in der Regel) die Qualität – Sie verstehen, was ich meine.

Probieren Sie das, führen Sie das MP4 Normal-Profil mit Hardware-Kodierung aus und dann das MP4 Fast-Profil mit Hardware-Kodierung und sehen Sie den Unterschied. Das Fast-Profil sollte schneller sein, weil es weniger andere Qualitätsfilter und Einstellungen verwendet.

Wenn Ihr Kodierer trotzdem gleich lange für h265 und h264 braucht, bei sonst gleichen Bedingungen, ist das großartig, denn h265 liefert in der Regel ein deutlich besseres Bild bei gleicher Bitrate/Größe. Also ist h265 nach wie vor der klare Gewinner.

Ein weiterer Punkt, der möglicherweise damit zusammenhängt.

Ich habe heute Folgendes festgestellt:
Wenn ich das MP4-Profil verwende, liegt meine GPU während der FFMPEG-Codierung nie über 20 %.
Wenn ich das H265-Profil verwende, steigt meine GPU bei FFMPEG auf 60 % und manchmal 70 %.

Könnte es sein, dass bei H265 etwas mit Threading passiert, das bei MP4 nicht passiert?
Ich habe versucht, das selbst herauszufinden, bin aber gescheitert, deshalb poste ich hier die beiden Profile. Gibt es etwas in den beiden unten stehenden Profilen, das dieses Verhalten erklären könnte?

Danke
BrianGGG

[MKV HVEC Constant Quality]
Description=WARNING: Constant Quality encoding (25) with Nvidia HVEC.
order=ffmpeg, handbrake
AllowH264CopyRemuxing=true
FixedResolution=true
AutoDeinterlace=true
ffmpeg-UsingHardwareEncoding=True
ffmpeg-general=-threads 0 -hwaccel auto
ffmpeg-video=-ss 3 -c:v hevc_nvenc -cq 23 -rc vbr -map 0:v
ffmpeg-audio=-acodec ac3 -ab 192k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 384k -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
handbrake-UsingHardwareEncoding=true
handbrake-general=–decomb --denoise=“weak” --loose-anamorphic --verbose=2 -T -O
handbrake-video=–start-at duration:3 -e x265 -q 18
handbrake-audio=-E ffac3 -R auto -B 192 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E ffac3 -R auto -B 384 -D 0 -a 1,2,3,4,5
handbrake-ext=.mkv
handbrake-audiodelay=skip
PreConversionCommercialRemover=true

[MP4 Normal]
Description=Main profile, good quality 1 pass MP4 (H.264/AAC) conversion. Good for most conversions, produces good results and is faster than the two pass conversion.
order=ffmpeg,mencoder,handbrake
mencoder-general=-ss 3 -vf pullup,softskip,yadif=0:-1,hqdn3d,harddup
mencoder-video=-ovc x264 -x264encopts bitrate=1400:me=hex:trellis=1:subq=8:partitions=all:8x8dct:ref=3:rc_lookahead=50:keyint=25:keyint_min=20:bframes=1:weight_b:level_idc=40:b_pyramid=normal:direct_pred=auto:mixed_refs:deblock=-1,-1:nofast_pskip:nodct_decimate:b_adapt=0:threads=auto
mencoder-audio=-oac faac -faacopts br=160:mpeg=4:tns:object=2
mencoder-audioac3=-oac faac -faacopts br=256:mpeg=4:tns:object=2
mencoder-ext=.avi
mencoder-remuxto=.mp4
mencoder-audiodelay=skip
ffmpeg-general=-threads 0
ffmpeg-video=-ss 3 -vf yadif=0:-1:1,hqdn3d -vcodec libx264 -b 1400k -x264opts me=hex:trellis=1:subq=8:partitions=all:8x8dct=1:ref=3:rc-lookahead=50:keyint=25:min-keyint=20:bframes=1:weightb=1:level=4.0:b-pyramid=normal:direct=auto:mixed-refs=1:deblock=-1,-1:no-fast-pskip=1:no-dct-decimate=1:b-adapt=0:threads=auto -map 0:v -sn
ffmpeg-audio=-acodec libfdk_aac -ab 160k -cutoff 18000 -map 0:a
ffmpeg-audioac3=-acodec libfdk_aac -ab 256k -cutoff 18000 -map 0:a
ffmpeg-ext=.mp4
ffmpeg-audiodelay=skip
handbrake-general=–decomb --loose-anamorphic --verbose=2 -f mp4 -O
handbrake-video=–start-at duration:3 -e x264 -b 1400 -x me=hex:trellis=1:subq=8:partitions=all:8x8dct:ref=3:rc-lookahead=50:keyint=25:keyint-min=20:bframes=1:weight-b:level-idc=40:b-pyramid=normal:direct-pred=auto:mixed-refs:deblock=-1,-1:nofast-pskip:nodct-decimate:b-adapt=0:threads=auto
handbrake-audio=-E faac -R auto -B 160 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E faac -R auto -B 256 -D 0 -a 1,2,3,4,5
handbrake-ext=.mp4
handbrake-audiodelay=skip
PreConversionCommercialRemover=true

Es gibt viele mögliche Gründe, z. B. könnten einige der im MP4-Profil verwendeten Filter zur Rauschunterdrückung und andere erweiterte Parameter von der GPU nicht unterstützt werden und daher auf der CPU laufen. Kodierungsmodi (konstante Bitrate vs. konstanter Quantizer) haben bei unterschiedlichen GPUs unterschiedliche Fähigkeiten, manche sind effizienter.

Vielleicht kannst du für uns einen Test mit verschiedenen Modi in deinem MKV-Profil durchführen (z. B. statt -cq 23 verwende -b:v 1400) und uns mitteilen, wie sich die GPU schlägt.

Wie schlägt sich deine GPU, wenn du dein MKV-Profil ausführst und hevc_nvenc durch h264_nvenc ersetzt? Das wäre ein guter Vergleich der H.264-Kodierfähigkeiten der Karte gegenüber HEVC.

Erster Test ist abgeschlossen. Das Verhalten von H264 ist ähnlich wie bei H265. Es gibt kein Problem, über 20% GPU mit diesem Profil zu erreichen.
Ich werde H265 wie oben für den nächsten Test bald anpassen.

Ich habe gesucht und kann keine endgültige Antwort auf diese Frage finden, also dachte ich, ich stelle sie hier, da wir über H-Hardware-Kodierung sprechen.
Welche GPU sollte ich kaufen, wenn ich das machen möchte?
Ich habe an vielen Stellen gelesen, dass die Hardware-Kodierung (über Nvidia) zu Videos mit schlechter Qualität führt, ist das immer noch der Fall? Viele der Beiträge, die ich gelesen habe, waren ziemlich alt.
Außerdem würde ich gerne, da ich einen Plex-Server betreibe, dass die GPU, die ich wähle, auch Hardware-Transkodierung unterstützt…

Vielen Dank im Voraus für jede Hilfe.

  • Cguy

tagging @Will_Tschumy @NYPLAYER @BrianGGG

Das ist Unsinn – ich habe sowohl AMD- als auch NVidia-Karten verwendet. Der einzige Unterschied, den ich festgestellt habe, ist die Geschwindigkeit – NVidia-Karten sind bei gleicher Qualität schneller (sowohl in Bezug auf die Einstellungen als auch auf die Wahrnehmung). Die 1060 bietet ein großartiges Preis-Leistungs-Verhältnis. Ich denke, Sie machen mit beiden Optionen nichts falsch, aber ich hatte mit NVidia bessere Erfahrungen. Viel Erfolg!

via Newton Mail

Vielen Dank, Will. Das sollte mir eine Menge Kopfschmerzen ersparen.