Posts: 77
Threads: 8
Joined: May 2022
Quote:Die max. VBV Werte müssen dann durch die Level, Profile&Co Auswahl beschränkt werden.
Ist also etwas umständlicher.
Zu klären wäre auch:- Das letzte Mal als ich die Dokumentation gelesen hatte stand da auch öfters mal, dass sie nicht sicher VBV konform sind, was VBV etwas unsinnig macht. Ist dies immer noch der Fall?
- Wenn Profile, Level (Tier) gesetzt sind, schränkt der Encoder die VBV Werte korrekt ein?
Quote: Wrote:Hybrid verwendet aber immer "auto" bzw. definiert den Wert nicht, wodurch laut report file auto gesetzt wird
Wie sind die vbv Werte bei 'auto' eingeschränkt? (sollten sie nicht auf die Profile/Level/Tier Maxima gestellt sein?)
Bzgl. der 4 Sekunden Empfehlung: Macht es nicht mehr Sinn da den maximal erlaubten Wert zu nehmen?
- Wie reagiert der Encoder, wenn man nicht legale Werte verwendet?
Bis jetzt habe ich da auch nichts gescheites gefunden. Ist es nicht so, dass der Hardware-Decoder in der Karte streiken sollte, wenn da nicht zum profile/level/tier passende vbv Werte eingestellt werden, also NVEncC nicht entsprechend eingeschränkt hat? Dann könnte man das ja mal experimentell aktivieren und schauen, ob das Ergebnis von der Hardware oder CPU decoded wird. Kann man ja in GPU-Z sehen, ob die Video Engine Load >0% zeigt oder nicht, also die CPU decoded.
Es besteht halt das Risiko, dass NVEncC per default VBV für Low Latency Verwendungszwecke einstellt, was dann wohl average frame size statt 4*Bitrate ist und die Qualität von I-Frames einschränken kann.
Hab ich allerdings nur in dieser ziemlich veralteten Dokumentation von 2014 unter Punkt 7.1.1 was dazu gelesen:
https://developer.download.nvidia.com/co...gGuide.pdf
Kann natürlich auch gut sein, dass das z.B. bei Verwendung von b-frames seitens NVEncC ausgeschlossen ist und höhere Werte verwendet werden... 
Seltsamerweise fehlt in der Doku von 2016 das komplette Kapitel Low Latency encoding:
https://developer.download.nvidia.com/designworks/video-codec-sdk/secure/7.1/01/NVENC_VideoEncoder_API_ProgGuide.pdf?tmqul5FwgC3nTRZtoGKKD1_3biKcCVJQdZW21904kMvPCz5jrMQL6q9SHREIu4ymmZxpEIVaEhFxZk3Hw4YfTlfEEmNI2R0W3jv6qQjZa3Ub6DgcRd2AKtljKyrnNxpuYAPVYhGcxpQlbESvpVZRrwcltNuRi4J_tSKmbbt80MU4XZX4rv2vRiKuxZ5Z&t=eyJscyI6IndlYnNpdGUiLCJsc2QiOiJkZXZlbG9wZXIubnZpZGlhLmNvbS9yZXN0cmljdGVkP2ZpbGVuYW1lPTQwMy5odG1sIn0=
Und eine neuere hab ich nicht gefunden...
Posts: 10.933
Threads: 56
Joined: May 2017
Quote:Ist es nicht so, dass der Hardware-Decoder in der Karte streiken sollte, wenn da nicht zum profile/level/tier passende vbv Werte eingestellt werden, also NVEncC nicht entsprechend eingeschränkt hat?
Die meisten Decoder, die mir so in den Sinn kommen unterstützen, alles bis zu einem bestimmten Profile/Level/Tier, aber wenn sie z.B. High@Level 6.2 unterstützen laufen sie, auch wenn das Material Main@Level1 geflagged ist, aber High@Level 6.2 VBV Werte verwendet. 
Problem ist halt, mit der aktuellen Dokumentation sehe ich nicht ein da was zu Implementieren und mich dann mit Userbeschwerden rumzuschlagen.
Cu Selur
Posts: 77
Threads: 8
Joined: May 2022
(31.12.2022, 11:47)Selur Wrote: Quote:Ist es nicht so, dass der Hardware-Decoder in der Karte streiken sollte, wenn da nicht zum profile/level/tier passende vbv Werte eingestellt werden, also NVEncC nicht entsprechend eingeschränkt hat?
Die meisten Decoder, die mir so in den Sinn kommen unterstützen, alles bis zu einem bestimmten Profile/Level/Tier, aber wenn sie z.B. High@Level 6.2 unterstützen laufen sie, auch wenn das Material Main@Level1 geflagged ist, aber High@Level 6.2 VBV Werte verwendet.
Problem ist halt, mit der aktuellen Dokumentation sehe ich nicht ein da was zu Implementieren und mich dann mit Userbeschwerden rumzuschlagen.
Cu Selur
Wenn das nunmal hier in einem aktuellen Dokument von NVidia ausdrücklich so empfohlen wird, kannst die Schuld auf Rigaya abschieben, wenn da irgendwas nicht Profil konform eingeschränkt wird 
Muss ja nicht per default aktiv sein, wer das bewusst von "Auto" auf benutzerdefiniert umstellt steht selbst in der Verantwortung.
Aber vielleicht finden sich ja doch noch irgendwo brauchbare Hinweise. Wäre halt traurig, wenn das Auto Handling von NVEncC für Qualitätsdefizite verantwortlich ist. Das hauptsächliche Marketingargument für NVEnc ist imho nach wie vor Streaming, und dann könnte es natürlich auch sein, das solche settings per default darauf getrimmt sind...
Bei x265 gibt's ein "custom command line addition" Feld. Wäre natürlich auch eine Möglichkeit um mit derartigen Optionen erstmal etwas rumzuspielen und Erfahrungen zu sammeln ob/was etwas bringt und was eher ein Problem verursacht. Der allgemeine Erfahrungsschatz scheint mir ja eher dünn zu sein, was NVEnc angeht. In dem Fall kann dann auch hinterher keiner rummeckern, dass irgendwas nicht passt an dem, was er da encoded hat.
h265 10 bit mit b-frames scheint sich jedenfalls zu lohnen, da spart man über den Daumen gepeilt 30% Bitrate im Vergleich zu h264 8 bit ein, bei (laut VMAF/SSIM/PSNR) vergleichbarer Qualität. Damit fährt man auf den ersten Blick mindestens so gut, wenn nicht besser, wie mit x264 10 bit preset medium, was ja traurigerweise leider eh kein Decoder unterstützt.
Und der Encoding Speed liegt natürlich um Welten auseinander.
Unbrauchbar ist NVEncC jedenfalls nicht, wenn man 10 bit encoded. Ist halt nur die Frage, ob da nicht sowohl bei h264 als auch bei h265 noch Luft nach oben ist durch Anpassung vbv-buf und auch anderer mir möglicherweise noch nicht bekannten settings.
Posts: 77
Threads: 8
Joined: May 2022
Hab gestern noch ein bißchen mit vbv-bufsize bei einer 1080p und einer 4k Quelle rumgespielt.
Wenn man wie ich bei h265 10 bit mit --vbr 0 --vbr-quality 25-26 encoded hat das keinen Wert. Wenn ich da beispielsweise vbv-bufsize 40000 setze, dann verzehnfacht sich die Bitrate fast (Bitraten des constant quality encodes mit vbv-bufsize auto waren bei 4 bzw. 17 Mbit).
Hab vbv-bufsize dann immer weiter abgesenkt, unter 1000 war die Bitrate dann nur noch etwa doppelt so hoch, unter 100 immer noch knapp doppelt so hoch, und das sank dann bis vbv-bufsize 1 auch nicht mehr signifikant ab.
Kann natürlich sein, dass das eher bei einer vorgegebenen Bitrate nützlich sein kann.
Mir ist aufgefallen, dass man am Ende der ersten Seite des x264 / NVEnc h264 Vergleichs bei igorslab, den ich vor ein paar Monaten gepostet hab, sieht, dass ebenfalls vbv-bufsize und vbv-maxrate auf 6000 getuned wurde, allerdings auch bei einer festen Bitrate von 6000.
Bei beiden Codecs?!? Allerdings find ich vbv-maxrate bei NVEncC gar nicht als Option...
Posts: 10.933
Threads: 56
Joined: May 2017
Keine Ahnung was igorslab da macht (das sie cbr für ne brauchbare Idee halten), aber ja bei cbr macht es Sinn vbv auf den cbr Wert zu setzen. (Aber wer braucht cbr ? Haben die eventuell nicht verstanden, was es mit vbv auf sich hat?)
Deine Beobachtungen, bestärken mich zumindest darin, dass ich das vbv erst mal nicht bei NVEncC unterstütze.
Cu Selur
Posts: 77
Threads: 8
Joined: May 2022
Quote:Deine Beobachtungen, bestärken mich zumindest darin, dass ich das vbv erst mal nicht bei NVEncC unterstütze.
Möglicherweise zu früh, vielleicht macht das nur bei CBR Sinn, vielleicht auch bei variable bitrate,...
Ein custom parameter feld wie bei h265 wäre aber aus meiner sicht ne coole Sache um bei so einem unbekannten codec mal an der ein oder anderen Schraube zu drehen, wenn man mit dem Ergebnis nicht so ganz glücklich ist.
Quote:Keine Ahnung was igorslab da macht (das sie cbr für ne brauchbare Idee halten), aber ja bei cbr macht es Sinn vbv auf den cbr Wert zu setzen. (Aber wer braucht cbr ? Haben die eventuell nicht verstanden, was es mit vbv auf sich hat?)
Ich bin mir jedenfalls nicht ganz sicher, ob ich vbv so ganz verstanden habe . Verstehe das grob als Option, die irgendwie eine Ober und Untergrenzen für die maximal verwendeten Bits pro Frame (oder beim buffer ein bestimmtes Zeitfenster, bis der buffer voll bzw. leer ist?) bewirkt. Lief bei mir seither auch unter ferner liefen die Option, wenn ich ehrlich bin...
Meinst du es macht Sinn bei CBR die VBV-maxrate auf die bitrate zu stellen? Warum das beim buffer Sinn machen soll erschließt sich mir nicht so ganz, aber vermutlich habe ich dessen Funktionsweise auch noch nicht ganz begriffen.
Eigentlich finde ich folgendes in der Nvidia SDK documentation auch interessanter. Die tuning info. Möglicherweise wird mit einer korrekt verwendeten tuning auch ein sinniger vbv Wert verwendet. Ich kapier nicht wie NVEncC das umsetzt:
https://docs.nvidia.com/video-technologi...igurations
Es gibt neben den normalen 7 Presets P1 (performance) - P7 (quality) eine sogenannte tuning info, welche ebenfalls 4 Stufen hat.
High quality
Low latency, with CBR
Ultra-low latency, with CBR
Lossless
Ich hab in den NVEncC Optionen aber irgendwie nichts derartiges gefunden, nur das normale preset P1-P7. Eigentlich sollte man beim normalen encoding (nicht für streaming) die "high quality" tuning info verwenden 
Posts: 10.933
Threads: 56
Joined: May 2017
Quote:Ein custom parameter feld wie bei h265 wäre aber aus meiner sicht ne coole Sache um bei so einem unbekannten codec mal an der ein oder anderen Schraube zu drehen, wenn man mit dem Ergebnis nicht so ganz glücklich ist.
NVenc->Misc->Addition
Quote:. Verstehe das grob als Option, die irgendwie eine Ober und Untergrenzen für die maximal verwendeten Bits pro Frame (oder beim buffer ein bestimmtes Zeitfenster, bis der buffer voll bzw. leer ist?) bewirkt. Lief bei mir seither auch unter ferner liefen die Option, wenn ich ehrlich bin...
pro Frame wird da nix festgelegt, da geht es immer um ein 'Fenster' 
Quote:Ich hab in den NVEncC Optionen aber irgendwie nichts derartiges gefunden, nur das normale preset P1-P7. Eigentlich sollte man beim normalen encoding (nicht für streaming) die "high quality" tuning info verwenden
k.A. ob rigaya das nicht eh schon macht.
Müsste man im Sourcecode nachlesen oder rigaya bei Github fragen.
Cu Selur
Posts: 77
Threads: 8
Joined: May 2022
Jedenfalls ist das mit den tuning infos kein Hirngespinst, bei ffmpeg sind die tuning infos mit dem Parameter -tune realisiert (aus nem post von videohelp kopiert):
C:\Windows\system32>"C:\SOFTWARE\Vapoursynth-x64\ffmpeg_OpenCL.exe" -h encoder=hevc_nvenc
ffmpeg version git-2021-08-06-9f19fbb-Hydra3333/python_cross_compile_script_v100 Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 10.3.0 (GCC)
configuration: --arch=x86_64 --target-os=mingw64 --cross-prefix=x86_64-w64-mingw32- --pkg-config=pkg-config --pkg-config-flags=--static --disable-shared --enable-static --disable-w32threads --enable-pthreads --enable-cross-compile --target-exec=wine --enable-runtime-cpudetect --enable-gpl --enable-version3 --extra-version=Hydra3333/python_cross_compile_script_v100 --enable-pic --enable-bzlib --enable-zlib --enable-lzma --enable-fontconfig --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libbluray --enable-libcdio --enable-avisynth --enable-vapoursynth --enable-librtmp --enable-libcaca --enable-iconv --enable-libxml2 --enable-gmp --enable-gnutls --enable-libzimg --enable-libx264 --enable-libx265 --enable-libvpx --enable-libdav1d --disable-libaom --enable-libxvid --enable-gray --enable-libopus --enable-libmp3lame --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libsoxr --enable-librubberband --enable-libass --enable-libwebp --enable-ffnvcodec --enable-cuvid --enable-cuda-llvm --enable-opengl --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-libmfx --enable-amf --enable-opencl --enable-opengl --extra-cflags='-DFRIBIDI_LIB_STATIC -lssp' --extra-libs='-lpsapi -lintl -liconv -lssp' --enable-libtwolame --enable-libzvbi --enable-libgsm --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libsnappy --enable-frei0r --enable-filter=frei0r --enable-libsrt --enable-libbs2b --enable-libilbc --enable-libgme --enable-libflite --enable-sdl2 --enable-libopenmpt --enable-libmysofa --enable-libvidstab --enable-libmodplug --disable-schannel --extra-cflags='-DLIBTWOLAME_STATIC -lssp' --extra-cflags='-DMODPLUG_STATIC -lssp' --extra-cflags='-DLIBXML_STATIC -lssp' --extra-cflags='-DGLIB_STATIC_COMPILATION -lssp' --extra-libs='-lpsapi -lintl -liconv -lssp' --enable-nonfree --enable-libfdk-aac --enable-decklink --prefix=/home/u/Desktop/_working/workdir/win64_output/ffmpeg_git.installed --disable-shared --enable-static
libavutil 57. 3.100 / 57. 3.100
libavcodec 59. 4.100 / 59. 4.100
libavformat 59. 4.101 / 59. 4.101
libavdevice 59. 0.100 / 59. 0.100
libavfilter 8. 1.103 / 8. 1.103
libswscale 6. 0.100 / 6. 0.100
libswresample 4. 0.100 / 4. 0.100
libpostproc 56. 0.100 / 56. 0.100
Encoder hevc_nvenc [NVIDIA NVENC hevc encoder]:
General capabilities: dr1 delay hardware
Threading capabilities: none
Supported hardware devices: cuda cuda d3d11va d3d11va
Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 rgb0 gbrp gbrp16le cuda d3d11
hevc_nvenc AVOptions:
-preset <int> E..V....... Set the encoding preset (from 0 to 18) (default p4)
default 0 E..V.......
slow 1 E..V....... hq 2 passes
medium 2 E..V....... hq 1 pass
fast 3 E..V....... hp 1 pass
hp 4 E..V.......
hq 5 E..V.......
bd 6 E..V.......
ll 7 E..V....... low latency
llhq 8 E..V....... low latency hq
llhp 9 E..V....... low latency hp
lossless 10 E..V....... lossless
losslesshp 11 E..V....... lossless hp
p1 12 E..V....... fastest (lowest quality)
p2 13 E..V....... faster (lower quality)
p3 14 E..V....... fast (low quality)
p4 15 E..V....... medium (default)
p5 16 E..V....... slow (good quality)
p6 17 E..V....... slower (better quality)
p7 18 E..V....... slowest (best quality)
-tune <int> E..V....... Set the encoding tuning info (from 1 to 4) (default hq)
hq 1 E..V....... High quality
ll 2 E..V....... Low latency
ull 3 E..V....... Ultra low latency
lossless 4 E..V....... Lossless
Posts: 10.933
Threads: 56
Joined: May 2017
01.01.2023, 18:48
(This post was last modified: 01.01.2023, 18:48 by Selur.)
const guid_desc list_nvenc_preset_names_ver10[] = {
{ NV_ENC_PRESET_P1_GUID, _T("performance"), NVENC_PRESET_HP },
{ NV_ENC_PRESET_P4_GUID, _T("default"), NVENC_PRESET_DEFAULT },
{ NV_ENC_PRESET_P7_GUID, _T("quality"), NVENC_PRESET_HQ },
{ NV_ENC_PRESET_P1_GUID, _T("P1"), NVENC_PRESET_HP },
{ NV_ENC_PRESET_P2_GUID, _T("P2"), NVENC_PRESET_P2 },
{ NV_ENC_PRESET_P3_GUID, _T("P3"), NVENC_PRESET_P3 },
{ NV_ENC_PRESET_P4_GUID, _T("P4"), NVENC_PRESET_P4 },
{ NV_ENC_PRESET_P5_GUID, _T("P5"), NVENC_PRESET_P5 },
{ NV_ENC_PRESET_P6_GUID, _T("P6"), NVENC_PRESET_P6 },
{ NV_ENC_PRESET_P7_GUID, _T("P7"), NVENC_PRESET_HQ },
};
source: https://github.com/rigaya/NVEnc/blob/mas...ram.h#L173
enum {
NVENC_PRESET_DEFAULT = 0,
NVENC_PRESET_HP,
NVENC_PRESET_P2,
NVENC_PRESET_P3,
NVENC_PRESET_P4,
NVENC_PRESET_P5,
NVENC_PRESET_P6,
NVENC_PRESET_HQ,
NVENC_PRESET_LL,
NVENC_PRESET_LL_HP,
NVENC_PRESET_LL_HQ,
NVENC_PRESET_BD,
};
steht im code.
=> da er extra LL (low latency) Konstanten verwendet, diese aber nicht verwendet, sieht es für mich aus als ob NVEncC diese nicht nutzt und somit alles okay ist.
Cu Selur
Posts: 77
Threads: 8
Joined: May 2022
NVEncC hat auch eine extra --lowlatency Option. Möglicherweise werden damit dann die LL Konstanten genutzt. Hoffen wir das Beste,...
Ein Wermutstropfen bleibt bei NVEnc( C ) HEVC: Der Deblocker lässt sich weder einstellen noch abschalten (im Gegensatz zu h264, da kann man ihn zumindest abschalten).
So bleibt nur für weniger smoothing bei detailarmen Flächen das Drehen an der AQ Schraube nach oben. Ist natürlich schon ein wenig dämlich, erst z.B. mit AQ 15 maximal viele Details zu erzeugen, damit der nicht einstellbare/abschaltbare Deblocker entsprechend viele übrig lässt.
Irgendwie schon seltsam, dass man das bei h264 abstellen kann und bei h265 nicht. Bei x265 geht das ja auch. Bei ffmpeg finde ich weder bei h264 noch h265 eine Abschaltoption.
Wenn man den deblocker zumindest abschalten kann, dann kann man ja einen anderen deblocker als Filter vorschalten und diesen dann entsprechend stark oder schwach einstellen und bei downscaling beispielsweise schon vor dem downscaling anwenden.
Wahrscheinlich macht das NVEnc auch so wenn man dessen internen resizer verwendet, aber das geht halt nur wenn man keinerlei AviSynth/VapourSynth Filter verwendet. Und CAS sharpening hab ich mittlerweile schätzen gelernt beim downscaling. Das macht nicht so ätzende Artefakte wie viele andere Sharpener, aber man hat trotzdem den subjektiven Eindruck eines schärferen Bilds
NVEnc's WarpSharp ist dagegen echt ein schlechter Witz - sieht selbst beim halbieren von treshold und depth völlig künstlich aus, wohingegen die Denoiser ganz OK sind.
Bin echt am überlegen, ob ich da nicht bei Github für rigaya ein issue eröffne und frage ob man bei h265 nicht ebenfalls eine Abschaltoption für den Deblocker einbauen kann...
|
