MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

  • So ich komm nochmal auf das Thema zurück mit:
    "Wir sollen doch am besten Motion Blure vom Spiel benutzen"


    Abgesehen von Spielen wo das [lexicon]Motion Blur[/lexicon] einfach nur übertrieben ist.
    Müsste nicht eine Aufnahme ohne [lexicon]Motion Blur[/lexicon] am Ende besser aus sehen als eine mit?
    Gerade im Bezug aufs [lexicon]Hochskalieren[/lexicon].
    Ich würde einfach mal behaupten das ein Bild das kein [lexicon]Motion Blur[/lexicon] hat sauberer hochskaliert werden müsste als eins mit Motion Blure.
    Weil ein Bild mit [lexicon]Motion Blur[/lexicon] ja bereits verwaschen ist und durch die Hochskalierung müsste dieser Effekt doch noch verschlimmert werden, oder?

  • Ich würde einfach mal behaupten das ein Bild das kein [lexicon]Motion Blur[/lexicon] hat sauberer hochskaliert werden müsste als eins mit Motion Blure.


    Exakt. Es wäre sauberer. ABER... bedenke das wenn es [lexicon]Motion Blur[/lexicon] vor der Skalierung hat es weitaus besser komprimierbarer ist nach der Skalierung.


    Ein [lexicon]Motion Blur[/lexicon] behandeltes Video hat ja bereits den Effekt drin das Bewegungen verschwimmen. Um diesen Effekt nicht scharfkantik hochzuskalieren wird Spline16 oder Spline100 genommen um es sanft hochzuskalieren. Bedeutet: Der MB Effekt wird besser, da die genannten Skalierer diesen Effekt ein wenig verstärken. Was bleibt ist ein komprimierbareres Bild als vorher. Weniger Bitratenverbrauch, weniger Pixelbrei, mehr Bildqualität.


    Weil ein Bild mit [lexicon]Motion Blur[/lexicon] ja bereits verwaschen ist und durch die Hochskalierung müsste dieser Effekt doch noch verschlimmert werden, oder?


    Verschlimmern? Jein. Er trägt ja positiv dazu bei. Die Skalierung macht den [lexicon]GPU[/lexicon] generierten MB viel weicher, da der [lexicon]GPU[/lexicon] generierte MB im RGB Farbraum vorliegt. Je weicher, desto weniger [lexicon]Bitrate[/lexicon] wird benötigt.


    Und im Grunde sieht man es nachher ja eh nicht. Man dreht sich im Spiel -> [lexicon]Motion Blur[/lexicon] wird aktiv -> Umgebung verschwimmt. Man bleibt stehen im Game -> [lexicon]Motion Blur[/lexicon] hält an -> Umgebung wird klar.


    [lexicon]Motion Blur[/lexicon] soll ja verwaschen. Wird der Effekt bei der Hochskalierung ein wenig verstärkt, bringt das eigentlich nur für das Bild selbst vorteile.


    Hmmm... wie könnte man es noch beschreiben? Stell dir am besten mal vor um dir herum kreist ein roter viereckiger Kasten der immer schneller wird. Dein Auge kommt irgendwann nicht mehr mit und es entsteht [lexicon]Motion Blur[/lexicon] für dein Auge. Jetzt haste das auch noch mit einer Kamera aufgenommen und der Effekt ist dort auch zu sehen, da die Kamera den gleichen physikalischen Gesetzen folgt wie es dein Auge auch tut.


    Das Video wird hochskaliert und es tritt mit Spline16/100 ein Verstärkungseffekt auf. Die Übergänge sind viel weicher und sehen dann nicht nur besser aus, sondern sind auch Platzsparender. Stell dir vor du hättest dann mit Point Resize hochskaliert. Dann hätte das Bild gewiss mehr Speicherplatz verbraucht.

  • Ok...
    Gut das stimmt natürlich das eine MB der in RGB arbeitet besser arbeiten kann als einer in YuY2....
    Gut kann natürlich auch sein das ich immer MB von Spielen im Kopf habe die einfach nur grauenhaft sind xD


    Aber versucht man nicht trotzdem eine gewisse Schärfe im Bild zu halten?

  • Aber versucht man nicht trotzdem eine gewisse Schärfe im Bild zu halten?


    Joa. Aber willst du wirklich die [lexicon]Motion Blur[/lexicon] Frames einen Videos scharf haben? ^^ Ist das nicht etwas Fail dann? ^^ Weil ist doch dann gar nicht Sinn und Zweck eines [lexicon]Motion Blur[/lexicon] Effektes. ^^


    Das nachhaltige Auftragen des Motion Blurs im [lexicon]SSM[/lexicon] z.B. geschieht nach der Skalierung. Einfach weil dieser [lexicon]Motion Blur[/lexicon] das gesamte Video und all seine Frames betrifft. Bedeutet das selbst ruhige Stellen mit leichter Bewegung einem [lexicon]Motion Blur[/lexicon] ausgesetzt sind. Würde dieser Effekt vor der Skalierung auftreten, würde das Bild mehr verwaschen sein als sonstwas. Ist auch nicht im Interesse der User.


    Das MB eines Spieles ist aber geziehlt an bestimmten Punkten im Spiel nur zu beobachten und nicht über sämtliche Frames.


    Mal so in Kurzfassung:
    Spiele mit gezieltem [lexicon]Motion Blur[/lexicon] via [lexicon]GPU[/lexicon] Erzeugung in einem Spiel ist um vieles besser als eine nachträgliche [lexicon]Motion Blur[/lexicon] Erzeugung auf dem Video. Auf dem Video wird es über sämtliche Frames sonst gemacht, im Spiel allerdings geziehlt nur auf Bewegungsabschnitte die vom Spiel für MB ausgewählt wurden.


    Edit:
    Zudem steigt die Encodegeschwindigkeit wenn MB nicht auf das Video nachträglich aufgesetzt werden muss. Die [lexicon]CPU[/lexicon] Berechnung für diesen [lexicon]Filter[/lexicon] würde dann entfallen. Resultat: schnellere Encodierung. Daher ist [lexicon]Motion Blur[/lexicon] Nutzung in Spielen eine gute Sache seine Videos später besser aussehen zu lassen.


    Wer [lexicon]Motion Blur[/lexicon] nicht mag in Spielen, sollte sich dann halt nicht wundern warum das Video sich langsam in Pixelbrei verwandelt auf YT. ^^


    Inkomplexes Material braucht z.B. kein [lexicon]Motion Blur[/lexicon]. Sachen wie GBA, [lexicon]SNES[/lexicon], [lexicon]NES[/lexicon], Sega, Amiga, etc. pp.
    Natürlich kann darunter das ein oder andere Game mit viel Bewegung (Renngames wo sich der Hintergrund ständig ändert) selbst bei solch alten Konsolen zu einem Pixelsalat sich mutieren auf YT.
    Da muss man dann denk ich mal sehen wie man das am besten macht. Da die meisten dieser Konsolen bis eine max [lexicon]Auflösung[/lexicon] von 640x480 hatten (PS2 könnte sogar 1280*1024 erreichen, wenn der Videospeicher nicht 4MB betragen würde ^^)
    Aber im Grunde sind alle alten Konsolen im 640x480 Modus. Und gerade da macht es Sinn im RGB Mode aufzunehmen. Weil dann braucht man da kein [lexicon]Motion Blur[/lexicon] um den Pixelbrei zu entgehen später, sondern es wird mit 2 Skalierungen gearbeitet die das Bild später auf 1440p oder höher so gut aussehen lassen mit dem Effekt das man [lexicon]Bitrate[/lexicon] sparrt. Das ist aber dann wieder eine ganz andere Geschichte.


    Würdest du denken das das hier vorher eine 256x224 Aufnahme war: https://www.youtube.com/watch?v=8P5NYyeS2iE
    Ist mir doch gut gelungen die Skalierung von 256x224 auf 1080p, oder? ^^ (1080p reicht meist bei solchen Games)
    Und vor allem wäre das später durch die Skalierer sehr Bitratenfreundlich. Gut für schnelle Games, da akurat Skaliert wurde und die Pixel nicht mehr Farbe und somit mehr Speicher einnehmen.


    Bei [lexicon]Motion Blur[/lexicon] hingegen wird darauf gearbeitet mehr die gleiche Farbkombination auf mehrere Pixel zu übertragen (Verwischeffekt) um mehr Speicher zu sparen für das Bild.

  • Spiele mit gezieltem [lexicon]Motion Blur[/lexicon] via [lexicon]GPU[/lexicon] Erzeugung in einem Spiel ist um vieles besser als eine nachträgliche [lexicon]Motion Blur[/lexicon] Erzeugung auf dem Video. Auf dem Video wird es über sämtliche Frames sonst gemacht, im Spiel allerdings geziehlt nur auf Bewegungsabschnitte die vom Spiel für MB ausgewählt wurden.


    Das ist eine Erklärung die ich auch so akzeptieren kann :D

  • Keiner ne Idee?


    Also erstmal wäres sinnvoll Screenshots die Qualitätsvergleiche dienen sollen - nicht als JPG zu speichern. Wie will man sonst differenzieren, was jetzt JPG Kompressionsverluste sind, und was du zeigen willst? (auch wenns in dem beispiel jetzt klar ist, aber für die zukunft sollte sowas nicht in JPG gespeichert werden. Zumal auch bei JPG zwischen 4:4:4, 4:2:2 und 4:2:0 Chroma gewählt werden kann.


    Und das sieht mir in der Tat schlichtweg nach simplem Chromaverlust durch YV12 aus & eben TV range statt pc range (16-235 helligkeit vs 0-255 helligkeitsrange der farben)


    Und zum Chromaverlust:


    http://encodingwissen.de/grund…ion/intraframe#farbraeume

  • Die Bilder sind png, zumindest bei mir, ka warum die dort jpg drausmachen :) Und sie sind vom Pc nicht vom TV. Dein Link habe ich mir durchgelesen, stehe aber genauso ahnungslos da wie vorher, wie kann ich das nun umgehen bzw so gestalten, dass es auf YT genauso aussieht wie von mir gewünscht?

  • Und sie sind vom Pc nicht vom TV


    Das war mir schon klar, das ging mir auch eher um die helligkeitsrange :P


    Vegas weglassen würde eine Farbraumkonvertierung umgehen. 4:2:0 (YV12) Chroma, tv range wirds am Ende aber so oder so.
    10bit encode bei [lexicon]x264[/lexicon] anhaken.


    Für NLEs wäres am besten das du in RGB24 aufnimmst.


    Zitat

    Die Bilder sind png, zumindest bei mir, ka warum die dort jpg drausmachen


    Dann solltest du so schnell wie möglich mal den Bildhoster wechseln^^


    http://www.abload.de

  • Bisher läuft es ja so, Elgato -> Vegas -> [lexicon]Frameserver[/lexicon] -> [lexicon]Megui[/lexicon] -> Endprodukt


    Eingestellt vor 2-3 Jahren nach deinen Tuts hier. Vegas weggelassen ist realisitisch gesehen nicht möglich (extrem viele Schnitte + Texteinblendungen)
    Die Schrifteinblendung ist also von Vegas (bildmaterial dahinter ist also vollkommen uninteressant im Moment), starte ich dann den [lexicon]Frameserver[/lexicon], kommt ja in [lexicon]Megui[/lexicon] die [lexicon]avisynth[/lexicon]? Vorschau und Endfenster, dort sieht die Schrift immer noch so aus wie in Vegas. Nach dem [lexicon]Rendern[/lexicon] dann aber nicht mehr.


    Du sagst jetzt, ich soll nur in [lexicon]Megui[/lexicon] (irgendwo) den 10 Bit encode anhaken und dann ist alles ok mit der Schrift?

  • @360GameTv


    TV Range = 16 - 235, dabei ist 16 absolut Schwarz und 235 absolut Weiß
    PC Range = 0 - 255, dabei ist 0 absolut Schwarz und 255 absolut Weiß


    Wird ein TV Range Video auf ein PC Range Player/Vorschau wiedergegeben, dann ist das Video etwas heller als sonst.
    Wird ein PC Range Video auf ein TV Range Player/Vorschau wiedergegeben, dann ist das Video dunkler als sonst.
    Wird ein TV Range Video in einem TV Range Player/Vorschau wiedergegeben, bleibt die Helligkeit neutral indem 16 als pures Schwarz erkannt wird und 235 als pures Weiß (kann man auf YT gut beobachten und bei einigen Playern)
    Wird ein PC Range Video in einem PC Range Player/Vorschau wiedergegeben, bleibt die Helligkeit neutral indem 0 als pures Schwarz erkannt wird und 255 als pures Weiß.


    Bisweilen ist mir nur [lexicon]Fraps[/lexicon] bekannt der in PC Range aufnehmen kann. Alle anderen Aufnahmeprogramme die ich bisher so gesehen habe nehmen alle TV Range auf.


    Hast du im MPC vllt ein Shader an der das ganze konvertiert von TV -> PC ? Dann wäre es nämlich klar das es dunkler ist.
    Du darfst dein Video weder beim Encode in [lexicon]MeGUI[/lexicon], noch im Video Player einer Farbrange Konvertierung aussetzen, sonst haste das Ergebnis wie du es mit den Bildern gezeigt hast.


    Wenn du dir aber nicht sicher bist, dann poste einfach die Konfiguration vom [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon] in [lexicon]MeGUI[/lexicon]. Dann sehen wir ja was da passiert. Geht aber nur, wenn du dir absolut sicher bist das die Vorschau in [lexicon]MeGUI[/lexicon] korrekt ist. Wenn nicht, dann liegt der Fehler noch vor [lexicon]MeGUI[/lexicon].


    Wenn wir da nix komisches sehen sollten anhand der Parameter, dann solltest du mal dein MPC überprüfen in Sachen Shader Nutzung und Ausgaberenderer.

  • Bisweilen ist mir nur [lexicon]Fraps[/lexicon] bekannt der in PC Range aufnehmen kann. Alle anderen Aufnahmeprogramme die ich bisher so gesehen habe nehmen alle TV Range auf.


    Abgesehen von RGB ^^
    ___


    10bit encode = kleinere Dateien und mehr Qualität (kein [lexicon]banding[/lexicon])


    Elgato ist bereits eine Verlustquelle und Chroma liegt dann auch nur in 4:2:0 vor.


    -> Bereits komprimiertes Video re-[lexicon]encodieren[/lexicon] = blöd, wäre besser wenn verlustfreie quelle
    quelle ist schon in 4:2:0 Für [lexicon]NLE[/lexicon] ala Vegas wäre RGB24 am besten geeignet.
    -> Durch dem [lexicon]Frameserver[/lexicon] haste Konvertierung: YV12 -> YUY2 -> YV12. Und bevor es an den [lexicon]Frameserver[/lexicon] geht, kann ein Vegas [lexicon]Filter[/lexicon] zwischen sein, der auf RGB32 konvertiert. Denn zb für Alphakanäle/Masken wird RGB32 benötigt. Also wieder weitere Konvertierung und hier schon sogar tv -> pc und Konvertierung von YUV auf RGB und zurück = Rundungsfehler.


    Alles in allem gehen halt viele Chroma und Farbraumkonvertierungen durch.


    Den [lexicon]Frameserver[/lexicon] Farbkonvert könnte man umgehen, wenn man nicht [lexicon]frameserver[/lexicon] nutzt, sondern zb als [lexicon]lagarith[/lexicon] YV12 exportiert und die [lexicon]lagarith[/lexicon] dann [lexicon]megui[/lexicon] gibt.


    YUV 16-235 vs RGB 0-255 sieht auch schon anders aus. Wie gibst du denn ausm [lexicon]Frameserver[/lexicon] aus? RGB oder YUY2?
    Projekteinstellung von Vegas stehts auf 8 bit? 32bit wäre falsch.

  • Nochmal, wie bereits geschrieben, um das Hintergrund Bild aka Videopiel geht es doch garnicht, daher ist die Aufnahmeart pups egal erstmal. Von mir aus denkt euch da gerade ein schwarzes Bild :)


    Es geht um die Schrift, die per Vegas hinzugefügt wird und alle Einstellungen sind nach Demons Empfehlungen. Vegas / [lexicon]Megui[/lexicon] / MPC sind so konfiguriert. (Beispiel MPC als Ausgabe EVR Custom pres. )


    Vegas steht natürlich auf 8Bit und im [lexicon]Frameserver[/lexicon] wird yuy2 ausgewählt. In der Vorschau von Vegas und [lexicon]Megui[/lexicon] sieht es exakt so aus wie es sein sollte, auf YT und im MPC nichtmehr danach.


    mfg

  • Welche Range ist denn für Youtube am besten?


    YT nutzt TV.601


    Man kann aber auch andere Schemen hochladen. YT reagiert entsprechend drauf. PC Range wird entsprechend dunkler, wärend die Farbmatritzen 601 oder 709 die Farben etwas anders anzeigen. (Gut bei sehr sehr dünnen Rot, Grün, Blaustreifen zu sehen was dort passiert ^^)


    Nochmal, wie bereits geschrieben, um das Hintergrund Bild aka Videopiel geht es doch garnicht, daher ist die Aufnahmeart pups egal erstmal. Von mir aus denkt euch da gerade ein schwarzes Bild


    Uns geht es was du mit dem Video angestellt hast. Und ja, von mir aus denk dir den Hintergrund weg. Und es ist immer noch ein TV/PC Range Problem. Was die Schrift erleidet, erleidet doch auch das Gesamtbild. Sprich irgendwo in welchen Programm auch immer wandelste das von einer TV Range in eine PC Range um. Vllt sogar noch ne falsche Farbmatrix genommen. kA. Solange du nicht mal durchschaust oder uns was postest suchen wir uns dumm und dämlich.


    Hinweise hab ich dir schon gegeben:
    Sind im MPC irgendwelche Shader an? Ist im MPC der Ausgarenderer verstellt? EVR kann man nämlich auch in 0-255 oder 16-235 anzeigen lassen.


    Ist richtig encodiert worden? [lexicon]x264[/lexicon] kann nämlich auch den Farbraum wechseln in TV, PC mit verschiedenen Farbmatritzenkonvertierungen. Vllt da mal die Command uns posten oder mal mit meiner kurz vergleichen:
    program --preset slow --crf 18.0 --keyint infinite --min-keyint 1 --aq-strength 1.25 --output "output" "input"


    Weil wenn du sagst das es in der Vorschau in [lexicon]MeGUI[/lexicon] noch ok aussieht, kann es ja nur noch danach auftreten irgendwo.

  • Große Noobfrage die hier wahrscheinlich schon 100 mal beantwortet wurde :



    Kann ich das Audio + Video mit [lexicon]MeGUI[/lexicon] irgendwie [lexicon]encodieren[/lexicon] ohne, dass beides voneinander getrennt wird.
    Ich weiß, dass man das mit den MKVmerge wieder zusammenpacken kann/soll, aber mein Schnittprogramm kann mit [lexicon]MKV[/lexicon]-Dateien relativ wenig anfangen.
    Hab daher das VIdeo auf [lexicon]MP4[/lexicon] gerendert, aber dann kann ich das audio ja nicht mit den merge iweder zusammenpacken.


    Wie gesagt : Noobfrage

  • Ich weiß, dass man das mit den MKVmerge wieder zusammenpacken kann/soll, aber mein Schnittprogramm kann mit [lexicon]MKV[/lexicon]-Dateien relativ wenig anfangen.


    Andere Noobfrage: Wieso will man das tun? Ich meine ein Encodiertes Video dann noch mal [lexicon]encodieren[/lexicon] ist irgendwie Witzlos, oder? ^^


    Mache lieber folgendes:

    • Virtual Dub 32Bit brauchste
    • Lade das Skript von [lexicon]MeGUI[/lexicon] in Virtual Dub.
    • Hat das Skript schon über Audio, wird Audio gleich mitgeladen. Hast du Audio extern, so kannste es in VDub extra hinzufügen.
    • In VDub dann speicherst du es als AVI mit einem [lexicon]Lossless[/lexicon] [lexicon]Codec[/lexicon] wie [lexicon]Lagarith[/lexicon] oder UTVideo, wärend Sound mit [lexicon]PCM[/lexicon] [lexicon]WAV[/lexicon] encodiert wird in die AVI.


    Diese AVI kannste dann in dein Schnittprogramm laden. Es ist Verlustfreier, als wenn du das [lexicon]encodieren[/lexicon] tust. Und 10 mal schneller fertig, da [lexicon]Lossless[/lexicon] ziemlich schnell ist bei der Erzeugung.


    Edit:
    Das aber nur dann machen wenn sich das Format nicht ummuxen lässt.


    Versuche stehts immer erst ein ummuxen des Videos, statt eine Neuencodierung. Und wenn es nicht anders geht, dann halt mein Vorschlag hier nehmen. Halt so Verlustfrei wie möglich die Quellen halten, sofern du sie noch bearbeiten willst.

  • Ergänzend zu Sagaras:


    Hab daher das VIdeo auf [lexicon]MP4[/lexicon] gerendert, aber dann kann ich das audio ja nicht mit den merge iweder zusammenpacken.


    Ne aber mit MP4boxgui.


    Ums direkt von [lexicon]MeGUI[/lexicon] gemuxt zu bekommen: AutoEncode Button: [lexicon]MP4[/lexicon], No target size, no splitting, und auf queue drücken (das würde dann 3 jobs adden: audio, video, mux) Damit du AutoEncode nicht jedes Mal aufs erneute einstellen musst, kannste auch in meguis optionen mit configure autoencode defaults auch permanent speichern.


    Aber [lexicon]MP4[/lexicon] unterstützt nur MP1, MP2, MP3, [lexicon]AAC[/lexicon] als audioformate. [lexicon]FLAC[/lexicon] oder Vorbis kannste also da nicht rein tun. Sprich das mit AutoEncode setzt voraus, das das Audio auch in [lexicon]MP4[/lexicon] getan werden kann, sonst gibt AutoEncode dir auch gar nicht erst [lexicon]MP4[/lexicon] zur Auswahl. Er bietet dir nur kompatible [lexicon]Container[/lexicon] an (sprich guckt, was du in [lexicon]megui[/lexicon] geladen hast)


    Aber das wäre ja auch gar kein Problem, denn Audio muss ja nicht zwangsläufig in ein [lexicon]Container[/lexicon], sondern kann ja auch ohne [lexicon]Container[/lexicon] ergänzt werden ins programm.

Jetzt mitmachen!

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