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

  • Es rendert noch 4 Stunden. In der Zwischenzeit probiere ich das mal mit den b-frames. Würde eine Reduktion auf 30FPS beim Aufnehmen helfen? Liegts vielleicht auch an [lexicon]FRAPS[/lexicon]?



    EDIT:
    Die b-frames sind schon auf 0. Also trotzdem 2 Stunden.


    [lexicon]Prozessor[/lexicon] ist ein AMD Phenom II X4 940 3GHz. Ist eben mein alter Rechner, der zuhause geblieben ist und nur selten benutzt wird.

  • Ich kodiere meine Videos nun schon länger im Farbraum YV24 bzw. YV16 (abhängig vom Material).
    Aufgenommen wird mit dem UtVideo [lexicon]Codec[/lexicon] 'YUV422', oder eben 'RGB'.
    Im [lexicon]SSM[/lexicon] habe ich für YUV 4:2:2 Aufnahmen Versuchen ohne Konvertierung als YV16 auszugeben, bei RGB YV24 Konvertierung der Videos eingestellt. avs4x264mod ist aktiviert, da ich in [lexicon]MeGUI[/lexicon] den 64 Bit [lexicon]Encoder[/lexicon] nutze.


    In der [lexicon]MeGUI[/lexicon] settings.xml habe ich <AskAboutYV12> und <AddConvertToYV12> auf "false" gestellt, damit der Input nicht zusätzlich zu YV12 konvertiert wird.
    Im [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon] habe ich noch folgende Parameter angegeben:
    --output-csp i422 bzw. --output-csp i444
    Damit die Videos eben auch im 4:2:2 bzw. 4:4:4 Sampling kodiert werden.
    Sollte soweit hoffentlich stimmen. Im [lexicon]MeGUI[/lexicon] Log finden sich jedoch ominöse Warnungen.


    Hier der Log zum Encode:


    Das [lexicon]AviSynth[/lexicon] Skript ist auch im Log zu finden.


    Auffällig ist hierbei
    ---[Warning] [31.05.2015 02:00:20] resize [warning]: converting from yuv420p to yuv422p


    ---[Warning] [31.05.2015 03:35:34] avs [warning]: Converting input clip to YV12


    ---[Information] [31.05.2015 03:35:34] avs4x264 [info]: "D:\Programme\MeGUI_2418_x86\tools\x264_10b\x264-10b_64.exe" - --preset fast --crf 14.0 --keyint infinite --min-keyint 1 --output-csp i422 --sar 1:1 --output "D:\Videos\Codiert\GTA5 #041.264" --frames 60356 --fps 50/1 --input-res 2560x1440 --input-csp i420 (--input-csp i420)


    Soweit ich das richtig interpretiere heißt das, das mein Input in [lexicon]MeGUI[/lexicon] erst in YV12 (4:2:0) konvertiert wird, und danach in YUV422, da ich [lexicon]x264[/lexicon] durch den Parameter auf 4:2:2 Output gestellt habe. Mein Ziel ist es jedoch die YUV 4:2:2 Aufnahme auch im 4:2:2 Sampling zu kodieren, also habe ich entweder im [lexicon]SSM[/lexicon], oder [lexicon]MeGUi[/lexicon] etwas falsch eingestellt.


    Daher meine Frage: Liege ich mit meiner Interpretation soweit richtig, und was habe ich in meinem Workflow falsch eingestellt? Eventuell im [lexicon]SSM[/lexicon] YV16 Konvertierung der Videos einstellen?
    Soweit ich nachgelesen habe scheint das ganze eventuell auch mit der avs4x264mod zusammenzuhängen, welche ja nur YV12, YV16 und YV24 unterstützt, daher habe ich auch YV16 für meine aufgenommenen Videos im 4:2:2 Sampling eingestellt, das soweit auch stimmen sollte.


    Nach meiner Befürchtung wird das Video also erst in YUV420 konvertiert, und dann noch mal in YUV422, wie ich es dann auch als Output kriege.


    Und last but not least, die [lexicon]MediaInfo[/lexicon]:


    Die MKVMerge Version ist veraltet, da die Updates in [lexicon]MeGUI[/lexicon] dafür unbeabsichtigt bis eben deaktiviert waren.


    Ich denke damit dürfte ich genügend Informationen zu meinem Problem gestellt haben.


    Schon mal vielen Dank für eure Hilfe :)

  • UTVideo nimmt in YUY2 auf - nicht YV16.


    Daher ist deine Farbraumangabe in [lexicon]SSM[/lexicon] falsch.


    Ohne Konvertierung YUY2 wählen und den YV16 fix haken drin lassen (dieser konvertiert dann dein YUY2 video zu YV16, damit die avs4x264mod pipeline damit zurecht kommt.

  • Gut, werde ich dann nächstes mal vor dem Kodieren so einstellen.
    Das Problem sollte sich damit wohl schon erledigt haben, dankeschön!


    Kommt es bei der Konvertierung von YUY2 zu YV16 zu Rundungsfehlern? Haben ja beide eine 4:2:2 Abtastung, aber einen anderen Aufbau. Würde mich einfach interessieren.

  • Kurze Frage:
    MSI AB nimmt mit 60 FPS auf.
    Encoden will ich ebenso mit 60FPS.
    Das Spiel hat aber an vielen Stellen 30-40FPS.


    Wie muss ich das in [lexicon]SSM[/lexicon] und [lexicon]MeGUI[/lexicon] einstellen, dass das Material nicht verschnellert wird?

  • In Zukunft nehme ich dann eh mit den leistungsfähigeren 40FPS auf.


    40FPS sind für YouTube aber recht sinnfrei.
    Für HFR bräuchtest du meiner Erfahrung nach mindestens 45FPS, ansonsten bietet dir YT hinterher maximal 30FPS an.
    Wenn du HFR haben willst, solltest du entweder direkt mit 45FPS aufnehmen oder es nachträglich auf 45FPS hochrechnen lassen.

  • Kommt drauf an was du erreichen willst.
    Flüssiges Video und "perfekte" Bildqualität sind allgemein gesagt nun mal zwei Gegensätze auf YouTube. Irgendeinen Kompromiss musst du eingehen.
    Bei 45FPS hättest du die bestmögliche Bildqualität die mit nativem HFR Material möglich ist.
    Mit 25FPS -> 50FPS hättest du nochmal höhere Bildqualität aufgrund der geringeren Anzahl an unterschiedlichen Bildern pro Sekunde kombiniert mit der höheren HFR [lexicon]Bitrate[/lexicon].


    Wenn du höhere Bildqualität haben willst, wäre es aber sinniger erst die [lexicon]Auflösung[/lexicon] zu erhöhen, das steigert die [lexicon]Bitrate[/lexicon] wesentlich mehr als ein HFR Encode. Desweiteren muss man bedenken, dass YouTube aktuell quasi nie höher kodiert als 1080p@60FPS.


    Aus meiner Sicht wäre 1152p@45FPS (wenn YouTube es kodieren sollte) aktuell der beste Kompromiss mit Schwerpunkt auf Bildqualität bezüglich Kodierzeit, Dateigröße, Aufnahme, Uploadzeit und Framerate. Hängt aber natürlich wieder vom Spiel, der Internetleitung und der eigenen Hardware ab.

  • Ich habe schon länger das Problem, das in [lexicon]MeGUI[/lexicon] über den Auto Encode das Multiplexen fehlschlägt.
    Daher habe ich mich etwas erkundigt, und das ganze scheint wohl mit der Größe (?) des kodierten Videos und dem Speicher zusammenzuhängen. Und meine Videos sind gerne mal 10-20 GB groß.


    [lexicon]MeGUI[/lexicon] Log:


    Wichtig ist hierbei diese Fehlermeldung:
    --[Error] [03.06.2015 16:45:22] Error: memory.cpp/safemalloc() called from file src/common/mpeg4_p10.cpp, line 1074: malloc() returned nullptr for a size of 218543 bytes.


    Der Fehler scheint öfter bei einigen Nutzern aufzutreten, aber eine "Lösung" habe ich bisher noch nicht gefunden.
    Die Auto Encode Einstellungen sind auf "No splitting" & "No target Size" eingestellt, was soweit stimmen sollte. Zudem ist "Always mux [lexicon]mkv[/lexicon] encoding with mkvmerge" aktiviert.


    Den Audio- und Videostream muxe ich dann immer manuell in MKVMerge zusammen, was auch ohne Probleme funktioniert. Würde mich nur interessieren ob es ein "Workaround" gibt, oder ich mich bei den größeren Videos darauf einstellen sollte, das ich das Ganze hinterher manuell [lexicon]muxen[/lexicon] soll? Wäre natürlich nur halb so wild, aber doch ganz praktisch wenn das automatische [lexicon]Muxen[/lexicon] funktionieren würde.


    Wieder mal danke für eure Hilfe!

  • 40FPS sind für YouTube aber recht sinnfrei.
    Für HFR bräuchtest du meiner Erfahrung nach mindestens 45FPS, ansonsten bietet dir YT hinterher maximal 30FPS an.


    Getestet? Ich hab bisher nur 31 fps getestet und weiß nur das 45 geht. Aber zwischen diesen weiß ich nicht. Also ist 45 minimum?


    @Rafinoff : Du brauchst 64bit MKVMerge. Bei großen Dateien kriegst du sonst Probleme mit dem 4 GB RAM limit von 32bit. [lexicon]MeGUI[/lexicon] hat halt nur das 32bit MKVMerge :(


    Evtl kannst ja die mkvmerge.exe der 64bit version in [lexicon]MeGUI[/lexicon] ersetzen. Sollte eig. ja gehen.


    Warum den MTMode auf 4?

  • 4 ist langsamer.


    Mode 3 die Sourcen und mode 2 den Rest



    1 wäre schnellste, jedoch sehr inkompatibel zu filtern.


    mode 3, 2 kombo ist immer noch sehr schnell mit nur etwas mehr RAM verbrauch als 1.

Jetzt mitmachen!

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