NVENC Transcoding x264/h264

[robbitop]

Hallo zusammen,

ich nutze Plex, um meine Videos in Echtzeit zu transcodieren. Plex nutzt dazu FFMPEG. Der Codec ist out of the box explizit h264, damit alle möglichen Geräte es hardwarebeschleunigt abspielen können.
Dazu nutze ich eine Geforce GTX1070 -> Pascal.

Nun wurde Turings NVENC damit beworben, deutlich bessere BQ/bitrate zu haben. Allerdings scheint das h265/HEVC zu betreffen.

Weiß jemand, ob es auch Verbesserungen hinsichtlich h264 gab? Ich finde dazu im Netz überhaupt nichts. (was vermuten läßt, dass es dort keine wesentlichen Verbesserungen gab)

[Rumbah]

Ich kann dir leider auch nicht direkt weiterhelfen, da ich auch nur eine Pascal GPU habe und nur damit Vergleichsencodes machen könnte. Aber laut dieser News soll auch der H264 Encoder besser geworden sein:

https://www.heise.de/newsticker/meldung/OBS-Studio-23-Schoener-Streamen-auch-ohne-Highend-Hardware-4325056.html

Hast du denn die Comand Line, die Plex mit ffmpeg zum Umwandeln nutzt?

[Gebrechlichkeit]

Habe eine 1660 non TI. Pascal und Turingn waren gleichschnell, hatte zuvor ne 1060 mini. Beide 300fps+ FHD. (game)Treiber 436.xx der neueste 440? will nicht so richtig und evtl. ist der Studio Treiber gar besser?

Source, 4K@1.1Gb
https://www.youtube.com/watch?v=lNIEZ61PyG0

A´s VideoConverter main10 geht leider seit 2018 nicht
NVenc h265, 24:24:24, ref 5, quali. mode, fps=70, size= 2,775MB
NVenc h265, 35:40:30, ref 5, quali. mode, fps=70, size= 379MB "ueberraschend ok-gut" (https://we.tl/t-AKoWxc1FK4)
NVenc h264, 35:40:30, ref 5, quali. mode, fps=110, size= 407MB "nope" (https://we.tl/t-ecmX4m2m3p)

Handbrake 1.2.2
NVenc h265, CRF30@default, decomb filter, auto, auto, variable framerate, fps=18?, size=0,99GB
ohne decomb filter, deinterlace = 45fps ... irgendwas stimmt da nicht.

dmMediaConverter 2.4
NVenc h265, preset hq, main10, rest auto, CQ33, fps=42+, size= 636MB
CQ37, size= 352MB "hmm gleichgut oder besser als simple x265 custom param Lauf" (https://we.tl/t-kxv4IKan9C)

Simple x264/265 Launcher 64bit
NVenc h265, custom param (https://we.tl/t-G3DCOUgxbP), fps=40, size= 273MB "naja, aus 3m entfernung solide"
NVenc h265, CQ/CRF37, default, kein custom param, audio copy, fps=120, size= 334MB "nope" (https://we.tl/t-sasGbQenKY)

2Pass gibt´s net, bei den heutigen Festplatten. VAAF? PSNR Vergleiche ueberlasse ich dir :biggrin: Nutze das png. tool aus StaxRip 2.4 (unter advanced), um die clips zu vergleichen.


1º simple launcher custom param, knapp vor (100MB leichter!)
2º dmMediaConverter 2.4 preset hq, main10

https://i.ibb.co/Ct9L6QG/801-Machu-Picchu-Peru-in-4-K-Ultra-HD-2.png (https://ibb.co/Ct9L6QG) https://i.ibb.co/F8jLZM7/801-Machu-Picchu-Peru-in-4-K-Ultra-HD-1.png (https://ibb.co/F8jLZM7) https://i.ibb.co/yhs1ggG/801-Machu-Picchu-Peru-in-4-K-Ultra-HD-3.png (https://ibb.co/yhs1ggG) https://i.ibb.co/xDLzdnm/801-Machu-Picchu-Peru-in-4-K-Ultra-HD.png (https://ibb.co/xDLzdnm) https://i.ibb.co/WzMR7vc/801-Machu-Pichu-dm-Media.png (https://ibb.co/WzMR7vc) https://i.ibb.co/8XcFxm4/801-Simple-x264265-Launcher-64bit.png (https://ibb.co/8XcFxm4)

https://s3.gifyu.com/images/3644-Machu-Picchu-Peru-in-4K-Ultra-HD-2.th.png (https://gifyu.com/image/kGt3) https://s3.gifyu.com/images/3644-Machu-Picchu-Peru-in-4K-Ultra-HD1.th.png (https://gifyu.com/image/kGtw) https://s3.gifyu.com/images/3644-Machu-Picchu-Peru-in-4K-Ultra-HD3.th.png (https://gifyu.com/image/kGtx) https://s3.gifyu.com/images/3644-Machu-Picchu-Peru-in-4K-Ultra-HD.th.png (https://gifyu.com/image/kGtK) https://s3.gifyu.com/images/3644-Machu-Pichu-dmMedia.th.png (https://gifyu.com/image/kGtH) https://s3.gifyu.com/images/3644-Simple-x264265-Launcher-64bit.th.png (https://gifyu.com/image/kGtN)

[Rumbah]

Aber haben die abgespeckten Turings nicht auch nur den "Videoteil" der Pascals?

Ich dachte, dass nur wirklich die 2XXX Serie auch den neuen Videoencoder hat und er bei den 16XX zusammen mit dem Raytracingkram/ML Kram eingespart wurde?

[robbitop]

TU117 hat den NVENC von Volta (gtx 1650)
TU116 hat den NVENC von Turing (gtx 1660)

Gebrechlichkeit: mir geht es ausschließlich um h264 für nvenc. Pascal vs Turing. Ob Turing da besser geworden ist. Wenn ich deinen Post richtig verstehe, wird das dort nicht verglichen, oder?

[Rumbah]

TU117 hat den NVENC von Volta (gtx 1650)
TU116 hat den NVENC von Turing (gtx 1660)
Ah, das wusste ich nicht.

Also laut Wikipedia:
Sixth generation, Turing TU10x/TU116

Sixth generation NVENC implements HEVC 8K encoding at 30FPS, HEVC B-Frames support and provides up to 25% bitrate savings for HEVC and up to 15% bitrate savings for H.264. The Nvidia GeForce GTX 1650 is exempt from this generation however, as it uses Volta NVENC instead of Turing.

Aber da stehen keine Quellen oder so dabei. Habe auch nichts gefunden, wo das wirklich mal vernünftig vermessen wurde (also mit objektiven Metriken, nach richtigen Sehtests wage ich gar nicht zu fragen ;) ). Scheint sich wohl niemand der normalen "3D Reviewern" dafür zu interessieren.

Könnte man ja mal mit Tears of Steel und deiner Plex Kommandozeile in Angriff nehmen.

[Rooter]

Könnte man ja mal mit Tears of Steel und deiner Plex Kommandozeile in Angriff nehmen.Tu das, Ergebnisse würden mich interessieren. :) Vor allem ob der mittlerweile eine Chance hat gegen x264.

MfG
Rooter

[Rumbah]

Da ich kein Plex benutze habe ich keine Ahnung, wie die Plex ffmpeg Zeile für x264 bzw. nvenc aussieht. War ja für das Szenario gefragt.

Da müsste dann robbitop oder ein anderer Plexnutzer einmal forschen.

[robbitop]

Wäre schön wenn Plex auch mal HEVC anbieten würde (nachdem es automatisch erkennt ob der jeweilge Client es in HW decodieren kann). Weil in HEVC/h265 soll Turing enorme Sprünge gemacht haben. Grob x264 medium Niveau.
Mit h264 ist man hw encodiert davon mWn noch Meilen entfernt.

[robbitop]

Bezüglich des Tests: kA wie das mit ffmepg geht.
Wäre es nicht einfacher das mit Handbrake zu testen?

Seit Version 1.2 ist NVENC implementiert. Man müsste also mittels NVENC nur 1x h264 encodieren mit Pascal und mit Turing. Gleiche feste/konstante Bitrate. Je geringer desto mehr trennt sich die Spreu vom Weizen.

Hier steht wie es geht: https://www.winxdvd.com/resource/handbrake-nvenc-hardware-accelerated-encoding.htm

[Rumbah]

Naja, ich würde ffmpeg direkt benutzen, ist für mich einfacher :)

Aber es ging mir eher darum, welche Optionen Plex mit NVENC benutzt, wenn es für dich transcodiert. Ich kann natürlich auch einfach so testen, aber das muss dann gar nichts mit deinem Anwendungsfall zu tun haben. NVEnc bietet nämlich auch viele Stellschrauben:

Allein 11 presets:
-preset <int> E..V.... Set the encoding preset (from 0 to 11) (default medium)
default E..V....
slow E..V.... hq 2 passes
medium E..V.... hq 1 pass
fast E..V.... hp 1 pass
hp E..V....
hq E..V....
bd E..V....
ll E..V.... low latency
llhq E..V.... low latency hq
llhp E..V.... low latency hp
lossless E..V....
losslesshp E..V....
Und das profile müsste man auch wissen:
-profile <int> E..V.... Set the encoding profile (from 0 to 3) (default main)
baseline E..V....
main E..V....
high E..V....
Und auch bei vbr oder cbr hat man Auswahl:
-rc <int> E..V.... Override the preset rate-control (from -1 to INT_MAX) (default -1)
constqp E..V.... Constant QP mode
vbr E..V.... Variable bitrate mode
cbr E..V.... Constant bitrate mode
vbr_minqp E..V.... Variable bitrate mode with MinQP (deprecated)
ll_2pass_quality E..V.... Multi-pass optimized for image quality (deprecated)
ll_2pass_size E..V.... Multi-pass optimized for constant frame size (deprecated)
vbr_2pass E..V.... Multi-pass variable bitrate mode (deprecated)
cbr_ld_hq E..V.... Constant bitrate low delay high quality mode
cbr_hq E..V.... Constant bitrate high quality mode
vbr_hq E..V.... Variable bitrate high quality mode

Dachte, man findet vielleicht in den Logs von Plex dann eine Kommandozeile, wo man das ablesen kann, damit man in der Optionsflut einen Anhaltspunkt hat.

[Gebrechlichkeit]

Gebrechlichkeit: mir geht es ausschließlich um h264 für nvenc. Pascal vs Turing. Ob Turing da besser geworden ist. Wenn ich deinen Post richtig verstehe, wird das dort nicht verglichen, oder?

Deswegen ja auch die encodes, zwar h265 aber kann jederzeit was in h264 mit benchen. Vergleiche ziehen musste du dann schon selber, k.A wie man die 1:1 vergleicht (via psnr, vaamf? von netflix usw.)

Verlinke auf eine legale source, wir beschraenken uns auf einen encoder und danach kann man pascal h264 vs turing h264 vergleichen. Natuerlich werden die gleichen Einstellungen genommen.

Software zur Auswahl

A´s video converter, handbrake 1.2.2, simplelauncher, ffmpeg (samt deine cli-param) bzw. in form von dmMediaConverter (https://forum.doom9.org/showthread.php?p=1887500#post1887500)(nutzt ffmpeg + gui, glaube sogar portable)

https://s5.gifyu.com/images/444.th.png (https://gifyu.com/image/kJeW) https://s5.gifyu.com/images/Annotation-2019-11-03-180323.th.png (https://gifyu.com/image/kJeg)

€dit: zus. sollten man noch darauf achten, wie genau die GPU genutzt wird. Je nach Einstellung schwankt CUDA von 10% bis 100% Auslastung und GPU/VE 55% - 100% hin/her. Standardeinstellungen nutzen mehr die VE aus (stehts at 100%) und je hochwertiger die Settings, umso mehr wird CUDA?Chip? genutzt (taskmanager copy auf cuda wechseln). Kein Schimmer ob das wichtig ist oder nicht.
https://s5.gifyu.com/images/adasdc.th.png (https://gifyu.com/image/kP2R)

[Rumbah]

Ich kann gerne als Quelle Tears of Steel (von https://media.xiph.org/tearsofsteel/) aus den dortigen 800p pngs in YV12, 8-bit lossless h264 komprimiert anbieten. Steht unter CC Lizenz und darf frei verteilt werden.

Da es allerdings ca. 10GB sind, würde ich den Link, falls dann gewünscht, per PN verschicken, damit nicht zu viel Traffic durch "random clicks" verursacht wird ;) .

[Gebrechlichkeit]

https://github.com/stoyanovgeorge/ffmpeg/wiki/How-to-Compare-Video
How to Compare Video in FFMPEG

StaxRip (unter Tools>Advanced>Video Comparison> Taste "S">.png). Je groesser die input datei, umso laenger dauert das laden. Zu wenig systemspeicher fuehrt zum crash der applikation, also wat kleines, handliches und keine 40gb klopper.

10Gb sind kein Problem, dauert aber trotzdem ne minute oder 50. :wink:

Jellyfish test video 2K/4K
http://www.jell.yfish.us

[Rumbah]

Die fertigen Videos kann man auch mit Vapoursynth (Skriptsprache zur Videofilterung und -bearbeitung) direkt vergleichen, also ohne pngs, die man zwischendurch speichern muss.

Kann ich dann gerne machen, wären dann VMAF, MS-SSIM, SSIM, PSNR als Metirken glaube ich.

[Gebrechlichkeit]

Ich habe gestern noch selbst die psnr, ssim werte ueberpruefen lassen. Kapieren tue ich nueschts! PNG vergleichen ist einfacher :biggrin: Besteht denn noch Interesse (@OP)?

https://s5.gifyu.com/images/biatch-1.th.png (https://gifyu.com/image/kXnI) https://s5.gifyu.com/images/biatch-2.th.png (https://gifyu.com/image/kXn7) https://s5.gifyu.com/images/biatch-3.th.png (https://gifyu.com/image/kXnq)
4fps+
ffmpeg -i input_video.mp4 -i reference_video.mp4 -filter_complex "psnr" "output_video.mp4"
30fps
ffmpeg -i main.mpg -i ref.mkv -lavfi "[0:v]settb=1/AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=1/AVTB,setpts=PTS-STARTPTS[ref];[main][ref]psnr" -f null -
10fps+
ffmpeg -i distorted.mp4 -i reference.mp4 -lavfi "ssim=ssim.log;[0:v][1:v]psnr=psnr.log" -f null –

[robbitop]

Absolut. Klar besteht Interesse. Bin aktuell auf Dienstreise und kann somit wenig beitragen.

[Gebrechlichkeit]

Source :
tears of steel
110Mbps, x264 r29843579fcb
12min 14s, 9.41GiB
1920x800, 24fps, High 4:4:4 Predictive@L5 (Cabac 16 Ref Frames)

a - simple launch x265 294 (cpu 70%, gpu 90%)
--audio-codec aac --aq-strength 15 --aq --aq-temporal --lookahead 32 --bframes 5 --ref 16 --mv-precision q-pel --vpp-unsharp radius=8 --vpp-unsharp weight=10.0 --vpp-unsharp threshold=200 --cqp 20:20:20 --weightp --nonrefp --strict-gop --slices 64 --cabac --cuda-schedule spin
encode 1min 39s
final size 1.11Gb

b - A´s Video Converter (cpu 100%, gpu 50%)
I:20 P:20 B:20, Best Quality, GOP auto, Ref Frames 5, Cabac enable, Profile Main (10bit broken)
encode 6min 47s
final size 0.99Gb

c - A´s Video Converter (cpu 100%, gpu 50%)
I:29 P:29 B:29, Best Quality, GOP auto, Ref Frames 5, Cabac enable, Profile Main (10bit broken)
encode 6min 50s
final size 282MB

d - Handbrake 1.2.2 (cpu 100%, gpu 10%)
RF20, FPS as source, variable framerate, default preset, auto profile, auto level
encode 10min 23s
final size 830MB

e - dmMedia Converter 2.4 H265 (cpu 100%, gpu 25%)
CQ20, preset hq, profile main10, audio copy
encode 6min 49s
final size 782MB

f - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H265 10bit
--avhw --cqp 20:20:20 --codec h265 --preset quality --profile main10 --tier high --output-depth 10 --vpp-edgelevel strength=10,threshold=15,black=5,white=2 --cu-max 32 --weightp --bframes 4 --ref 16 --gop-len 600 --lookahead 32 --strict-gop --qp-max 22 --qp-min 17 --aq --colormatrix bt709 --colorprim bt709 --transfer bt709 --mv-precision q-pel --cabac
encode 1min 38s
final size 1.26GB

g - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit
-c:v hevc_nvenc, quality -1
encode 7min 44s
final size 170MB

h - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit
-c:v hevc_nvenc, quality -1, very slow
encode 8h 47min
final size 126MB

i - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H264 10bit
--cqp 20:20:20 --preset quality --output-depth 10 --vpp-unsharp radius=6,weight=2,threshold=20 --adapt-transform --weightp --direct temporal --bframes 5 --ref 16 --gop-len 600 --lookahead 32 --slices 32 --aq-strength 5 --aq --aq-temporal --output-buf 64 --mv-precision q-pel --cabac
encode 8min 09s
final size 1.52GB

Frameshot (png) comparison using Stax Rip Beta 204
Frames taken : 2222, 5180, 5555, 7500, 8000, 11111

https://www.imgonline.com.ua/eng/similarity-percent.php
Image comparison

Similarity of pictures
Results Frame 2222 ORIGINAL vs

a - simple launch x265 294 (cpu 70%, gpu 90%) 99.45%
b - A´s Video Converter (cpu 100%, gpu 50%) 99.74%
c - A´s Video Converter (cpu 100%, gpu 50%) 99.7%
d - Handbrake 1.2.2 (cpu 100%, gpu 10%) 99.88%
e - dmMedia Converter 2.4 H265 (cpu 100%, gpu 25%) 99.83%
f - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H265 10bit 98.6%
g - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 98.22%
h - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 98.21%
i - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H264 10bit 98.67%



Similarity of pictures
Results Frame 5180 ORIGINAL vs
a - simple launch x265 294 (cpu 70%, gpu 90%) 97.09%
b - A´s Video Converter (cpu 100%, gpu 50%) 97.16%
c - A´s Video Converter (cpu 100%, gpu 50%) 97.05%
d - Handbrake 1.2.2 (cpu 100%, gpu 10%) 99.64%
e - dmMedia Converter 2.4 H265 (cpu 100%, gpu 25%) 99.63%
f - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H265 10bit 96.81%
g - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 98.96%
h - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 99.02%
i - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H264 10bit 98.57%




Similarity of pictures
Results Frame 5555 ORIGINAL vs
a - simple launch x265 294 (cpu 70%, gpu 90%) 98.27%
b - A´s Video Converter (cpu 100%, gpu 50%) 97.16%
c - A´s Video Converter (cpu 100%, gpu 50%) 97.05%
d - Handbrake 1.2.2 (cpu 100%, gpu 10%) 99.63%
e - dmMedia Converter 2.4 H265 (cpu 100%, gpu 25%) 99.17%
f - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H265 10bit 96.81%
g - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 97.24%
h - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 97.25%
i - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H264 10bit 98.57%





Similarity of pictures
Results Frame 7500 ORIGINAL vs
a - simple launch x265 294 (cpu 70%, gpu 90%) 98.27%
b - A´s Video Converter (cpu 100%, gpu 50%) 97.16%
c - A´s Video Converter (cpu 100%, gpu 50%) 97.05%
d - Handbrake 1.2.2 (cpu 100%, gpu 10%) 99.82%
e - dmMedia Converter 2.4 H265 (cpu 100%, gpu 25%) 99.59%
f - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H265 10bit 98.58%
g - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 98.48%
h - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 99.59%
i - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H264 10bit 98.57%




Similarity of pictures
Results Frame 8000 ORIGINAL vs
a - simple launch x265 294 (cpu 70%, gpu 90%) 98.27%
b - A´s Video Converter (cpu 100%, gpu 50%) 97.16%
c - A´s Video Converter (cpu 100%, gpu 50%) 97.05%
d - Handbrake 1.2.2 (cpu 100%, gpu 10%) 99.79%
e - dmMedia Converter 2.4 H265 (cpu 100%, gpu 25%) 99.45%
f - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H265 10bit 98.58%
g - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 98.52%
h - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 98.46%
i - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H264 10bit 98.57%




Similarity of pictures
Results Frame 11111 ORIGINAL vs
a - simple launch x265 294 (cpu 70%, gpu 90%) 98.27%
b - A´s Video Converter (cpu 100%, gpu 50%) 97.16%
c - A´s Video Converter (cpu 100%, gpu 50%) 97.05%
d - Handbrake 1.2.2 (cpu 100%, gpu 10%) 99.69%
e - dmMedia Converter 2.4 H265 (cpu 100%, gpu 25%) 99.24%
f - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H265 10bit 98.58%
g - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 97.55%
h - Stax Rip Beta 2.04 (cpu 100%, gpu 25%)- ffmpeg (hevc_nvenc) H265 8bit 97.68%
i - Stax Rip Beta 2.04 (cpu 65%, gpu 100%) - Nvidia H264 10bit 98.57%



FRAME 2222
in depth detail analysis using magnifier (eyebrow)
B and C are blurry, while A is sharper than both
D and E are closer to ORIGINAL, A and F have less detailed eyebrow BUT
A and F have more contrast, more shadow around the eye
H adds more clarity, even though the original has none around the eye aka more highlighted
I with added unsharp filter = why does this shit even exist? 100% garbage

FRAME 5180
in depth detail analysis using magnifier (whole picture, wall bricks)
A and F useless, full of artifacts
D, G not as clear as E and Original
E delivers best image, while H slighlty over details the bricks
on Frame 2222 not visible, due static image ... sadly clips encoded via gpu are useless
shimmer, flicker, artifacts all over the place, excluded from future benchmarking

FRAME 7500
in depth detail analysis using magnifier (purple text, neck)
SURPISE MODDARFUKA!! G is better looking the H!!
H overdetails, sharpens the image, neck is blurrier than G!
D is blurrier than E and Original

FRAME 8000
in depth detail analysis using magnifier (roofs)
E best image, close to Original
D and G onpar, while H due low file size blurry mess

FRAME 11111
in depth detail analysis using magnifier (tiles, left side, shadow)
D beats E, by not much
G is useless
and H for just 126MB astonishing, yet .... no matter how much you let it encode Higher BITRATE >>>> Encoder Preset (very slow)


FAZIT

Wenn nicht anders vermerkt, wurden alle mit gleicher RF/CQP von 20 encodiert. Und dmMediaConverter hat sich als beste Software GUI fuer ffmpeg den ersten Platz geschnappt. StaxRip, Av´s Convrete und simple 264 launcher konnten mit der Source nicht umgehen (4:4:4?, 100mbit? k.A)

Wer mit der GPU encodiert :

nimmt dmMediaConverter, schneller als Handbrake.

Wer mit der CPU encodiert, kann alles nehmen wobei ich nach meinen Tests auf mein Geld auf ffmpeg setzen wuerde. FFMPG Nvidia h265 (stax rip) lieferte stets bessere Werte ab als NVenc von Nvidia, evtl. schlecht implementiert.

Jede Source vor diesem Test wurden perfekt von der gpu bearbeitet, keine Artefakte. H264 lohnt sich via GPU nicht, und mMn limitert auf 2K Content. 4K sollte man mit h265 encodieren.

FAZIT zum FAZIT

FFMPEG >>>> Handbrake >>>> forget about it

[yamo]

Deswegen ja auch die encodes, zwar h265 aber kann jederzeit was in h264 mit benchen. Vergleiche ziehen musste du dann schon selber, k.A wie man die 1:1 vergleicht (via psnr, vaamf? von netflix usw.)

Verlinke auf eine legale source, wir beschraenken uns auf einen encoder und danach kann man pascal h264 vs turing h264 vergleichen. Natuerlich werden die gleichen Einstellungen genommen.

Software zur Auswahl

A´s video converter, handbrake 1.2.2, simplelauncher, ffmpeg (samt deine cli-param) bzw. in form von dmMediaConverter (https://forum.doom9.org/showthread.php?p=1887500#post1887500)(nutzt ffmpeg + gui, glaube sogar portable)

https://s5.gifyu.com/images/444.th.png (https://gifyu.com/image/kJeW) https://s5.gifyu.com/images/Annotation-2019-11-03-180323.th.png (https://gifyu.com/image/kJeg)

€dit: zus. sollten man noch darauf achten, wie genau die GPU genutzt wird. Je nach Einstellung schwankt CUDA von 10% bis 100% Auslastung und GPU/VE 55% - 100% hin/her. Standardeinstellungen nutzen mehr die VE aus (stehts at 100%) und je hochwertiger die Settings, umso mehr wird CUDA?Chip? genutzt (taskmanager copy auf cuda wechseln). Kein Schimmer ob das wichtig ist oder nicht.
https://s5.gifyu.com/images/adasdc.th.png (https://gifyu.com/image/kP2R)


Herzlichen Dank für die Tipps!!!!
dmMediaconverter ist im Zusammenspiel mit NVenc sehr genial:
Qualität ist gut ~iQSV
rasend schnell + 2pass und autocrop für alte 4:3 Filme
Dateigröße ähnlich gut wie iQSV

Handbrake & Co produzieren bei NVenc nur miese Dateileichen der doppelten Größe, bei schlechterer Qualität.

Danke!

[Gebrechlichkeit]

https://s5.gifyu.com/images/ivj7he1yes4c.gif (https://gifyu.com/image/7gNP)

[yamo]

dmMediaconverter beschwert sich immer über missing libs, läuft aber meistens ;)
Ist das normal?

[Gebrechlichkeit]

Ich hatte auch paar Probleme mit der neuesten 2.4.1. Nutze immernoch 2.4 und bin zufrieden damit. Kann mich auch nicht mehr erinnern woran die neueste Version gescheitert hat. Finde keine alten Fassungen von der Software, hab mal meine kopie hochgeladen, und die wird schnell gesichert.

2.4
d12ebcbea786d683350c139b646fda73 *dmMediaConverter.exe.test.ver.2.4.exe
https://we.tl/t-BNkmjEuUdo

[yamo]

Danke ;)