Videoaufnahme ruckelt

Efaniel schrieb:
Bei lokalen Aufnahmen nutzt man CQP, damit das Video nur dort Bitrate verbraucht, wo es auch nötig ist.
Bin nicht so im NVENC drin, aber wie siehts eigentlich mit QVBR aus? Die KI behauptet hier folgendes:

Overview of NVENC QVBR and CQP​

NVIDIA's NVENC encoder offers different rate control modes for video encoding, notably QVBR (Quality Variable Bitrate) and CQP (Constant Quality). Each mode serves distinct purposes and has unique advantages.

Key Differences​


FeatureQVBRCQP
PurposeHigh quality with file size limitationConsistent quality without file size limit
File SizeVariable, optimized for qualityGenerally larger, as quality is prioritized
Use CaseIdeal for streaming and recordingBest for high-quality local recordings
Bitrate ManagementAdjusts bitrate based on scene complexityFixed quality target, adjusts bitrate automatically

When to Use Each Mode​

  • QVBR:
    • Best for streaming where maintaining quality while controlling file size is crucial.
    • Efficient for scenarios where bandwidth is limited.
  • CQP:
    • Suitable for local recordings where file size is not a concern.
    • Provides high-quality output, often near lossless, making it ideal for editing and archiving.

Conclusion​

Choosing between QVBR and CQP depends on your specific needs. If you prioritize quality while managing file size, QVBR is the better option. For high-quality recordings without regard for file size, CQP is recommended.

Klingt irgendwie so, als ob CQP der "agressivere" Quality-Mode ist.
 
@qiller mit QVBR habe ich bisher keine Erfahrung gemacht.
Was ich eben dazu gelesen habe ist, dass der Unterschied darin liegt, dass CQP z.B. je nach Komplexität der Szene sehr hohe Bitraten erreichen kann und du bei QVBR zu dem Quantization Factor noch einen zusätzlichen Max-Bitrate Value angeben kannst.

Also selbst wenn die Szene zu komplex wird um die vorgegebene Quality-Stufe zu halten wird sie künstlich von der Max-Bitrate gebremst.
Das soll helfen um die Dateien in ihrer Maximalgröße einzudämmen.
Wenn man sagt 50.000 kbps Max Bitrate dann wird die Datei nicht darüber hinaus steigen.

Was deine AI da aber sagt "streaming" für QVBR halte ich für quatsch. Es gibt nicht einen Anbieter der es unterstützt und von der Logik her müsste ein sehr hoher Aufwand auf der Ingest-Server Seite erfolgen mittels Keyframes und Puffer.
Live Streaming ist aber auf Interaktion mit den Zuschauern aufgebaut und das würde damit nicht mehr funktionieren - so denke ich zumindest.
 
Efaniel schrieb:
Das ist ehrlich gesagt mit Kanonen auf Spatzen geschossen und hebt die Vorteile von AV1 komplett auf.

kommt drauf an, welche qualiät man will.
dazu schrieb ich, dass man auch CQP nehmen kann


Efaniel schrieb:
Warum riesige Dateien vermeiden? Du blähst dir nur die Festplatte voll, hast längere Upload-Zeiten

redest du von dir? weil ich hab weder das festplatte noch das Upload-Problem

Efaniel schrieb:
YouTube-Komprimierung komplett zunichtemacht

bin ich froh, dass ich das noch nicht hatte seitdem ich AV1 Hardware besaß

das trifft nur zu, wenn man FHD/WQHD rendern mag und nur wenn man das Material kein fastpace content ist

Efaniel schrieb:
CBR gehört ins Streaming, nicht in Aufnahmen: Bei lokalen Aufnahmen nutzt man CQP, damit das Video nur dort Bitrate verbraucht, wo es auch nötig ist.

ob CQP oder CBR hängt davon ab, welche art von Qualität man will und ob man AV1 kann.
 
NerdmitHerz schrieb:
ob CQP oder CBR hängt davon ab, welche art von Qualität man will
Ne, eigentlich hängt das von den technischen Möglichkeiten bei Aufnahme, Übertragung und Wiedergabe ab. Wenn CQP wirklich so hohe Bitratenschwankungen erzeugen kann, ist das fürs Streaming übers Internet mit i.d.R. niedrigen Uploadraten total ungeeignet, denn jede detailreiche Szene mit schnellen Änderungen würde die Bitratenanforderung in die Höhe und damit übers Uploadratenlimit des Anschlusses schnellen lassen. Das führt dann dazu, dass in Menüs oder ruhigen Szenen noch alles normal übertragen wird, aber in schnellen Szenen es zu ordentlich Framedrops kommt....

Efaniel schrieb:
bei QVBR zu dem Quantization Factor noch einen zusätzlichen Max-Bitrate Value angeben kannst.
Efaniel schrieb:
"streaming" für QVBR halte ich für quatsch
...dann könnte in der Tat QVBR mit so einem Max-Bitrate Wert eine Lösung darstellen, um doch mit variablen Bitraten streamen zu können.

Ich kenn das mit diesem "Max-Bitrate" Wert allerdings von SVT-AV1 (heißt da "mbr") und wenn man da nen CRF-Encode macht, wird der Wert ignoriert. Ka, obs nur ein Bug in der Implementierung ist, aber in SVT-AV1 scheint das mit der Max-Bitrate nicht zu funktionieren (und irgendwie widerspricht das ja auch dem "Constant Quality" Gedanken).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Efaniel
NerdmitHerz schrieb:
ob CQP oder CBR hängt davon ab, welche art von Qualität man will und ob man AV1 kann.
Nein, das ist technisch so nicht ganz richtig. CBR und CQP sind keine unterschiedlichen "Qualitätsstufen“, sondern unterschiedliche Rate-Control-Verfahren.

CBR versucht, unabhängig vom Bildinhalt eine konstante Datenrate einzuhalten. Ob gerade ein schwarzer Ladebildschirm zu sehen ist oder BeamNG mit maximaler Bewegung und Vegetation läuft - der Encoder bekommt dasselbe Bitraten-Budget pro Sekunde.

CQP funktioniert genau andersherum: der Encoder hält die Quantisierung bzw. die angestrebte sichtbare Qualität möglichst konstant und darf dafür die Bitrate dem Bildinhalt entsprechend schwanken lassen. Bei wenig Bewegung wird entsprechend wenig geschrieben, bei komplexen Szenen deutlich mehr.

Deshalb ist CQP für lokale Game-Aufnahmen normalerweise die sinnvollere Wahl.
CBR ist nicht "verboten“ oder grundsätzlich falsch, aber an dieser Stelle schlicht nicht der passende Ansatz, wenn das Ziel eine möglichst gute Qualität bei möglichst effizienter Dateigröße ist.

NerdmitHerz schrieb:
bin ich froh, dass ich das noch nicht hatte seitdem ich AV1 Hardware besaß

das trifft nur zu, wenn man FHD/WQHD rendern mag und nur wenn das Material kein fastpace content ist
Gerade bei Fast-Paced-Content sehe ich CQP eher im Vorteil. Wenn die Szene komplex wird, kann der Encoder die benötigte Bitrate entsprechend erhöhen. Bei CBR ist das Bitraten-Budget dagegen fest vorgegeben.

Und natürlich re-codiert YouTube das hochgeladene Material. Das bedeutet nicht, dass jedes Ausgangsmaterial zwangsläufig exakt gleich aussieht – die Qualität des Ausgangsmaterials kann durchaus einen Einfluss auf das Ergebnis haben.

Aber 100 Mbit/s CBR sind deshalb nicht automatisch sinnvoller als ein vernünftig eingestelltes CQP-AV1.
CQP 14 bei AV1 ebenfalls nicht - da landen wir vermutlich in ähnliche wenn nicht sogar größere Regionen was die Dateigröße angeht.
NerdmitHerz schrieb:
redest du von dir? weil ich hab weder das festplatte noch das Upload-Problem
Nein, ich rede aber auch nicht von Dir. Genau das ist doch der Punkt.

Es geht hier nicht darum, ob DU persönlich 60 GB Videodateien speichern oder hochladen kannst. Der TE hat nach einer sinnvollen Lösung für seine Aufnahmen gefragt und kommt von Bandicam mit H.264 bei etwa 30 Mbit/s.

Die Frage ist also: Was ist für diesen Anwendungsfall eine vernünftige Einstellung?

Und da halte ich 100 Mbit/s CBR bzw. CQP 14 für deutlich überdimensioniert. Nicht weil ich persönlich Speicherplatz sparen muss, sondern weil man einem Nutzer nicht ohne konkreten Grund das drei- bis vierfache an Datenvolumen empfehlen muss, wenn ein deutlich effizienterer Ansatz für praktisch denselben Zweck existiert.

Dein persönlicher Speicher- oder Upload-Spielraum ist dafür schlicht nicht relevant.

Und genau deshalb finde ich den Einwand "ich habe damit aber kein Problem“ etwas am Thema vorbei. Es geht nicht darum, was bei dir funktioniert, sondern darum, was man jemandem als sinnvolle Standardeinstellung empfiehlt, der einfach BeamNG aufnehmen und anschließend auf YouTube hochladen möchte.

Ich will dir deine 100 Mbit/s oder CQP 14 ja gar nicht wegnehmen. Wenn du für dein eigenes Material genau diese Einstellungen bevorzugst und den zusätzlichen Speicherbedarf bewusst in Kauf nimmst: absolute fine with me.

Als Empfehlung für den TE halte ich es aber weiterhin für Kanonen auf Spatzen schießen.

Auto vergleiche sind zwar doof, aber da der TE ja Beam.NG aufnehmen möchte, nutze ich das trotzdem.
Du empfiehlst ihn für eine Strecke von A nach B gerade einen Maybach und gehst in die vollen und ich sagte dazu, dass man auch mit einem vernünftigen Mittelklasse-Wagen das Ziel ebenfalls komfortabel und effektiv mit genau der selben Fahrzeit erreichen kann. 😉

qiller schrieb:
Ich kenn das mit diesem "Max-Bitrate" Wert allerdings von SVT-AV1 (heißt da "mbr") und wenn man da nen CRF-Encode macht, wird der Wert ignoriert. Ka, obs nur ein Bug in der Implementierung ist, aber in SVT-AV1 scheint das mit der Max-Bitrate nicht zu funktionieren.

Ich habe selbst eben mal in OBS geschaut und wenn ich QVBR einstelle fehlt mir ebenfalls die MAX-Bitrate Setting. Anscheinend ist diese dynamisch in die CQ Stufe gewandert und erhöht sich je nachdem welchen CQ Level man wählt - warum das so ist, weiß ich leider noch nicht.
Werde wohl mal Testaufnahmen machen und schauen, ob ich Anhand der CQ Stufe die jeweilige Max Bitrate ermitteln kann.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: qiller
Efaniel schrieb:
Ich habe selbst eben mal in OBS geschaut und wenn ich QVBR einstelle fehlt mir ebenfalls die MAX-Bitrate Setting.
In Staxrip würde es gehen. Aber ich denke, auch da wird der Wert ignoriert werden.

1789321071630.png
1789321043048.png

Ich kanns für AV1 auch nicht testen, weil meine RTX 3090 das nicht encoden kann. Könnte ich höchstens mit HEVC testen.
 
  • Gefällt mir
Reaktionen: Efaniel
qiller schrieb:
Ne, eigentlich hängt das von den technischen Möglichkeiten bei Aufnahme, Übertragung und Wiedergabe ab. Wenn CQP wirklich so hohe Bitratenschwankungen erzeugen kann, ist das fürs Streaming übers Internet mit i.d.R. niedrigen Uploadraten total ungeeignet, denn jede detailreiche Szene mit schnellen Änderungen würde die Bitratenanforderung in die Höhe und damit übers Uploadratenlimit des Anschlusses schnellen lassen. Das führt dann dazu, dass in Menüs oder ruhigen Szenen noch alles normal übertragen wird, aber in schnellen Szenen es zu ordentlich Framedrops kommt....

kommt denn noch auf die Bitrate drauf an, die man selbst zur Verfügung hat

bei youtube wären es max 51 Mbit/s und bei Twitch kommt man im Moment mit 1440p60 auf 12 Mbit/s dank TwitchEB

da es hier um reines Recording geht, wäre der Streaming-Part irrelevant.

ich hab es nur erwähnt, sollte es für Lesende interessant sein

Efaniel schrieb:
Aber 100 Mbit/s CBR sind deshalb nicht automatisch sinnvoller als ein vernünftig eingestelltes CQP-AV1.
CQP 14 bei AV1 ebenfalls nicht - da landen wir vermutlich in ähnliche wenn nicht sogar größere Regionen was die Dateigröße angeht.

die länge des recordings bestimmt am ende die größe der datei
 
NerdmitHerz schrieb:
die länge des recordings bestimmt am ende die größe der datei
Ja. Und der Tankinhalt bestimmt, wie weit ein Auto kommt. 🤷‍♂️

Das die Aufnahmelänge ein Faktor ist, bestreitet niemand. Bei CQP kommt aber – völlig überraschend – noch der Bildinhalt dazu, weshalb die benötigte Bitrate und damit die Dateigröße schwankt.

Genau deshalb heißt es Constant QP und nicht Constant File Size.

Was mich an der Diskussion inzwischen eher amüsiert ist:
Statt bei den eigentlichen technischen Punkten einmal einzuräumen, dass 100 Mbit/s CBR bzw. CQP 14 für den konkreten Anwendungsfall schlicht ziemlich overkill ist, wird die ursprüngliche Empfehlung offenbar um jeden Preis verteidigt und die Diskussion dafür immer weiter auf Nebenschauplätze verschoben.

Ich sage lediglich weiterhin:
Für jemanden, der von 30 Mbit/s H.264-Bandicam-Aufnahmen kommt und Beam.NG auf YouTube stellen möchte, ist das unnötiges Overkill.

Wir können jetzt natürlich noch weitere Runden drehen, bis aus „die Länge des Recordings bestimmt die Dateigröße“ die nächste Begründung für CQP 14 geworden ist. 😏

Ich glaube allerdings, wir kommen hier nicht mehr wirklich weiter - sehr schade.

@Timminator1701 hat alle Informationen die er braucht - wenn es noch gezielt Fragen gibt - gerne her damit. Das ist dann wenigstens noch sinnvoll.
 
Kenne mich mit NVENC nicht wirklich aus aber hat der überhaupt einen echten CBR-Modus? Lass die Aufnahme doch mal von ffbitrateviewer analysieren. Bei vielen Encodern wie x264 oder x265 kann man zwar CBR einstellen aber die Bitrate ist auch da nie konstant und geht bei schwarzem Bild oder Standbild immer weit nach unten.

Edit: Oh doch bei OBS drückt er dem Videostream tatsächlich eine konstate Bitrate rein. War mit ziemlich sicher, dass das bei früheren Versionen nicht ging. Vielleicht ein Bug gewesen. Nur bei SVT-AV1 in OBS geht CBR nicht. Liegt vielleicht auch an ffmpeg encodern lib264/265 etc. Unter Staxrip mit x264/265 bekomme ich keine konstante Bitrate hin. Auch nicht wenn man --strict-cbr; --nal-hrd cbr etc. einstellt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: qiller
1789395745711.png

Ziemlich konstante Bitrate bei den OBS CBR Captures.
1. 1920x800 @ 120fps NVENC HEVC 20Mbit/s CBR 8bit SDR BT.709
2. 3840x1600 @ 60FPS NVENC HEVC 20Mbit/s CBR 8bit SDR BT.709
3. 3840x1600 @ 60FPS NVENC HEVC 50Mbit/s CBR 10bit HDR BT.2020

Edit: CP2077 Capture mit OBS
1789398239098.png


1. 3840x1600 @ 60FPS NVENC HEVC CQP20 10bit HDR BT.2020/HLG
2. 3840x1600 @ 60FPS NVENC HEVC VBR=40Mbit/s max. Bitrate=80Mbit/s 10bit HDR BT.2020/HLG
3. 3840x1600 @ 60FPS NVENC HEVC QVBR24 max. Bitrate=80Mbit/s 10bit HDR BT.2020/HLG
4. 3840x1600 @ 60FPS NVENC HEVC QVBR22 max. Bitrate=80Mbit/s 10bit HDR BT.2020/HLG

Der vierte Capture war nur um zu sehen, ob das im dritten Capture mit QVBR nur ein Zufall war und die vorgegebene max. Bitrate von 80Mbit/s nun funktioniert oder nicht. Scheint wohl nicht zu funktionieren. Größte Streuung der Bitrate hat man, wie schon hier vermutet, mit CQP-Encoding. Die Captures waren jetzt nicht identisch. Für einen besseren Vergleich müsste man sich wohl ein besseres Spiel/Szene suchen, die immer konstant abläuft.
 
Zuletzt bearbeitet:
Zurück
Oben