[BUG] NVEnc Features werden trotz gpu support nicht unterstützt

[Selur]

Irgendwie schon seltsam, dass man das bei h264 abstellen kann und bei h265 nicht.
....
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...

Frage ist halt ob das SDK ne Option dafür bereit stellt. NVIDIA muss ja noch Features für neue Versionen der Chips haben.

Wenn man den deblocker zumindest abschalten kann, dann kann man ja einen anderen deblocker als Filter vorschalten u

Ne, es geht hier um 'in loop' deblocking, externes deblocking macht was anderes und sollte bei Material mit Makroblockartefakten separat angewendet werden vom den Encoding,...

Weder bei H.264 noch H.265 sollte man das Deblocking deaktivieren, abschwächen kann Sinn machen, aber deaktivieren ist unsinnig.

Cu Selur

[mogobime]

Weder bei H.264 noch H.265 sollte man das Deblocking deaktivieren, abschwächen kann Sinn machen, aber deaktivieren ist unsinnig.

Komisch, dass es dann bei NVEnc h264, x264 + x265 überhaupt möglich ist. Abschwächen wäre mir natürlich auch lieber, aber das geht nichtmal bei NVEnc h264.

Dann verhindert das in-loop deblocking wohl eher vom encoder selbst erzeugte Blockartefakte, die z.B. von zu niedriger Bitrate her kommen?!?

Subjektiv hatte ich jedenfalls schon den Eindruck mit abgeschaltetem x264 In-loop deblocking, externem deblocking vorm resizen und CAS sharpening nach dem resizen ein sehr detailreiches und scharfes Bild ohne jedenfalls übermäßige Artefakte zu bekommen. Kann natürlich sein, das abgesenktes in-loop-deblocking ein ähnliches Bild bei niedrigerer Bitrate und noch weniger Artefakten erzeugt hätte...
Werd das Abschalten und externe deblocken wohl aus Neugier auch mal bei NVEnc h264 probieren, hab ich seither wegen fehlendem 10 bit nicht gemacht.

Aber wenn du Abschalten von in-loop-deblocking generell für unsinnig hältst muss ich mir natürlich nochmal überlegen, ob ich rigaya damit konfrontieren soll...

[Selur]

Dann verhindert das in-loop deblocking wohl eher vom encoder selbst erzeugte Blockartefakte, die z.B. von zu niedriger Bitrate her kommen?!?

Ja, es sollte deblocked und etwas gesmoothed werden, wenn blocking entsteht. Das Heruntersetzen regelt quasi die Stärke des Deblockings.

Wenn inloop-deblocking deaktiviert ist, verlieren H.264 und H.265 ein wesentliches Instrument zur Kompression, sprich Datenraten werden entsprechend steigen oder die Qualität sinken (wenn die Zielgröße fest ist).

Cu Selur

[mogobime]

Eine wilde Kaskade wäre natürlich auch deblock (normal) oder fft3dgpu (leicht)->lanczos resize->deblock (leicht)->CAS->NVEnc (mit ausgeschaltetem deblock). Ist zwar nicht dasselbe wie in-loop-deblocking, aber wird wahrscheinlich auch noch ein paar Bits rausquetschen. Wird natürlich auch nicht gerade schneller dadurch , vor allem fft3dgpu bei 4K Material bremst gewaltig (aber immer noch deutlich weniger als KNLMeansCL oder QTGMC).

[Selur]

...bei 4K Material bremst gewaltig...

Ist halt die temporäre Komponente, die bremst und die Tatsache, das 4k halt recht viele Pixel sind.
Wenn Du KNLMeansCL mit distance = 0 verwendest, sollte es noch recht flott sein.

Wenn Du Avisynth verwendest, kannst auch mal DGDenoise antesten.

Cu Selur

[mogobime]

Werde früher oder später auch mal die anderen Denoiser zum Zwecke des nur leichten Denoisings um Bits zu sparen antesten. Fluxsmooth mit VapourSynthhab ich dafür auch schonmal verwendet, ist recht flott, dafür dass es eine Spatio-Temporal Funktion hat.

FFT3DGPU läuft als ST Filter jedenfalls in komplexen Skripten (vor allem bei 4K) nur einigermaßen zügig mit Prefetch(1,7) und Prefetch(4) bei allen nachfolgenden Filtern (End Prefetch und vorangehende Filter können und sollten anscheinend durchaus wieder einen höheren Prefetch haben). Irgendwie kommt FFT3DGPU mit mehr als 7 Frames im eigenen Prefetch nicht vernünftig klar (hab ich mittlerweile mit 3 verschiedenen Grafikkarten ausprobiert) und wenn nachfolgende Filter mehr als 7-8 frames puffern lassen (Prefetch(4) steht ja für Prefetch(4,8)) läuft's auch oft nicht mehr richtig rund. Die nachfolgenden Filter Prefetches laufen dann anscheinend Gefahr immer wieder leer zu laufen, und das Skript kann ins stocken kommen.
Beachtet man das alles nicht, kann der Speed schonmal um 50-70% absinken. Bestimmt verhält es sich mit anderen ST Filtern ähnlich, was die nachfolgenden Filter prefetches angeht.

Da würde es einem in Ermangelung einer durchdachteren Lösung das Filtern mit AviSynth leichter machen, wenn man bei "Custom" auch "Insert After" auswählen könnte, da AviSynth+ ja den Filter Prefetch immer nach dem Filter haben will. Aber jetzt passt's langsam nicht mehr zum Thema. Kannst ja mal drüber nachdenken...

[bitspyer]

Interessante Unterhaltung hier... Ich beschäftige mich ja auch gerne mit dem Nvencc. Vielleicht nicht ganz so tief wie ihr, aber immer auf der Suche nach Best Practice Options für den Nvencc.

Im groben bin ich beim Nvencc zur Erkenntnis gekommen, dass dieser vieles mit Bitrate erschlägt. Natürlich kommt auch einiges auf die Quelle drauf an.
Mit x265 und gut eingestellten Options ist das Ziel nachher bedeutendet kleiner, allerdings mit einem Zeitaufwand jenseits von Gut und Böse. Ich bin da bei  4-6fps maximal.

Mit Nvencc erreiche ich mit einer Bitrate von 35Mbit - 45Mbit eine für mich akzeptable Qualität. (VMAF meistens so bei 95, nie unter 90).

Als Options für mich habe ich da folgendes, wobei ich mal Hybrid nehme, mal direkt NVencc füttere, ohne anderes Tool herum.

--level auto --tier high --sar 1:1 --lookahead 32 --aq --aq-strength 2 --aq-temporal --strict-gop --gop-len 240 --ref 8 --bframes 5 --bref-mode each --mv-precision Q-pel --preset quality --output-thread 1 --repeat-headers --colorrange auto --colorprim auto --transfer auto --cuda-schedule auto --max-cll copy --master-display copy

Dann wird noch mit qvbr zwischen 22 und 18 gespielt, eventuell noch mit --max-bitrate der Spielraum eingerschränkt.

Damit fahre ich ganz gut, zumal auch inzwischen Cropping direkt in nvencc funktioniert.
Nvencc ist halt nicht auf niedrige Bitraten optimiert, auch wenn es besser wird. Glaube aber nicht, das man je in die Gefilde eines x265 kommen wird. Manche Tools geben bei Nvencc bei 4K zb nur einen Spielraum innerhalb von 20Mbit, da meine ich aber mehr unschärfe zu entdecken, als bei 40mbit. (Ja, erschlage fehlende Optimierung durch Bitrate), dafür ist Nvencc allerdings auch (noch) unschlagbar in der benötigten Zeit (bei mir ca. 30fps).

NvenCC hat inzwischen auch viele Filter direkt implementiert, wobei ich nichts über deren Qualität sagen kann, da ich sehr selten Filter nutze. Vielleicht mal einen minimalen Rauschfilter.