Einen schöne guten Tag,
da immer wieder die frage aufkommt: Ist die Qualität so gut?,” oder “Wie kann ich meine Qualität verbessern?”.
Werden wir uns heute mal damit beschäftigen, Schritt für Schritt.
Aufnahme
Anfangen werden wir mit der Aufnahme, da man bereits hier sehr viel Qualität einbüßen kann.
Worauf sollte man aber bei der Aufnahme achten?
[lexicon]Bitrate[/lexicon] = Wenn wir unser Aufnahme verlustfrei aufnehmen, können wir hier viel Qualität erhalten.
Dabei kommt es auf den verwendeten [lexicon]Codec[/lexicon] an und wie dieser Eingestellt wird.
Hierbei gibt es drei Arten von Codecs.
1. [lexicon]Lossless[/lexicon] = Die erste Art ist der [lexicon]Lossless[/lexicon] [lexicon]Codec[/lexicon], hier drunter Fallen die Codecs UT Video, [lexicon]MagicYUV[/lexicon], [lexicon]Lagarith[/lexicon] [lexicon]Lossless[/lexicon] [lexicon]Codec[/lexicon] und der [lexicon]Codec[/lexicon] von [lexicon]Fraps[/lexicon].
Diese Codecs können nur verlustfrei Aufnehmen.
2. [lexicon]Lossy[/lexicon] = Die zweite Art sind die [lexicon]Lossy[/lexicon] Codecs, darunter Fallen Codecs wie MJPG, der [lexicon]Codec[/lexicon] von Miralles Action!, Nvidias NVENC wenn man ihn mit [lexicon]Shadowplay[/lexicon] nutzt.
Diese Codecs können nur verlustbehaftet aufnehmen, wodurch wir dann bei der Aufnahme bereits Qualität verlieren.
3. [lexicon]Lossless[/lexicon]/[lexicon]Lossy[/lexicon] = Die dritte Art sind die Codecs die man so einstellen kann das sie [lexicon]Lossless[/lexicon] oder [lexicon]Lossy[/lexicon] aufnehmen, das beste Beispielt hier ist der [lexicon]Encoder[/lexicon] [lexicon]x264[/lexicon] des Codecs [lexicon]H.264[/lexicon].
Diesen können wir zwar mit dem Parameter qp=0 [lexicon]Lossless[/lexicon] einstellen, dafür haben wir aber dann das High 4:4:4, wodurch viele [lexicon]NLE[/lexicon]’s (Videobearbeitungsprogramme mit Timeline) diese Aufnahme dann wieder nicht öffnen könne.
Tutorial = Bearbeitung von Lets Plays ohne Timeline:
Kommt noch!
Vergleich:
[lexicon]Lossless[/lexicon]:
http://abload.de/img/720plossless68umt.png
[lexicon]Lossy[/lexicon] 50.000 kbit/s:
http://abload.de/img/720p50.000kbitsqjumh.png
Für diesen Vergleich habe ich aus einer 720p@60@RGB24 [lexicon]Lossless[/lexicon] Aufnahme zwei Videos erstellt.
Das erste Video hat dabei 720p@60@YV12 und ist [lexicon]Lossless[/lexicon].
Das zweite Video hatte 720p@60@YV12 und wurde so gut wie möglich auf eine [lexicon]Bitrate[/lexicon] von 50.000 kbit/s beschränkt um die Aufnahme Qualität von [lexicon]Shadowplay[/lexicon] zu zeigen.
Damit mir keiner vorwerfen kann, dass ich beim ersten [lexicon]Lossy[/lexicon] Video extra schlechte Einstellungen benutzt habe, wurde dieses Video mit einem Preset von Slow erstellt, an das in Punkto Qualität kein Aufnahmeprogramm ein Gleichwertiges Ergebnis erzielt, da mit diesem Profil ein Video nicht in Echtzeit Codiert werden kann, desweiteren wurde der [lexicon]GOP[/lexicon] auf 0 gestellt um nochmal Dateigröße einzusparen.
Farbraum = Als nächstes kommen wir zum Farbraum, da dieser einen sehr großen Einfluss auf die Dateigröße der Aufnahme und der Qualität hat.
Den Farbraum gibt es in verschiedenen Stufen.
1. RGB 4:4:4 / RGB 24 = Der hochwertigste Farbraum ist der RGB 4:4:4 / RGB24 Farbraum, da dieser pro Farbe 8 Bit hat. Der RGB Farbraum besteht aus 3 Farben, Rot, Grün und Blau, somit haben wir pro Pixel 3 Byte, was bei der Aufnahme zu einer sehr großen Datei führt
Es gibt auch den den RGB 4:4:4 + Alpha / RGB32 Farbraum diese besteht aus Rot, Grün, Blau und dem Alphan Kanal (Transparent). Da bei einer Aufnahme der Alpha Kanal leer bleibt, ist das für uns egal ob wir in RGB24 oder 32 Aufnehmen.
2. YUV 4:4:4 (YV24, I444) = Der Farbraum mit der nächst höheren Qualität ist YUV4:4:4 / YV24, diesr besteht aus Y = Luminanz (Hälligkeitsanteil) und Chrominanz dieser wird dann noch in U (Blauanteil) und V (Rotanteil) unterteilt. Wobei aus U und V sämtliche Farben gemischt werden können und Y nur für die Helligkeit zuständig ist. Beim YUV 4:4:4 / YV24 hat wieder jeder Teil seine 8 Bit.
Warum ist YUV 4:4:4 / YV24 aber schlechter als RGB 4:4:4 / RGB24?
Weil wir bereits hier eine Farbkonvertierung vom Farbraum RGB zu YUV haben, da unser Pc immer in RGB ausgibt. Der Unterschied in der Qualität ist so gering das er nur Messbar ist, weil hier kleine Rundungsfehler beim Konvertieren entstehen.
3. YUV 4:2:2 (YUY2, YV16, UYVY, 2VUY, HDYC, I422) = Als drittes haben wir den YUV 4:2:2 / YV16, dieser ist ein guter Kompromiss zwischen Dateigröße und Qualität. Der Y Bereich ist noch immer mit 8 Bit angegeben aber der UV Bereich nur noch mit jeweils 4 Bit, wodurch wir eine leichte horizontale Verschmierung der Farben haben. Dafür sparen wir ~33% der Dateigröße ein.
4. YUV 4:2:0 (YV12, IYUV, I420) = Als letztes haben wir dann noch den YUV 4:2:0 / YV12 Farbraum, dieser ist die niedriegste Qualität in der wir Aufnahme sollten. Hier sparen wir dann dann auch ganze 50% der Dateigröße, was zulasten der Qualität geht.
Beim YUV 4:2:0 / YV12 wird der Luma Bereich noch immer mit 8 Bit angeben, der U Bereich hat weiterhin noch 2 Bit, aber der V Bereich erhält 2 Bit, wodurch wir eine leichte horizon- und vertikale Verschmierungen der Farben haben.
Farbmatrix = Als nächstes kommen wir zur Farbmatrix, diese gibt es nur bei den YUV Farbräumen.
Die Farbmatrix beschneiden die angezeigten Farben.
Warum sollten wir zum Beispiel Farben mischen die wir nicht sehen können?
Die Farbmatrix wird in Zahlen angegeben, .601, .709, .2020,...
Die Farbmatrix 601 wurde früher bis 576p verwendeten.
Alles ab 720p bekommt 709 und diese wird auch von Youtube verwändet.
Ab 2160p wird sogar 2020 verwendet, die bekommen wir aber von Youtube nicht, wenn wir Videos mit der [lexicon]Auflösung[/lexicon] hochladen.
Vergleicht man 601 mit 709 so sieht das Video mit der Farbramtix 601 aus als hättes es einen Grauschleier, da wir hier weniger Farbsättigung haben.
--------------------------------------------------------------------------------------------------------------
Vergleichsbild
--------------------------------------------------------------------------------------------------------------
Aus dem Grund sollte man auch den [lexicon]Lagarith[/lexicon] [lexicon]Lossless[/lexicon] [lexicon]Codec[/lexicon] nicht nutzen, da er die Fabmatrix 601 benutzt, sollte man aber mit dem [lexicon]Lagarith[/lexicon] [lexicon]Lossless[/lexicon] [lexicon]Codec[/lexicon] in RGB aufnehmen hat man das Problem nicht, da RGB immer alle Farben darstellen kann.
Bei UT Video und [lexicon]MagicYUV[/lexicon] kann man die Farbmatrix auf 709 stellen.
Farbbereich = Zum Schluss kommen wir zum Farbbereich, dieser wird in PC (Vollbereich) oder TV (Begrentzter Bereich) angegeben. Der TV Bereich hat im Gegensatz zum Pc Bereich einen etwas matteren Schwarz- und Weißton
Pc: 0-255
TV: 16-235
Hierbei ist Wichtig zu wissen in welchem Bereich aufgenommen wurde und im welchen Bereich Ausgegeben wird, da es hier ansonsten zu Fehler kommen kann.
Dabei gibt es die Kompinationen:
TV Bereich -> PC Bereich = Matte Farbdarstellung (Grauschleier)
TV Bereich -> TV Bereich = Neutral
PC Bereich -> TV Bereich = dunklere Farbdarstellung
PC Bereich -> PC Bereich = Neutral
Für Youtube nehmen wir im TV Bereich auf und verarbeiten unsere Videos auch im TV Bereich. Sollte man jetzt Chrom nutzen um sich die Video anzuschauen kann es zu Fehler kommen, das hängt damit zusammen das Chrome die Videos in PC Bereich ausgibt, was auch kein Problem darstellt.
Nur jetzt kommt unsere [lexicon]Grafikkarte[/lexicon] die mehr das ein Videoplayer was im Pc Bereich ausgeben möchte und sagt sich:” Ne, das kann nicht sein!”
Dadurch wird dann der Farbbereich nicht wie bei Youtube konvertiert, sondern einfach beschnitten was dazu führt das das Video dunkler dargestellt wird.
Um dieses Problem zu beheben müssen wir auf die Einstellungen unsere [lexicon]Grafikkarte[/lexicon] zugreifen und die Darstellung der Videoplayer von TV auf Pc umstellen.
Das hat in den meisten Fällen keinen weiteren Einfluss, außer bei sehr alten Spielen kann es so zu einem Anzeige Fehler kommen.
--------------------------------------------------------------------------------------------------------------
Bilder Nvidia und AMD, des Einstellungsortes.
--------------------------------------------------------------------------------------------------------------
Videobearbeitung
Nach der Aufnahme kommt die Videobearbeitung.
Diese unterteielt sich in drei Schritte.
Decoding = Wenn wir ein Video beabeiten möchten, muss dieses entschlüsselt werden, so wie es auch ein Videoplayer machen muss.
[lexicon]Rendern[/lexicon] = Das [lexicon]Rendern[/lexicon] ist die Neuberechnung des Bildes. Das heißt sämtliche Effekte die wir nurtzen fallen hier drunter, genau so auch wenn wir eine Facecam eibauen, das Video in die richtige länge schneiden oder die [lexicon]Auflösung[/lexicon] und [lexicon]Fps[/lexicon] des Videos verändern.
Encoding = Das Encoding kommt nach dem [lexicon]Rendern[/lexicon], hier werden aus den beabeiteten Bilder wieder einen Videostream erzeugt und dieser wird wieder verschlüsselt.
Wir werden uns mit drei Möglichkeiten beschäftigen wie wir unsere Videobeabeitung machen können. Hier haben wir unterschiedliche Vor- und Nachteile die wir uns mal etwas genauer anschauen werden.
Die Bearbeitung mit einer [lexicon]NLE[/lexicon] (Videobeabeitunngsprogramm mit Timeline)
1. Decoding = Eine [lexicon]NLE[/lexicon] ist ein in sich geschlossenes Programm, das nur über Plugins erweiter werden kann. Hier haben wir eher weniger Einfluss auf das De- und Encoding. Dadurch können solche Programme sehr schnell hinterher hängen, da man die nicht einfach Nachrüsten kann.
Ein gutes Beispiel ist das High 4:4:4 Profil des [lexicon]x264[/lexicon].
Unter Windows gibt es aktuell keine [lexicon]NLE[/lexicon] die dieses Profil nativ unterstützt.
Wofür bräuchten wir dieses Profil?
Sollten wir zum Beispiel mit [lexicon]OBS[/lexicon] [lexicon]Lossless[/lexicon] (verlustfrei) Aufnahmen oder in YV24/RGB24 aufnehmen, muss der [lexicon]x264[/lexicon] dieses Profil schreiben, da er nur in diesem Profil mit diesen Parametern arbeiten darf.
Wir haben auch schon eine Weg gefunden um solche Dateien in [lexicon]NLE[/lexicon]'s zu laden, hierfür nehmen wir [lexicon]Avisynth[/lexicon] zur Hilfe. [lexicon]Avisynth[/lexicon] lädt dann diese Datei und erzeugt eine temporärte Datei die die [lexicon]NLE[/lexicon] dann laden kann. Dieser Weg kostet dem Pc aber wieder Leistung, was das Encoding am Ende verlangsamt.
2. Farbraumkonvertierung = Zusätzlich konvertieren manche [lexicon]NLE[/lexicon]'s den Farbraum der Aufnahme.
Zum Beispiel [lexicon]Sony Vegas[/lexicon].
Laden wir hier eine Aufnahme mit YV12 oder YV16 in die [lexicon]NLE[/lexicon], so wird diese immer in RGB32 konvertiert, damit die Effekte und Filter einfacher zu Programmieren sind. Dadurch das wir dann aber den Farbraum nach "oben" konvertieren vertlieren wir im ingesamten an Qualität, da er sowieso spätistens auf Youtube wieder "runter" konvertiert wird.
3. Encoding = Und zum Schluss der negativen Punkte kommen wir noch zum Encoding.
Sehr viele [lexicon]NLE[/lexicon]'s verwenden nur ein Bitraten basierendes Encoding und manche machen das sogar nur ein 1 Pass.
Bei einem [lexicon]Bitrate[/lexicon] basierenden Encoding geben wir eine [lexicon]Bitrate[/lexicon] an die das Video pro Sekunde haben soll. Hier durch heben wir eine genau Vorstellung wie groß die Datei am Ende werden wird die wir hochladen werden. Dadurch haben wir aber eine sehr schwankende Qualität im Video, da ein Standbild eine niedrigere [lexicon]Bitrate[/lexicon] braucht, als die riesige Explosion, wo wir uns dann auch noch selber bewegen.
Was ist jetzt aber noch 1 Pass und 2 Pass.
Das ist die Anzahl der Durchläufe.
Bei einem 2 Pass Encoding wird im ersten Durchlauf das Video analysiert und erst im zweiten Durchlauf wird das Video encoded. Wodurch wir hier schon an eine deutlich bessere Verteilung der [lexicon]Bitrate[/lexicon] bekommen als bei einem 1 Pass Encoding.
Weil, woher soll der [lexicon]Encoder[/lexicon] wissen wie er die [lexicon]Bitrate[/lexicon] verteilen soll, wenn er das Video vorher nicht analysiert hat?
Dank der VFW (Video für Windows) Schnittstelle können wir aber [lexicon]Encoder[/lexicon] nachreichen. Hier steht und dann der [lexicon]x264vfw[/lexicon] zur Verfügung. Dieses [lexicon]x264[/lexicon] ist aber nur eine Notfalllösung, damit wir direkt in der [lexicon]NLE[/lexicon] einen "ordentlichen" [lexicon]Encoder[/lexicon] nutzen können.
Warum ist es nur ein Notfalllösung?
Da [lexicon]x264vfw[/lexicon] ist nur eine Notfallösuung, da er bestimmte Mechaniken des [lexicon]x264[/lexicon] [lexicon]CLI[/lexicon] nicht nutzen kann, wodurch er schlechter und langsamer encoded. Sollte man dann noch den [lexicon]AVI[/lexicon] Hack nutzen kann es schnell man zur Asynchronität zwischen Video und Audio kommen. Zudem wird der [lexicon]x264vfw[/lexicon] langsamer geupdatet als der [lexicon]x264[/lexicon] [lexicon]CLI[/lexicon], wodurch er von der Version immer hinterher hängt.
Warum sollte ich aber [lexicon]x264[/lexicon] nutzen, ob VFW oder [lexicon]CLI[/lexicon]?
Weil der [lexicon]x264[/lexicon] das [lexicon]CRF[/lexicon] (constant rate faktor) Encoding beherrscht.
Was ist das [lexicon]CRF[/lexicon] Encoding?
Beim [lexicon]CRF[/lexicon] Encoding geben wir keine [lexicon]Bitrate[/lexicon] mehr an, sondern wir geben die Qualität an die wir haben möchten, der Standart hierbei ist 23 und unter 18 zu gehen lohnt sich nicht mehr wirklich.
Dadurch das wir keine [lexicon]Bitrate[/lexicon] angeben haben wir einen sehr dynamischen Verlauf der [lexicon]Bitrate[/lexicon] von wenigen Bits bis hin zu mehreren hundertausend.
Immer so viel wie das Video braucht um die angegeben Qualität zu erreichen.
Dadurch haben wir bei gleicher Dateigröße eine deutlich bessere Qualität.
Und wir müssen uns keine Gedanken darüber machen wie komplex das Video ist, ob ein Crysis oder ein Pokemon, mit der gleichen Einstellung erhalten wir die gleiche Qualität.
Zudem können wir beim [lexicon]x264[/lexicon] deutlich besser auf die Geschwindigkeit des Encoders Einfluss nehmen.
Als Beispiel:
Wir hatten jemanden mit einem alten Altohn 3 Kerner von AMD, hier hatte er mit den Encodern von [lexicon]Sony Vegas[/lexicon] 7 Stunden für ein 20 Minuten gebraucht, mit dem [lexicon]x264[/lexicon] und angespassten Einstellungen war es nur noch 1 Stunde.
4. Die Bearbeitung = Die Vorteile eine [lexicon]NLE[/lexicon] sind sehr leicht zu erkennen, die einfache Bearbeitung.
Daurch das wir eine Timeline haben können wir das Video hin und her schieben, können uns unsere Schnittpunkte sehr einfach raussuchen.
Haben für Effekte, Filter, usw eine grafische Oberfläche wo wir alles einstellen.
Wir können nicht nur in dem Vorschaufenster und das Ergenis anschauen, sondern auch direkt darin arbeiten.
Das heißt die Facecam an die richtige Positon setzen, Texte in der Größe anpassen und da hinsetzen wo sie hin sollen und sehen dabei direkt wie es dann im Verhältnis wirkt.
Wir haben in der Timeline mehre Spuren für Ton und Video, wodurch wir uns übersichtlicher sortieren können.
[lexicon]Avisynth[/lexicon] und [lexicon]MeGui[/lexicon]
Als nächstes haben wir die Möglichkeit der reinen Bearbeitung mit [lexicon]Avisynth[/lexicon] und dem anschließenden Encoding mit [lexicon]Megui[/lexicon].
[lexicon]Avisynth[/lexicon] ist im ersten ein [lexicon]Frameserver[/lexicon], ein [lexicon]Frameserver[/lexicon] der [lexicon]rendern[/lexicon] kann.
Das heißt [lexicon]Avisynth[/lexicon] kann nicht nur Frames weiter geben, sondern diese auch noch bearbeiten.
Der größte Unterschied ist das wir keine Timeline haben und unsere gesamte Videobearbeitung programmieren.
Das heißt wir müssen die Befehle wissen und diese anwenden können.
Dadurch wird die Bearbeitung etwas schwieriger, da wir nicht direkt sehen wie sich das was mir machen auswirkt.
Deswegen müssen wir genau wissen was der Befehl macht und was wir am Ende raushaben wollen.
Das ist aber auch der einzige Wichtige Nachteil.
Dafür haben wir aber eine deutlich bessere Kontrolle.
Das heißt wir müssen nicht nur mit den mitgelieferten Befehlen arbeiten, sondern können durch verschiedene [lexicon]Avisynth[/lexicon] Versionen und Plugins die erweitern.
Decoden: Bei [lexicon]Avisynth[/lexicon] sind wir nicht auf das DirectShow System von Windows angewiesen, sondern wir können auf verschiedene Laderoutienen zurück greifen. Dadurch können wir die verschiedenen [lexicon]Container[/lexicon] über die beste Methode laden. Gerade dadurch können wir auch sehr einfach beschädigte Aufnehmen rettern, weil wir Ledaeroutinen nutzen können die den Header nicht brauchen.
Videobearbeitung: Normalerweise müssen wir die Skripte erst schreiben, aber der Sagras hat den Sagras Scriptmaker entwickelt. Dadurch wird die Erstellung der Skripte deutlich einfacher, da wir eine grafische Oberfläche für die Erstellung der Skrtipte haben. Hier können wir dann einfache Bearbeitungen machen, schneiden, Übergänge, verändern der [lexicon]Auflösung[/lexicon] und [lexicon]Fps[/lexicon] und noch vieles mehr. Zusätzlich sitze wir auch aktuell an schwierigere Bearbeitungen um diese zu vereinfachen.
Encoding: Für das Encoding nutzen wir [lexicon]MeGui[/lexicon]. [lexicon]Megui[/lexicon] ist eine grafische Oberfläche mit der wir den [lexicon]x264[/lexicon] [lexicon]CLI[/lexicon] ansprechen können und dieses dann sehr einfach auf unsere Bedürfnisse anpassen.
[lexicon]Frameserver[/lexicon] ([lexicon]NLE[/lexicon] -> [lexicon]Frameserver[/lexicon] -> [lexicon]Avisynth[/lexicon] -> [lexicon]MeGui[/lexicon])
Als letztes kommen wir zur Nutzung eines Frameservers. Mit dieser Methode können wir eine [lexicon]NLE[/lexicon] mit [lexicon]Avisynth[/lexicon] und [lexicon]MeGui[/lexicon] verbinden.
Welchen [lexicon]Frameserver[/lexicon] wir nutzen können und ob wir überhaupt einen nutzen können hängt von der verwendeten [lexicon]NLE[/lexicon] ab.
Beispiele:
Den [lexicon]Debugmode Frameserver[/lexicon] können wir mit Sony Vergas, Sony Movie Studio und [lexicon]Adobe[/lexicon] Premiere Pro (außer CC) nutzen.
Den Advance [lexicon]Frameserver[/lexicon] nutzen für [lexicon]Adobe[/lexicon] Premiere Pro CC, da der Debugmode Framserver hier für Probleme sorgt.
Wenn wir einen [lexicon]Frameserver[/lexicon] nutzen haben wir die leichte Bearbeitung einer [lexicon]NLE[/lexicon] und können trotzdem auf die besseren Resizer von [lexicon]Avisynth[/lexicon] und das deutlich bessere Encoding von [lexicon]MeGui[/lexicon] zugreifen.
Youtube
Nach der Videobearbeitung kommen wir zu dem was sich direkt auf Youtube mit unseren Video abspielt. (Ihr habt gedacht das davor war trocken? Jetzt fängt es erst an trocken zu werden…)
Jeder kennt es, man schaut sich ein Video auf Youtube an und wundert sich über diese “Unschärfe”. Es ist keine Unschärfe, sondern es sind Macroblöcke. Diese Blöcke entstehen wenn die [lexicon]Bitrate[/lexicon] für das Video nicht mehr ausreichend war. Deswegen sehen wir dieses Blöcke gerade bei Spielevideos, da diese durch die ganzen feinen Texturen und Bewegungen sehr komplexe Videos erzeugen. Verwechselt aber bitte nicht schöne Grafik mit komplexen Videos. Zum Beispiel [lexicon]Minecraft[/lexicon] , gerade mit standard Texturenpaket, ist ein der Spiele was sehr komplexe Videos erzeugt.
Um die Videoqualität auf Youtube zu erhöhen muss man verstehen wie Youtube arbeitet, da Youtube alle hochgeladenen Video neu codiert. Wie diese codiert werden hängt davon ab wie die [lexicon]Auflösung[/lexicon] und [lexicon]Fps[/lexicon] der Videos ist.Dabei geht es immer nach dem gleichen Verfahren, ob großer oder kleiner Youtuber.
Als erstes haben wir einen Constant Rate Faktor ([lexicon]CRF[/lexicon]), da dieser ja nach Komplexität des Videos sehr hohe Bitraten erzeugen kann, wird er durch eine maximal durchschnittlichen [lexicon]Bitrate[/lexicon] im Zaum gehalten. Dieser Wert verändert sich sich mit den verschiedenen Auflösungsstufen und [lexicon]Fps[/lexicon] und ist für uns der wichtigste Wert, da er die Limitierung unserer Videoqualität darstellt. Zum Schluss haben wir noch einen Constand Quantizer (QP), dieser sorgt dafür das die Videoqualität nicht unter einen bestimmten Wert sinkt. Es sieht schrecklich aus wenn der QP-Wert greift und eine höhere [lexicon]Bitrate[/lexicon] freigeben muss.
Liste der vbv-max
bis 30 [lexicon]Fps[/lexicon] 41 - 60 [lexicon]Fps[/lexicon]
720p 2.000 kbit/s ([lexicon]H.264[/lexicon]) 3.000 kbit/s ([lexicon]H.264[/lexicon])
1080p 4.000 kbit/s ([lexicon]H.264[/lexicon]) 5.000 kbit/s ([lexicon]H.264[/lexicon])
1440p 10.000 kbit/s ([lexicon]H.264[/lexicon]) 15.000 kbit/s ([lexicon]VP9[/lexicon])
2160p 22.000 kbit/s ([lexicon]H.264[/lexicon]) ~ 34.000 kbit/s ([lexicon]VP9[/lexicon])
Wie man jetzt sehen kann haben wir von der [lexicon]Fps[/lexicon] her 2 Encoding Stufen. Einmal bis 30 [lexicon]Fps[/lexicon] und einmal das High Framerate ([lexicon]HFR[/lexicon]), dieses geht von 41-60 [lexicon]Fps[/lexicon]. Zusätzlich kann man sehen das gerade die 1440p und 2160p sehr hohe maximal durchschnittliche Bitraten. Dadurch erzielen wir gerade bei diesen Stufen sehr gute Videoqualität. Einen großen und sehr entscheidenden Punkt gibt es bei den 1440p/2160@[lexicon]HFR[/lexicon] Stufen zu beachten. Diese sind nämlich nur in [lexicon]VP9[/lexicon] vorhanden. Der [lexicon]Codec[/lexicon] [lexicon]VP9[/lexicon] komprimiert die Videos deutlich stärker, braucht dafür aber auch 10-20x so lange. Dadurch haben wir bei der 1440p Stufe die 15.000 kbit/s hat, wenn man es mit [lexicon]H.264[/lexicon] vergleich, etwa eine [lexicon]Bitrate[/lexicon] von 20.000 kbit/s, was die 2160p Stufe bedeutet, aber das nur mit etwa 44,5% der Pixel, was zu einer extrem Steigerung der Qualität führt.
Zusätzlich wird das Encoding der 1440p und 2160p Stufen nicht erst durch die [lexicon]Auflösung[/lexicon] von 2560x1440 bzw 3840x2160, sondern Bereits durch eine [lexicon]Auflösung[/lexicon] von 2048x1152 und 3200x1800 ausgelöst. Wodurch wir im Fall der 1440p Stufe noch mal etwas über ⅓ an Pixel sparen.
-------------------------------------------------------------------------------------------------------
Vergleichsbilder
-------------------------------------------------------------------------------------------------------