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

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

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

      Anzeige
      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?

      Bitrate = Wenn wir unser Aufnahme verlustfrei aufnehmen, können wir hier viel Qualität erhalten.
      Dabei kommt es auf den verwendeten Codec an und wie dieser Eingestellt wird.
      Hierbei gibt es drei Arten von Codecs.

      1. Lossless = Die erste Art ist der Lossless Codec, hier drunter Fallen die Codecs UT Video, MagicYUV, Lagarith Lossless Codec und der Codec von Fraps.
      Diese Codecs können nur verlustfrei Aufnehmen.

      2. Lossy = Die zweite Art sind die Lossy Codecs, darunter Fallen Codecs wie MJPG, der Codec von Miralles Action!, Nvidias NVENC wenn man ihn mit Shadowplay nutzt.
      Diese Codecs können nur verlustbehaftet aufnehmen, wodurch wir dann bei der Aufnahme bereits Qualität verlieren.

      3. Lossless/Lossy = Die dritte Art sind die Codecs die man so einstellen kann das sie Lossless oder Lossy aufnehmen, das beste Beispielt hier ist der Encoder x264 des Codecs H.264.
      Diesen können wir zwar mit dem Parameter qp=0 Lossless einstellen, dafür haben wir aber dann das High 4:4:4, wodurch viele NLE’s (Videobearbeitungsprogramme mit Timeline) diese Aufnahme dann wieder nicht öffnen könne.

      Tutorial = Bearbeitung von Lets Plays ohne Timeline:
      Kommt noch!

      Vergleich:
      Lossless:
      abload.de/img/720plossless68umt.png
      Lossy 50.000 kbit/s:
      abload.de/img/720p50.000kbitsqjumh.png

      Für diesen Vergleich habe ich aus einer 720p@60@RGB24 Lossless Aufnahme zwei Videos erstellt.
      Das erste Video hat dabei 720p@60@YV12 und ist Lossless.
      Das zweite Video hatte 720p@60@YV12 und wurde so gut wie möglich auf eine Bitrate von 50.000 kbit/s beschränkt um die Aufnahme Qualität von Shadowplay zu zeigen.
      Damit mir keiner vorwerfen kann, dass ich beim ersten Lossy 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 GOP 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 Auflösung 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 Lagarith Lossless Codec nicht nutzen, da er die Fabmatrix 601 benutzt, sollte man aber mit dem Lagarith Lossless Codec in RGB aufnehmen hat man das Problem nicht, da RGB immer alle Farben darstellen kann.
      Bei UT Video und MagicYUV 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 Grafikkarte 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 Grafikkarte 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.

      Rendern = Das Rendern 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 Auflösung und Fps des Videos verändern.

      Encoding = Das Encoding kommt nach dem Rendern, 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 NLE (Videobeabeitunngsprogramm mit Timeline)
      1. Decoding = Eine NLE 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 x264.
      Unter Windows gibt es aktuell keine NLE die dieses Profil nativ unterstützt.
      Wofür bräuchten wir dieses Profil?
      Sollten wir zum Beispiel mit OBS Lossless (verlustfrei) Aufnahmen oder in YV24/RGB24 aufnehmen, muss der x264 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 NLE's zu laden, hierfür nehmen wir Avisynth zur Hilfe. Avisynth lädt dann diese Datei und erzeugt eine temporärte Datei die die NLE dann laden kann. Dieser Weg kostet dem Pc aber wieder Leistung, was das Encoding am Ende verlangsamt.

      2. Farbraumkonvertierung = Zusätzlich konvertieren manche NLE's den Farbraum der Aufnahme.
      Zum Beispiel Sony Vegas.
      Laden wir hier eine Aufnahme mit YV12 oder YV16 in die NLE, 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 NLE's verwenden nur ein Bitraten basierendes Encoding und manche machen das sogar nur ein 1 Pass.
      Bei einem Bitrate basierenden Encoding geben wir eine Bitrate 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 Bitrate 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 Bitrate bekommen als bei einem 1 Pass Encoding.
      Weil, woher soll der Encoder wissen wie er die Bitrate verteilen soll, wenn er das Video vorher nicht analysiert hat?

      Dank der VFW (Video für Windows) Schnittstelle können wir aber Encoder nachreichen. Hier steht und dann der x264vfw zur Verfügung. Dieses x264 ist aber nur eine Notfalllösung, damit wir direkt in der NLE einen "ordentlichen" Encoder nutzen können.
      Warum ist es nur ein Notfalllösung?
      Da x264vfw ist nur eine Notfallösuung, da er bestimmte Mechaniken des x264 CLI nicht nutzen kann, wodurch er schlechter und langsamer encoded. Sollte man dann noch den AVI Hack nutzen kann es schnell man zur Asynchronität zwischen Video und Audio kommen. Zudem wird der x264vfw langsamer geupdatet als der x264 CLI, wodurch er von der Version immer hinterher hängt.

      Warum sollte ich aber x264 nutzen, ob VFW oder CLI?
      Weil der x264 das CRF (constant rate faktor) Encoding beherrscht.
      Was ist das CRF Encoding?
      Beim CRF Encoding geben wir keine Bitrate 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 Bitrate angeben haben wir einen sehr dynamischen Verlauf der Bitrate 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 x264 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 Sony Vegas 7 Stunden für ein 20 Minuten gebraucht, mit dem x264 und angespassten Einstellungen war es nur noch 1 Stunde.

      4. Die Bearbeitung = Die Vorteile eine NLE 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.

      Avisynth und MeGui

      Als nächstes haben wir die Möglichkeit der reinen Bearbeitung mit Avisynth und dem anschließenden Encoding mit Megui.

      Avisynth ist im ersten ein Frameserver, ein Frameserver der rendern kann.
      Das heißt Avisynth 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 Avisynth Versionen und Plugins die erweitern.

      Decoden: Bei Avisynth 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 Container ü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 Auflösung und Fps und noch vieles mehr. Zusätzlich sitze wir auch aktuell an schwierigere Bearbeitungen um diese zu vereinfachen.

      Encoding: Für das Encoding nutzen wir MeGui. Megui ist eine grafische Oberfläche mit der wir den x264 CLI ansprechen können und dieses dann sehr einfach auf unsere Bedürfnisse anpassen.

      Frameserver (NLE -> Frameserver -> Avisynth -> MeGui)
      Als letztes kommen wir zur Nutzung eines Frameservers. Mit dieser Methode können wir eine NLE mit Avisynth und MeGui verbinden.
      Welchen Frameserver wir nutzen können und ob wir überhaupt einen nutzen können hängt von der verwendeten NLE ab.

      Beispiele:
      Den Debugmode Frameserver können wir mit Sony Vergas, Sony Movie Studio und Adobe Premiere Pro (außer CC) nutzen.
      Den Advance Frameserver nutzen für Adobe Premiere Pro CC, da der Debugmode Framserver hier für Probleme sorgt.

      Wenn wir einen Frameserver nutzen haben wir die leichte Bearbeitung einer NLE und können trotzdem auf die besseren Resizer von Avisynth und das deutlich bessere Encoding von MeGui 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 Bitrate 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 Minecraft , 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 Auflösung und Fps 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 (CRF), da dieser ja nach Komplexität des Videos sehr hohe Bitraten erzeugen kann, wird er durch eine maximal durchschnittlichen Bitrate im Zaum gehalten. Dieser Wert verändert sich sich mit den verschiedenen Auflösungsstufen und Fps 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 Bitrate freigeben muss.

      Liste der vbv-max
      bis 30 Fps 41 - 60 Fps
      720p 2.000 kbit/s (H.264) 3.000 kbit/s (H.264)
      1080p 4.000 kbit/s (H.264) 5.000 kbit/s (H.264)
      1440p 10.000 kbit/s (H.264) 15.000 kbit/s (VP9)
      2160p 22.000 kbit/s (H.264) ~ 34.000 kbit/s (VP9)

      Wie man jetzt sehen kann haben wir von der Fps her 2 Encoding Stufen. Einmal bis 30 Fps und einmal das High Framerate (HFR), dieses geht von 41-60 Fps. 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@HFR Stufen zu beachten. Diese sind nämlich nur in VP9 vorhanden. Der Codec VP9 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 H.264 vergleich, etwa eine Bitrate 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 Auflösung von 2560x1440 bzw 3840x2160, sondern Bereits durch eine Auflösung 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 x264 und am schnellsten - aber keine Gewähr zu dieser Aussage)

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

      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 x264 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

      Schauerland schrieb:

      Premiere Pro CC 2015 sollte mit dem 4:4:4 Profil von x264 (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
    • Anzeige
      @Sagaras
      Es war auch nur als Hinweis gedacht, da dies eine Art FAQ ist.
      NV12, weil es Standardmäßig in OBS-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.

      GelberDrache92 schrieb:

      Was das mit Adobe angeht würde ich gerne etwas warten, da ich glaube das der H.264 in einer Avi lag, was eigentlich Komplet bekloppt wäre xD
      ne geht auch im mp4 oder mov container.

      MKV kann adobe nicht, weil es "kein Industrie Standard ist" wie sie sagen.... :-|
    • GelberDrache92 schrieb:

      Knie Nv12 geht es darum das OBS es nutzt.

      Da du hier auch direkt Aufnahmeprogramme ansprichst xD
      Ich glaube dann fehlt dir auch für Fraps: 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 ^^
    • Schauerland schrieb:

      und NV12 ist der default für x264

      YV12 ist standard. Wenn dann weicht OBS davon ab.

      Schauerland schrieb:

      Premiere Pro CC 2015 sollte mit dem 4:4:4 Profil von x264 (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 H.264 geschafft einen Bruchteil davon mehr zu unterstützen? Applaus!
      Aktuelle Projekte/Videos




      Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
      Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7
    • Sagaras schrieb:

      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.

      De-M-oN schrieb:

      YV12 ist standard. Wenn dann weicht OBS davon ab.
      Intern wird nv12 verwendet, da es schneller ist
      mailman.videolan.org/pipermail…vel/2010-July/007551.html
      das habe ich auch im doom9 forum irgendwo gelesen. Da müsste ich den Link aber nochmal raussuchen.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Schauerland ()

    • Schauerland schrieb:

      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 Fraps 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. ^^
    • GelberDrache92 schrieb:

      Zusätzlich wird das Encoding der 1440p und 2160p Stufen nicht erst durch die Auflösung von 2560x1440 bzw 3840x2160, sondern Bereits durch eine Auflösung 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 NLE:

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

      Dank der VFW (Video für Windows) Schnittstelle können wir aber Encoder nachreichen. Hier steht und dann der x264vfw zur Verfügung. Dieses x264 ist aber nur eine Notfalllösung, damit wir direkt in der NLE einen "ordentlichen" Encoder nutzen können.

      Warum ist es nur ein Notfalllösung?

      Da x264vfw ist nur eine Notfallösuung, da er bestimmte Mechaniken des x264 CLI nicht nutzen kann, wodurch er schlechter und langsamer encoded. Sollte man dann noch den AVI Hack nutzen kann es schnell man zur Asynchronität zwischen Video und Audio kommen. Zudem wird der x264vfw langsamer geupdatet als der x264 CLI, 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 NLE 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!
    • SiggySmilez schrieb:

      Aber mal rein aus Interesse, wäre sowas mit MeGui möglich?


      avisynth.nl/index.php/Internal_filters
      avisynth.nl/index.php/External_filters

      Also da geht eig. alles was eine Timeline NLE auch kann.
      Aktuelle Projekte/Videos




      Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
      Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7
    • SiggySmilez schrieb:

      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...
      Rendern = 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 (H.264) auf 15.000 kbit/s (VP9) steigen, solange vorher der CRF nicht begrenzt.
      Wir haben mit Avisynth auch Resizer zum hochskallieren, die auf 480p Videos extrem gute 1152p Video erzeugen können.

      SiggySmilez schrieb:

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

      Das Video was du da hattest ist jetzt sogar sehr einfach zu machen ohne NLE 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.

      SiggySmilez schrieb:

      Das bedeutet also, das wenn man ein paar Abstriche macht, wie zb. die Geschwindigkeit, doch per NLE 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 CRF Wert ein CRF Wert ist und dabei ist es egal ob vfw oder cli.
      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 Banding 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 NLE's zurückgreifen die doch sehr bescheiden sind.
    • GelberDrache92 schrieb:

      Aber man hat kein 10 Bit Encoding und gerade durch das 10 Bit Encoding kann man das Banding auf Youtube deutlich reduzieren.


      Vor allem aber lokal. Denn 10bit haste kein Banding mehr. Bei 8bit durchaus. :)
      Aktuelle Projekte/Videos




      Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
      Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7
    • Es sollte ja aber klar sein, das es auch einen positiven Effekt für Youtube hat, wenn die Quelle besser ist^^
      Aktuelle Projekte/Videos




      Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
      Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7
    • GelberDrache92 schrieb:

      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 Auflösung 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.


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