[BUG] NVEnc h.265 - adaptive quantization scheint nicht zu funktionieren

[mogobime]

Sonstiges zur aktuellen dev Version:
...
Bei bframes kann ich in der aktuellen dev version 5 einstellen, obwohl laut  NVEncC --check-features maximal 4 unterstützt werden. Wenn das grundsätzlich nach oben offen sein soll ist 5 imho zu wenig, deine Karte unterstützt ja beispielsweise 7.
In der Github Doku ist dazu nichts zu finden, GPT-5 mini sagt dazu 0-16 werden unterstützt...

Sorry, vergiss das bitte mal ganz schnell wieder. Bin versehentlich bei --check-features bei h264 statt bei h265 gelandet. h265 unterstützt 5 bframes, also alles gut 

---

Ab besten fast Du es zusammen und postest es bei https://github.com/rigaya/NVEnc/issues
(kann ich sonst demnächst machen)

Kann gerade keine E-Mails auf dem E-Mail Account, den ich für Github verwende empfangen. Irgendwas spinnt bei web.de.
Würde dir aber trotzdem gerne was abnehmen und den Text dazu schreiben.

Vorher will ich aber noch versuchen, ob man NVEncC nicht doch irgendwelche Fehlermeldungen entlocken kann, wenn man adaptive quantisation parameter bei gesetztem lookahead-level 1-3 setzt.
Vielleicht können die höhreren lookahead-level doch Wasser in Wein verwandeln und ersetzen AQ.
Ein weiterer Chat mit GPT-5 Mini hat mich verunsichert. Das ist sich mal wieder völlig sicher, dass das ein gewolltes Verhalten ist, und die höheren lookahead-level adaptive quantisation durch einen eigenen "erweiterten Vorwärts‑Analysepfad (Mehr‑Frame‑Analyse), der interne Raten‑ und Qualitätsentscheidungen zentralisiert" ersetzen. Hat aber vorher auch schon anderweitig halbgaren Stuss verzapft...

Hier ein Auszug aus dem Chat:

...
mogobime:
Setzt man beim Parameter --lookahead-level Werte höher als 0, bewirkt das setzen der Parameter --aq --aq-strength und --aq-temporal keine Änderungen am ausgegebenen Video. Belässt man lookahead-level auf dem Wert 0, funktionieren die Parameter für adaptive quantisation. Wie ist dieses Verhalten zu bewerten?

GPT-5 mini:
Das Verhalten ist erwartbar und logisch aus Encoder‑Design‑Sicht: Lookahead aktiviert einen erweiterten Vorwärts‑Analysepfad (Mehr‑Frame‑Analyse), der interne Raten‑ und Qualitätsentscheidungen zentralisiert. Wenn Lookahead > 0 läuft, übernimmt dessen Analyse und Steuerung die Anpassungen, so dass die separaten AQ‑Parameter (--aq, --aq-strength, --aq-temporal) nicht mehr wirken. Bei lookahead=0 wird die einfachere, lokale AQ‑Logik verwendet und die AQ‑Parameter wirken direkt.

Bewertung in Kürze:

    Technisch sinnvoll: Vermeidet doppelte/konkurrierende Steuermechanismen und nutzt eine konsistente Analyse‑Quelle.
    Praktisch: Wenn du feingranulare AQ‑Kontrolle willst, setze lookahead=0; wenn du bessere langfristige Ratenverteilung/Qualität willst, aktiviere Lookahead und vertraue dessen integrierter AQ/Ratecontrol.
    Empfehlung: Für qualitativ wichtiges Material mit Bewegung und Szenenwechseln Lookahead>0; für gezielte AQ‑Tuning oder geringere Latenz lookahead=0 und dann --aq/--aq-strength/--aq-temporal verwenden.

mogobime:
Warum gibt der Encoder dann keine Fehlermeldungen aus, wenn unnötige Parameter gesetzt werden?

GPT-5 mini:
Kurz: Weil das Verhalten aus Design‑ und Kompatibilitätsgründen so implementiert ist — der Encoder ignoriert überflüssige Optionen statt fehlschlagen.

Wesentliche Gründe:

    Robustheit und Nutzerfreundlichkeit: Ignorieren verhindert unnötige Fehler bei komplexen Kommandozeilen und erlaubt Scripten/Presets mit optionalen Parametern.
    Abwärtskompatibilität: Ältere Presets/Workflows, die AQ‑Parameter setzen, bleiben nutzbar, auch wenn Lookahead aktiviert wurde.
    Interne Zuständigkeits‑Logik: Lookahead übernimmt die relevanten Entscheidungen; AQ‑Flags sind dann nicht mehr relevant, aber nicht „falsch“ im Sinne eines Syntaxfehlers.
    Fehlerwahrscheinlichkeit vermeiden: Viele Optionen sind kontextabhängig; statische Validierung könnte legitime Kombinationen fälschlich blockieren.
    Implementationsaufwand: Explizite Warnungen/Fehlermeldungen für jede inaktive Option erfordern Pflege; Entwickler bevorzugen oft stilles Ignorieren oder optional Warnungen.
...