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

Du hast nicht in RGB aufgenommen. Fraps nimmt in YUY2 auf. Ist wie YV12 ein 4:2:0 Subsampling.

Eine Qualitätsreduzierung durch Änderung auf YV12 liegt also NICHT vor.

Etwas anderes als YV12 zu verwenden wäre massivste Anhebung der Dateigröße zu absolut wenig Qualitätsgewinn. Von einem "erheblich" kann hier echt nicht die Rede sein.

Schon gar nicht, wenn euer Quellmaterial nicht mal in etwas besseres als 4:2:0 aufgenommen wurde.

Auch macht es weder Sinn in etwas höheres als 4:2:0 aufzunehmen noch mit etwas höherem zu Encodieren, da spätestens Youtube es eh ebenfalls mit YV12 encodiert.

Ihr solltet allerdings nicht mit VLC oder WMP etc Videos anschauen. Wenn ich hier ein "erheblich" höre, dann lässt mich das schon vermuten, das ihr eines dieser Player verwendet.

Preset würd ich nicht schneller als Medium machen. Das killt die Kompression schon stark. Das mach ich nicht mal mit meinem 32 Mbit Internet und mit dem demnächst kommenden 100 mbit Internet werd ich auch nicht schneller als Medium machen. Aber müsst ihr selber wissen

Ums auszuweiten: Ich würde dir MPC-HC in 32bit empfehlen (mehr und schnellere Decoder vorhanden.

Dazu dann noch den Haali Renderer: http://haali.su/mkv/MatroskaSplitter.exe (In dessen Setup den Haken aus Associate MKV and MP4 to WMP entfernen)
Dann im MPC-HC unter Optionen -> Ausgabe den Renderer auf Haali Renderer umstellen. Dann haste nochmals besseres Bild

Mit Installation des Haali Renderers kann auch DirectShow etwas mit MKV Containern anfangen, was dann das Einleseproblem via DirectShow von MKV Dateien bei MeGUI löst.

Aber eig. ist das Zusammenmuxen unnötig. Für mehrere Quellvideodateien haben wir den AVS Generator von Lucki.

Zitat

Aber woran könnte das denn liegen, dass es so massiv länger dauert?

Videomaterial komplexer? (z.B. weil neues Spiel? )

Zitat

Wie gesagt, fürher konnte ich in Handbrake mit crf 22 in unter 30 minuten rendern auch mit 720p.
MeGUI brauchte immer ca Stunde, ist aber insgesammt schneller, da ich so mit debugmode nicht in vegas rendern muss.

Beide Programme sind GUIs für den x264 Encoder. Encoden tut x264 und nicht das Programm.

Zitat

CPU Auslastung ist auch fast dauerhaft auf 100%

Was dir sagt, das x264 die CPU sehr effizient ausnutzt und deine CPU nicht mehr her gibt an Leistung.

Was CPU anbelangt biste mit Intel sowieso besser dran als AMD.
Vieles ist auch nicht parallelisierbar.

Mehr Power auf den einzelnen Kernen ist also gewinnbringender als zb ein AMD 6-Kerner mit weniger Leistung auf einem Kern im Vergleich zu Intel.

Zitat

Okay rendern und so klappt alles aber wie bekomme ich da noch meine Audio-Spur von Audacity rein?

Falls es um Fraps+Audacity geht:

Luckis AVS Generator benutzen. Alternativ den umständlicheren Weg: Den Fraps Ton encoden nach FLAC, die FLAC in Audacity zur Stimme hinzu importieren. Als WAV exportieren. Die neue WAV bei MeGUI als Audio Input.

Und dann nur 1mbit Upload? Oder 1 megabyte/s ? Falls ersteres: Wie beschissen isn das?
Ich hab mit meinem 32mbit Internet bereits 2 mbit Upload.
Beim 100er würd ich dann 6 mbit Upload kriegen
Aber 1 megabyte/s? Wer gibt denn 1 megabyte/s?^^
Oder nicht in Deutschland?^^

Bevor ich die Encodierzeit verschneller würd ich persönlich bei solchem Internet die Qualität aufreißen. Wenn ich das 100er habe werd ich erstmal schön CRF 15 ausprobieren

Zitat

Macht es Sinn in RGB aufzunehmen oder ist der Qualitätsgewinn zu gering?

Am Ende der Kette haste exakt null Qualitätsgewinn.

x264 gibt standardmäßig in YV12 aus. Und das zu ändern wäre absolut unwirtschaftlich.

2048x1152,30fps Video mit x264:

RGB: 1,72 GB
YV12: 800 MB

Irgendwie isses das echt nicht wert. Außerdem selbst wenn es das wert wäre: Spätestens Youtube encodiert mit YV12. Von daher hast du mit einer höheren Aufnahme & Encode als 4:2:0 genau NULL Vorteile. Spätestens auf Youtube isses das selbe als wenn du direkt in 4:2:0 aufgenommen hättest.
Ich kann Youtube auch vollkommen verstehen das sie da nicht mehr als 4:2:0 benutzen. Ich würde es selber mit x264 auch nicht tun. Der Dateigrößenanstieg steht in keinerlei gutem Verhältnis zu dem absolut marginalem Qualitätsgewinn. 4:2:2 würde ich für kleine Schriften ja in Erwägung ziehen, aber das würde dann höchstens privat Sinn machen und man muss sich den Dateigrößenanstieg für den kleinen Gewinn bewusst sein.
Wie gesagt: Auch nicht mit VLC angucken. Dieser Player ist einfach Grütze. Da wunderts einem nicht, wenn du mit YV12 schlechtes Bild hast.

Wegen dem Youtubevideo? Mit MKVMergeGUI ohne Kopfdatenkompression gemuxt?

Zitat

Aber kann ich nicht vielleicht irgendeine Einstellung verstellt haben, die so ausschlaggebend ist, dass es 5 mal so lange dauert?

Guck mit Mediainfo einen alten Encode an und einen neuen und vergleich die Encodiereinstellungen.

Zitat von CHAOSFISCH

Aber ich kann ehrlich gesagt keinen Unterschied feststellen.

Der ist aber vorhanden. Ich kann ihn durchaus auch sehen bei kritischen Stellen. Man muss halt wissen, wo man hinschauen muss.
Aber darum gehts ja nicht. Sondern drum dass der Re-encode von Youtube besser ausfallen wird, wenn man besseres Material hochlädt.

Zitat

Hängt die Arbeitsgeschwindigkeit mit vom "Rechenaufwand" des Lazcos-Filters ab?
Sprich: Wenn er von 720p auf 1080p skalieren muss, ist er langsamer, als wenn von von 1904*1071 auf 1080p skaliert?

Ja. Schneller würde es natürlich gehen wenn du den Filter nicht benötigen würdest. (Der Filter muss ja diese Umrechnung machen und Lanczos4 macht das ja schon sehr hochwertig).
Ich zb brauche den Filter nicht, da ich ja eh in 2048x1152 aufnehme.
Filter kosten halt zusätzliche Zeit. Das ist ganz normal.

Scriptinhalt bitte posten.

Oh und bitte auch Mediainfo des Videos.

http://mediainfo.sourceforge.net/de (Achtung beim Setup, das hat viele Haken die du entfernen solltest (ist son setup mit zusatzsoftware, kennt man ja. Also die 3 Haken entfernen und auf ablehnen drücken).

Damit die Datei öffnen, die Ansicht auf Text stellen und den Text hier reinkopieren.