Bessere Videoqualität auf Youtube [WiP] | Gaming Tutorial-Reihe

Ich brauche deine Hilfe, um den Fortbestand des LetsPlayForums zu sichern: Mehr Informationen findest du hier!
  • 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 [email protected]@RGB24 [lexicon]Lossless[/lexicon] Aufnahme zwei Videos erstellt.
    Das erste Video hat dabei [email protected]@YV12 und ist [lexicon]Lossless[/lexicon].
    Das zweite Video hatte [email protected]@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/[email protected][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
    -------------------------------------------------------------------------------------------------------

  • Du könntest noch NV12 hinzufügen (Müsste 4:2:0 sein, so wie ich das verstanden habe ist da die Reihenfolge der bytes nur anders und NV12 ist der default für [lexicon]x264[/lexicon] und am schnellsten - aber keine Gewähr zu dieser Aussage)


    Premiere Pro CC 2015 sollte mit dem 4:4:4 Profil von [lexicon]x264[/lexicon] (lossles mode) nun klarkommen.
    Hatte jedenfalls keine Probleme das zu verwenden. Bei 2014 ging es noch nicht.

  • Du könntest noch NV12 hinzufügen (Müsste 4:2:0 sein, so wie ich das verstanden habe ist da die Reihenfolge der bytes nur anders und NV12 ist der default für [lexicon]x264[/lexicon] und am schnellsten - aber keine Gewähr zu dieser Aussage)


    Er könnte auch YUV 4:0:0 und 4:1:1 hinzufügen xD Das ist aber ohnehin irrelevant. Genauso wie als NV12 bei YUV 4:2:0 noch zusätzlich stehen würde xD
    Darum ging es ja auch gar nicht ;D


    Premiere Pro CC 2015 sollte mit dem 4:4:4 Profil von [lexicon]x264[/lexicon] (lossles mode) nun klarkommen.
    Hatte jedenfalls keine Probleme das zu verwenden. Bei 2014 ging es noch nicht.


    Oh, mal ne Ausnahme? xD
    Hmm... weiß aber nicht ob sich nun jeder Premiere Pro CC 2015 holen wird deswegen xD


    Sry, wenn das wieder mal falsch rüberkommt von mir. Du musst aber zugeben das diese Software zum einen sehr schön teuer ist, zum zweiten es mal ein wenig was richtig macht und es zu einer Ausnahme nun macht.


    Wieviele Schnittprogramme können wohl das H264 Profil High 4:4:4 laden bei Verlustfreien Inhalt?

    ^^

    Da bleiben nicht viele xD

  • Knie Nv12 geht es darum das [lexicon]OBS[/lexicon] es nutzt.


    Was das mit [lexicon]Adobe[/lexicon] angeht würde ich gerne etwas warten, da ich glaube das der [lexicon]H.264[/lexicon] in einer [lexicon]Avi[/lexicon] lag, was eigentlich Komplet bekloppt wäre xD

  • @Sagaras
    Es war auch nur als Hinweis gedacht, da dies eine Art FAQ ist.
    NV12, weil es Standardmäßig in [lexicon]OBS[/lexicon]-MP eingestellt ist und ich mir auch die Frage stellte, was das ist. (Als Ergänzung zu "YV12, IYUV, I420")
    Und Premiere 2015, weil immer gesagt wird, Premiere kann das 4:4:4 Profil nicht - was ja nun mit der aktuellen Version nicht mehr stimmt.


    Was das mit [lexicon]Adobe[/lexicon] angeht würde ich gerne etwas warten, da ich glaube das der [lexicon]H.264[/lexicon] in einer [lexicon]Avi[/lexicon] lag, was eigentlich Komplet bekloppt wäre xD

    ne geht auch im [lexicon]mp4[/lexicon] oder mov [lexicon]container[/lexicon].


    [lexicon]MKV[/lexicon] kann [lexicon]adobe[/lexicon] nicht, weil es "kein Industrie Standard ist" wie sie sagen.... :-|

  • Knie Nv12 geht es darum das [lexicon]OBS[/lexicon] es nutzt.


    Da du hier auch direkt Aufnahmeprogramme ansprichst xD
    Ich glaube dann fehlt dir auch für [lexicon]Fraps[/lexicon]: bgr24 und yuvj420p

    ^^


    Oder willste das ich dir noch sämtliche Teile nenne die noch irgendwo drinstecken?

    ^^


    Die interessieren doch jetzt gar nicht xD Ich hab die gestern zu deinen Text nur hinzugefügt, damit man nur ein paar Beispiele hat. Ich wollte gewiss nicht die gesammte Palette hinschreiben die es gibt

    ^^
  • und NV12 ist der default für [lexicon]x264[/lexicon]


    YV12 ist standard. Wenn dann weicht [lexicon]OBS[/lexicon] davon ab.


    Premiere Pro CC 2015 sollte mit dem 4:4:4 Profil von [lexicon]x264[/lexicon] (lossles mode) nun klarkommen.
    Hatte jedenfalls keine Probleme das zu verwenden. Bei 2014 ging es noch nicht.


    Das heißt die haben es nach mind. 12 Jahren Existenz von [lexicon]H.264[/lexicon] geschafft einen Bruchteil davon mehr zu unterstützen? Applaus!

  • Die interessieren doch jetzt gar nicht xD Ich hab die gestern zu deinen Text nur hinzugefügt, damit man nur ein paar Beispiele hat. Ich wollte gewiss nicht die gesammte Palette hinschreiben die es gibt


    Ich finde es schon nützlich. Alternativ fände ich eine einzelne FAQ/Wiki Seite ganz nützlich.


    YV12 ist standard. Wenn dann weicht [lexicon]OBS[/lexicon] davon ab.

    Intern wird nv12 verwendet, da es schneller ist
    https://mailman.videolan.org/p…vel/2010-July/007551.html
    das habe ich auch im doom9 forum irgendwo gelesen. Da müsste ich den Link aber nochmal raussuchen.

  • Ich finde es schon nützlich. Alternativ fände ich eine einzelne FAQ/Wiki Seite ganz nützlich.


    Kann man ja alles machen. Aber gehört nicht hierher jetzt

    ^^


    Hättest den Text gestern sehen sollen. Da stand dann für YUV 4:4:4 nur YV24, für YUV 4:2:2 stand nur YV16 und für YUV 4:2:0 stand nur YV12 dar.
    Damit man aber ein paar Beispiele hat die noch dazugehören, habe ich da gestern halt ein paar ergänzt. Ich wollte gewiss nicht die gesammte Palette an Kombinationen da hinschreiben.


    Weil denn hätte ich gewiss auch IMC 1-4 nennen können die YUV 4:2:0 sind, wobei IMC 1 und 3 16bpp haben und die anderen beiden nur 12bpp.
    Genauso wie ich bei YUV 4:4:4 noch AYUV hätte hinschreiben können.
    Oder ich hätte den Unterschied zwischen RGBA und RGB32 auch nennen können. Genauso wie ich die [lexicon]Fraps[/lexicon] eigenen Formate hätte nennen können.
    Ich habe die schon alle bewusst rausgelassen, da ich gedacht habe das ein paar Beispiele reichen würden.

    ^^
  • 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.


    ergo nehmen wir z.B. in 1080pXXfps auf, vor dem upload encoden(?) wir auf 1152p60fps und erhalten automatisch etwas bessere quali auf youtube als wenn wir direkt die 1080pXXfps aufnahme hochladen?


    zum Thema [lexicon]NLE[/lexicon]:


    ich kann mir kaum vorstellen das Videos wie diese (schnitt ist recht einfach, kaum effekte, ein paar bilder hinzu) ohne [lexicon]NLE[/lexicon] gemacht worden sind, da kommt (wenn überhaupt) wohl eher der [lexicon]Frameserver[/lexicon] zum Einsatz? Aber mal rein aus Interesse, wäre sowas mit [lexicon]MeGui[/lexicon] möglich?


    Zitat

    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.


    Das bedeutet also, das wenn man ein paar Abstriche macht, wie zb. die Geschwindigkeit, doch per [lexicon]NLE[/lexicon] ordentliche Videos produzieren kann. Wie sieht es mit der Bildqualtität und Dateigröße aus, wenn man den vfw benutzt?


    Ansonsten sehr toll gemacht! Danke dafür!

  • ergo nehmen wir z.B. in 1080pXXfps auf, vor dem upload encoden(?) wir auf 1152p60fps und erhalten automatisch etwas bessere quali auf youtube als wenn wir direkt die 1080pXXfps aufnahme hochladen?


    Also...
    [lexicon]Rendern[/lexicon] = neu Berechnung des Bildes, Filter Effekt, usw... fallen hier drunter.
    Encoding = Aus den einzelnen Bildern wird wieder ein Videostream erzeugt und dieser wird dann wieder verschlüsselt.
    Die Qualität ist nicht nur etwas besser, die Qualität steigt extrem an, weil wir von 5.000 kbit/s ([lexicon]H.264[/lexicon]) auf 15.000 kbit/s ([lexicon]VP9[/lexicon]) steigen, solange vorher der [lexicon]CRF[/lexicon] nicht begrenzt.
    Wir haben mit [lexicon]Avisynth[/lexicon] auch Resizer zum hochskallieren, die auf 480p Videos extrem gute 1152p Video erzeugen können.


    ich kann mir kaum vorstellen das Videos wie diese (schnitt ist recht einfach, kaum effekte, ein paar bilder hinzu) ohne [lexicon]NLE[/lexicon] gemacht worden sind, da kommt (wenn überhaupt) wohl eher der [lexicon]Frameserver[/lexicon] zum Einsatz? Aber mal rein aus Interesse, wäre sowas mit [lexicon]MeGui[/lexicon] möglich?


    Das Video was du da hattest ist jetzt sogar sehr einfach zu machen ohne [lexicon]NLE[/lexicon] zu machen. Nur das wird dann in einem eigene Thread nochmal genau drauf eingegangen.
    Weil das waren nur ein paar Bilder, Texte und Video in Video.
    Das letzte ist nichts anderes als würde man eine Facecam mit einbauen.


    Das bedeutet also, das wenn man ein paar Abstriche macht, wie zb. die Geschwindigkeit, doch per [lexicon]NLE[/lexicon] ordentliche Videos produzieren kann. Wie sieht es mit der Bildqualtität und Dateigröße aus, wenn man den vfw benutzt?


    Man bekommt die gleiche Bildqualität, weil ein [lexicon]CRF[/lexicon] Wert ein [lexicon]CRF[/lexicon] Wert ist und dabei ist es egal ob vfw oder [lexicon]cli[/lexicon].
    Wie genau dadurch die Dateigröße steigt kann ich jetzt nicht sagen, da ich dazu noch keinen genauen Test gemacht habe.
    Aber man hat kein 10 Bit Encoding und gerade durch das 10 Bit Encoding kann man das [lexicon]Banding[/lexicon] auf Youtube deutlich reduzieren.
    Zusätzlich kann man keine Stapelverarbeitung machen, das heißt wir können nicht 10 Videos fertig machen und in der Zeit wo wir nicht am Pc sind hintereinander durchjagen lassen.
    Und wir müssen halt auf die Resizer von den [lexicon]NLE[/lexicon]'s zurückgreifen die doch sehr bescheiden sind.


  • Man sollte also im bestmöglichen Farbraum aufnehmen, falls möglich...
    Beim [lexicon]Encodieren[/lexicon] sollte man je nach [lexicon]Auflösung[/lexicon] auch die "treffende" Farbmatrix auswählen. (von 720p bis 1152p wäre das .709)
    Richtig?

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!