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

    Zitat von Dennis_50300

    jop ist soweit ich das sehe auf dem Stand der Dinge, das mit dem 444 wie man es im Video sieht unter "misc" beim x264 kann man halt rauslassen, 444 macht keinen Sinn hochzuladen auf YouTube.Aufnehmen schon unter gewissen Umständen eben wenn du DosBox z.B. benutzt für Games, b.z.w. niedrige Auflösungen aufnimmst, weil man dann mit dem Poin Size (sagaras skriptmaker) "toller" hochskalieren kann.



    Gruss Dennis

    Vielen Dank für die Antwort auch wenn ich nach dem "auf dem Stand der Dinge" nur noch Bahnhof verstanden habe. Aber das legt sich vielleicht nach dem einlesen/einsehen der beiden Threads :)

    Zitat von QuinsWorld

    Vielen Dank für die Antwort auch wenn ich nach dem "auf dem Stand der Dinge" nur noch Bahnhof verstanden habe. Aber das legt sich vielleicht nach dem einlesen/einsehen der beiden Threads :)

    Joa definitiv, zuletzt war ich da fleissig mit SagaraS darüber am Schreiben und er hat es sehr detailliert erklärt gehabt, ich habs versucht in Kurzform zum Schnelleinstieg, ist eigentlich weniger schwer als man erst meint.



    Gruss Dennis

    Zitat von Dennis_50300

    444 macht keinen Sinn hochzuladen auf YouTube.

    Und warum nicht?


    Wer Storage hat, der das stemmen kann, hat durch 4:4:4 weniger CPU Belastung bei Aufnahme, da kein Chroma zwischen interpoliert werden muss, und verbleibt man bei 4:4:4 auch bei x264 erhält man durch der besseren Komprimierbarkeit in den meisten Fällen eine kleinere Datei als bei 4:2:2 oder 4:2:0.

    Zitat von Dennis_50300

    Aufnehmen schon unter gewissen Umständen eben wenn du DosBox z.B. benutzt für Games, b.z.w. niedrige Auflösungen aufnimmst, weil man dann mit dem Poin Size (sagaras skriptmaker) "toller" hochskalieren kann.

    4:4:4 ist grundsätzlich für jeden Filter eine bessere Basis zum Arbeiten, allem voran aber dem Auflösungsskalierer. Und youtube's Auflösungsskalierer wird es entsprechend auch mögen.

    Joa irgendwie muss man ja die Capturekarte per CPU-Dampf Recording rechtfertigen ne ;-)


    NVenc ist da definitiv sinnvoller, ob ich bei CRF18 1,7GB Dateien hab oder 2GB die ich hochladen muss das macht dann echt nun nicht so den grossen Unterschied.
    Das da nicht mehr nachher bei herumkommt auf YouTube nach der Verarbeitung schreibt SagaraS ja auch nicht ohne Grund.


    Also im grunde genommen lohnt sich 444 dann per cpu-dampf eben nur für die DosBox Geschichten beispielsweise wenn du Point Resize nutzen willst zum Hochskalieren.


    Wenn mit Vega dann mal 444 möglich werden sollte über AMD VCE, oder zumindest mit der nächsten Generation nvenc an NV'S karten 444 drin ist, kann man das gerne mitnehmen, aber ansonsten ist es einfach nur ineffizienter, wobei man aber so gut wie garkeinen Mehrwert davon hat, das steht in keinem Verhältnis.


    Was alte Schinken angeht, werd ich mehr per DSR Aufnehmen, direkt in 2560x1440, dann brauch ich da auch nichts mehr hochskalieren, für LP's kann man dann auch gut und gerne notfalls ein paar Details wegnehmen dann wenn es unbedingt sein muss damit noch genügend FPS dabei herumkommen, AA weniger b.z.w. deaktivieren dürfte aber auch schon helfen, dank DSR ja auch kein Beinbruch.


    Edit:
    Bei PointResize von DosBox Aufnahmen auf HQ3x oder xBRZ hatte ich übrigens nicht so'n Murks gehabt das die Threads nicht richtig ausgelastet waren, da ging das Rendern dann auch verdammt schnell vom 444 Material.


    vielleicht könnte man mit 444 das Point Resize ja auch beim Hochskalieren verwenden, nur das wiederum geht ja nunmal leider nicht mit nvenc, also dann lieber gleich direkt in 2560x1440 aufnehmen und gut ists.
    Notfalls per DSR auch kein Beinbruch, bei LP's, brauchen die Aufnahmedateien halt ein wenig mehr Platz, mal schauen was so kommt mit Vega und AMD VCE dann :-)



    Gruss Dennis

    Einmal editiert, zuletzt von Dennis_50300 ()

    Manchmal hab ich das Gefühl du bist etwas neidisch, wenn jemand Dinge hat, die du nicht hast? Anders kann ich mir solche Aussagen wie:



    Zitat von Dennis_50300

    Joa irgendwie muss man ja die Capturekarte per CPU-Dampf Recording rechtfertigen ne

    nicht erklären.
    Was muss ich hier rechtfertigen? Eine Aufnahme in 4:4:4 ist auch ohne Capture Karte möglich. Da mein RAID 0 irgendwie an Speed verloren hat ( von 350 auf 270 mbyte/s abgesackt - vllt sind die 5 Jahre alten Platten langsam ermüdet ) nehme ich auch mit der CC momentan in nur 4:2:0 auf, also beruhig dich.
    Trotzdem: Wer den Storage hat der 4:4:4 stemmen kann hat bei Aufnahme CPU Ersparnis, da kein Chroma zwischeninterpoliert werden muss und hat mit einem solchen Material Filter- und Kompressionsvorteile beim späteren Encode und natürlich auch nach Youtube. Die unteren Qualitätsstufen sind ja nunmal auch Skalierung. Und das geht aus 4:4:4 heraus halt mit weniger Verluste seitens Skalierer. Ja die Unterschiede sind marginal, wenn man Youtube's Kompression der kleineren Stufen vor allem mitbedenkt. Aber zu schreiben das es komplett gar keinen Vorteil hat, ist halt auch daneben. Zumal Effektfilter oder anderweitige Filter machen bei 4:4:4 ja auch sauberere Arbeit.



    Zitat von Dennis_50300

    NVenc ist da definitiv sinnvoller, ob ich bei CRF18 1,7GB Dateien hab oder 2GB die ich hochladen muss das macht dann echt nun nicht so den grossen Unterschied.

    Naja der Kompressionsunterschied kann schon manchmal überraschend deutlich ausfallen. Aber bei meiner Leitung wäre's auch egal wie groß die Datei wird. Aber wenn man 4:4:4 stemmen kann, nimmt man den Vorteil doch gerne mit.



    Zitat von Dennis_50300

    Also im grunde genommen lohnt sich 444 dann per cpu-dampf eben nur für die DosBox Geschichten beispielsweise wenn du Point Resize nutzen willst zum Hochskalieren.

    Bei Nearest Neighbor ist das vollkommen Latte ob du 4:2:0 oder 4:4:4 hast. Bei nearest neighbor wird einfach jeder Pixel dupliziert und fertig. Aber du meinst mit Pointsize wohl die Pixelscaler wie xBRZ und co. Bringt dir YUV 4:4:4 auch nichts, die unterstützen nur RGB, da ihre Interpolationsmechanik technisch bedingt nur mit RGB sinnvoll funktioniert. Weshalb da auch eine Aufnahme in RGB anzuraten wäre, sollte man die nutzen wollen. 4:4:4 dürfte zwar auch noch recht ok funktionieren - je nach dem wie enorm hochskaliert werden muss, aber diese Scaler arbeiten eig. nur wie vorgesehen, wenn sie RGB Inputs erhalten.

    Zitat von Dennis_50300

    oder zumindest mit der nächsten Generation nvenc an NV'S karten 444 drin ist, kann man das gerne mitnehmen

    Ist es doch. Bei Pascals NVEnc wo ja auch h.265 geht, ist sogar 16bit 4:4:4 drin. Und ich könnte mir sehr gut vorstellen das auch AMD schon mehr als 4:2:0 supported.


    Pascal NVEnc supported diese:


    Code
    Supported pixel formats: yuv420p nv12 p010le yuv444p yuv444p16le bgr0 rgb0 cuda

    Also sogar 4:4:4 16bit. Also bitte. Wenn OBS nur 4:2:0 an den Encoder sendet, kann NVEnc da herzlich wenig für und ich auch nichts für. Quark dann nicht mich wegen meiner CC voll oder Nvidia's NVEnc, sondern quark dann lieber mal ins OBS Forum drüber. Das wäre dann sogar produktiv, weil das durchaus ein Defizit ist. Auch scheint mir OBS keine Glücksgriffe zu wählen mit den Frames, wenn man nicht gerad einen enormen überschuss an frames hat gegenüber aufnahme fps. Ich hatte da immer deutlich duplikatframes drin, bei 100+ fps jedoch schon weniger als bei 70. Bei Capture Karte war auch bei 70 spielfps und 60 aufnahme fps noch jeder frame unique. Vllt würde OBS bessere Glücksgriffe gelingen wenn man die fps auf ein vielfaches limitieren würde, zb 120 bei 60 aufnahme fps wenn der pc dauerhaft 120 halten kann. oder eben 60 / 60 zumindest.

    Zitat von Dennis_50300

    Was alte Schinken angeht, werd ich mehr per DSR Aufnehmen

    Naja wenn dir der Gauss Skalierer zusagt .. ok.
    Also mir produziert der viel zu viel Unschärfe. Merkt man bereits aufm Desktop auf den Schriften.


    Bei besserer CPU als meine 3770k wird das eh völlig irrelevant ob ich die CPU oder NVEnc nehme. Selbst der 3770k kriegt ja schon 2560x1600p60 mit CPU fast komplett ohne Verlust bewältigt. Lediglich Unreal neigt etwas früher einzubrechen als wenn die CPU komplett frei ist. Bei anderen Spielen existiert selbst mit der CPU nichtmal mehr eine fps veränderung. Und die aktuellen CPUs haben ja schon 6, 10 oder gar 18 Kerne mit recht guten Taktraten, da wird das bissl CPU Coding von Virtualdub überhaupt keine Rolle mehr spielen.
    Von daher bräuchte ich einfach nur mal bessere hardware allmählich.

    Ich habe gerade mal meine ersten Testencodings (Vegas - Frameserver - MeGUI) mit meinen neuen PC gemacht (1700x Ryzen 7) und omg auf medium 34,4 fps und auf slow noch knappe 28 FPS bei einem 5min langen Video. Krank wenn ich an vorher denke mit max 3-5 fps^^

    Ich hatte mit dem alten PC CRF 19 oder 21 ?!
    Jetzt mit OBS bei CRF 16. Placebo Effekt oder sind die Schriften nun tatsächlich einiges besser zu lesen im Endergebniss.



    Da ist die Frage ob MEGUI mehr zaubert als OBS oder ist CRF immer gleich ?
    ( Natürlich kommt es auf den Codec etc an )
    Aber wäre interssant zu wissen ob jetzt per dxtory und megui oder obs direkt.

    @De-M-oN
    Danke für den Hinweis mit dem Frameserver + MeGUI + SSM. Das Schneiden über 'CUT' funktioniert soweit ganz gut. Auch kann ich mir eine Preview von dem Bereich ansehen. Der Ton wird auch abgespielt.


    Leider hab ich ein Problem, sobald ich den Ton über den Reiter 'Audio' exportiere. Es hört sich an als würde der Sound hängen und nur die ersten Millisekunden abspielen. Oder es ist kein Ton zu hören. In der Preview, wie oben geschrieben, ist alles okay. Liegt das an VirtualDub?

    @UndiscoveredLP kann dir statt frameserver + megui x264vfw empfehlen - die hatten neulich sogar ein neues release.
    Ist ne Ecke schneller und du kannst mit batching arbeiten oder so tools wie vegasaur


    Ist nur etwas tricky wegen avi container.
    Das audio encodiere ich mir dann hinterher mit ffmpeg
    zB aac im mp4 container mit faststart


    ffmpeg -i input.avi -c:v copy -c:a aac -ab 320k -movflags +faststart out.mp4


    oder flac + mkv


    ffmpeg -i input.avi -c:v copy -c:a flac out.mkv


    fallst du die genauen Einstelluneg für x264vfw willst (damit das avi nicht async wird) sag bescheid

    @Schauerland
    Gestern hab ich noch im x264vfw Tutorial nach einer Möglichkeit gesucht mehrere Videos inkl. Audio zu rendern. Das heißt mit der neuen Version des x264vfw funktioniert es nun? Falls ja, wäre ich sehr interessiert an dem Thema um für mich selbst rauszufinden, ob ich besser mitr x264vfw oder SSM + MeGUI arbeiten möchte.


    Kannst du mich da etwas aufklären? Würde mich auch freuen, wenn du mir die Einstellungen sagen könntest, sodass das *.avi file nicht async wird :)


    @De-M-oN
    Nein, da ich mir nicht sicher war, ob ich das tatsächlich anhaken musste. Werde ich gleich ausprobieren, da ein Rendervorgang noch am Gange ist.

    Zitat von fr0st

    Gestern hab ich noch im x264vfw Tutorial nach einer Möglichkeit gesucht mehrere Videos inkl. Audio zu rendern. Das heißt mit der neuen Version des x264vfw funktioniert es nun? Falls ja, wäre ich sehr interessiert an dem Thema um für mich selbst rauszufinden, ob ich besser mitr x264vfw oder SSM + MeGUI arbeiten möchte.

    Es funktionierte immer. Du musst den Output-Mode anders wählen. Statt "File", wie im Tutorial angegeben, nimmst du VfW. Dann bekommst du eine AVI-Datei incl. Ton heraus. Das was da raus kommt ist nicht ganz unproblematisch, deshalb hat Schauerland noch einen abschließenden Schritt, indem er von FFmpeg die Videospur kopieren, Audiospur kodieren und alles in einen MP4-Container stecken lässt.

    @fr0st
    wichtig sind die zwei Haken bei Zero Latency und VirtualDub Hack


    [IMG: http://www.bilder-upload.eu/upload/b5d03f-1502708488.png]


    wie gesagt, audio musst du dann noch encodieren und beides muxen - ich mache es mit einem ffmpeg script in einem schritt


    falls du größer als 1920x1080 renderst, musst du Level kleiner 6 manuell setzen, da sonst Vegas 14 das nicht mehr einlesen kann (falls du die fertigen dateien nochmal in vegas brauchst)

    @RealLiVe
    Gestern noch den ganzen Abend nach einer Lösung gesucht. Wäre ich im Leben nicht drauf gekommen. Man lern nie aus.


    @Schauerland
    Apropo man lernt nie aus. Auch hier hab ich wieder was dazu gelernt. Gibt es bei den Level etwas zu beachten? Vor- und Nachteile der einzelnen Level? Ab und an macht es sicherlich Sinn alte Projekte in Vegas weiter verarbeiten zu können.
    Ich hab die Erfahrung gemacht, dass Vegas meine *.mkv Dateien aus OBS nicht in das Projekt importieren kann. Ist das nach dem muxen durch dein obiges Script unter Berücksichtung des Levels immer noch so? Würde flac + mkv gegenüber aac + mp4 vorziehen.


    Noch eine kleine Rückfrage zu deinem Script:
    Ich erstelle eine Batch, kopiere die Zeilen rein und starte das Script im selben Verzeichnis wo die *.avi-Datei liegt. Am Ende erhalte ich meine gemuxte *.mkv / *.mp4 Datei, die ich auf YT hochladen kann. Verstehe ich das richtig?

    ffmpeg runterladen (statisch gelinkt) und entpacken https://ffmpeg.zeranoe.com/builds/


    path variable des ffmpeg ordners hinzufügen


    in .bat Datei kopieren und diese ins Ausgaveverzeichnis der avis legen. mit doppelklick werden alle avis in mp4 gemuxt und das audio in aac convertiert


    Code
    for %%i in (".\*.avi") do (

        ffmpeg -i "%%i" -c:v copy -c:a aac -b:a 320k -movflags +faststart ".\%%~ni.mp4"

    )


    alternativ als mkv

    Code
    for %%i in (".\*.avi") do (

        ffmpeg -i "%%i" -c:v copy -c:a flac ".\%%~ni.mkv"

    )

    Vegas kann kein mkv importieren und scheinbar kein h264 mit level 6
    Hier einige Infos zu den levels:
    https://de.wikipedia.org/wiki/H.264#Level

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden