Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenKönnte auch sein das sein [lexicon]Magix[/lexicon] die [lexicon]FPS[/lexicon] falsch verwertet. Immerhin wird von 25 auf 30 gegangen. Eventuell wird beim Hochinterpolieren alle paar Sek. ein Pulsieren wargenommen, anhand der falschen Änderung.
[lexicon]FPS[/lexicon] eines Videos niemals ändern bei einer [lexicon]NLE[/lexicon].
Habe letztens aus Langerweile über die [lexicon]PS3[/lexicon] auf Youtube mit ein [lexicon]Doom[/lexicon] LP reingezogen von @De.M.oN. xD
Meist schau ich über die [lexicon]PS3[/lexicon] auf Youtube entweder normale Serien oder Filme. Ab und an mal ein LP.
Über mein Rechner mach ich das kaum, einfach weil ich, wenn ich schon am Rechner bin, andere Sachen zu tun habe, als nur noch auf YT mich zu tummeln.
Zudem bietet mir die Konstellation das die [lexicon]PS3[/lexicon] am Fernseher die YT Videos spielt, mir die Gelegenheit am Rechner andere Games zu zocken.
Wobei der 420er sich nicht mit guter [lexicon]FPS[/lexicon] Performance in Spielen gerühmt hat in vergangenheit.
Wobei UTVideo ja auch mal wieder aktualisiert wurde und eventuell der Fehler behoben wurde ;D
Der RTSS 6.4.0 ist zumindest Win10 Kompatibel. Die 6.3.0 Version nicht.
Das ist doch das neusten Verson oder RivaTuner Statstics Server 6.3.0 ?
6.4.0 ist der aktuellste.
http://www.guru3d.com/files_de…tics_server_download.html
Damit es funktioniert, muss der RTSS am besten Adminrechte besitzen.
Da du vorher mit YV12 aufgenommen hast, nimmste bei UTVideo halt YUV420 BT.709.
Riva Tuner:
Application detection level: High
On-Screen Display coordinate space: Framebuffer
Stealth mode und Custom Direct3D support: on
Multicore Optimierung: 4 Thread
Und halt statt [lexicon]Lagarith[/lexicon] mal den UTVideo [lexicon]Codec[/lexicon] verwenden.
Hab ich da irgendwo eine Einstellung übersehen
Einfach mal posten, weil wir sehen das nicht und können das somit sehr schwer deuten woran es liegt ;D
Einfach mal die Einstellungen des [lexicon]Afterburner[/lexicon] posten die du unter dem Punkt Video hast und einmal die Einstellungen des RivaTuners posten, bitte.
bzw. der [lexicon]Lagarith[/lexicon] nicht für 4k geeignet
[lexicon]Lagarith[/lexicon] ist etwas träge, ja. Nimm am besten dafür entweder UTVideo: Download oder [lexicon]MagicYUV[/lexicon]: Download
In Spielen viel mit Bewegungsunschärfe am besten zocken, sofern das Spiel sowas anbieten tut.
Das würde dem Video auf YT später sehr gut bekommen.
Wie bekommen wir die Fragemeldung wie eingeschaltet in [lexicon]MeGui[/lexicon] ?!???
Zuerst Sicherstellen das [lexicon]MeGUI[/lexicon] geschlossen und aus ist 
Im [lexicon]MeGUI[/lexicon] Verzeichnis die Datei Settings.xml mit dem Notepad/Editor von Windows öffnen oder via Notepad++.
Suche dann die Zeile:
<AddConvertToYV12>true</AddConvertToYV12>
und ändere sie in
<AddConvertToYV12>false</AddConvertToYV12>
um.
Dann starteste [lexicon]MeGUI[/lexicon] wieder und er sollte dir dann auch wieder die Frage stellen.
Wenn du z.B. in 1080p schon aufnehmen solltest, so fehlt dir ja nicht mehr viel bis 1152p. Da bräuchtest du dann keine Faktoren Skalierung zu verwenden. Da reicht wirklich dann ein neutraler Skalierer wie Spline36, Spline16 oder Spline100 aus.
Bei 720p Aufnahmen würde ich eine Faktorenskalierung empfehlen. 720p -> 1440 -> 1152
Erst die Faktorenskalierung mit einen Point Resizer und dann der Finale Skalierer mit halt Spline36, etc, pp.
Also wäre es ja fast besser gar nicht mit [lexicon]Spline64[/lexicon] auf 2048×1152 hochzuskalieren.
[lexicon]Spline64[/lexicon] ballert dir ordentlich Ringing Artefakte mit ein und skaliert sehr scharf. Daher benötigt ein [lexicon]Spline64[/lexicon] skaliertes Video sehr viel [lexicon]Bitrate[/lexicon] auf YT.
Du musst allerdings anders denken. Je neutraler ein Skalierer ist bzw. weicher, umso mehr [lexicon]Bitrate[/lexicon] wirst du von Youtube bekommen. Je weicher ein Bild ist, desto weniger [lexicon]Bitrate[/lexicon] wird benötigt und desto besser wird das Bild auf YT auch werden.
[lexicon]Auflösung[/lexicon] am besten die 1152p Marke nutzen beim skalieren.
PointResizer dienen bei RGB24/32 und YUV444 am besten in Faktoren zu skalieren. Das sind die schärfsten Skalierer die es gibt. Eine Faktor 2 Skalierung und anschließend ein Interpoliertes Downscaling würde einen weichen und doch scharfen Effekt mit sich bringen, wo [lexicon]Bitrate[/lexicon] recht gut gesparrt werden kann.
Und noch eine Frage hätte ich: Wie kann ich denn einstellen ob ich x64 oder x86 will?
[lexicon]MeGUI[/lexicon] -> Options -> Settings -> External Program Comfiguration
Unten Rechts steht dann irgendwo: "[lexicon]x264[/lexicon]: enable 64 bit mode"
Ist diese Option angehakt, so verwendest du den 64 Bit [lexicon]Encoder[/lexicon] von [lexicon]x264[/lexicon].
Ist diese Option aus, so verwendest du den 32 Bit [lexicon]Encoder[/lexicon] von [lexicon]x264[/lexicon]
Jetzt habe ich folgende Idee: Ich könnte doch statt --output -csp "i444" einfach wieder statt i444 RGB nehmen und den [lexicon]CRF[/lexicon] Wert auf 20 erhöhen. Würde das mehr Qualität bringen oder scheiterts dann wieder an dem höheren [lexicon]CRF[/lexicon] Wert?
Um diesen Effekt eines höheren Farbraum encodierten Videos zu sehen, so wie du es mit [lexicon]MeGUI[/lexicon] gemacht hast, sollten die nachfolgenden Kriterien vorher erfüllt worden sein:
Es darf nicht dieses Schema gelten:
YUV420 -> YUV422 -> YUV444 -> RGB24/32
Das letzte Schema beinhaltet Verlust der Farbe (Chroma) des Farbraumes. Eine Interpolation auf den nächst höheren Farbraum würde also 0 Effekt bringen.
Oft ist es so das User da einfach weiter klicken und mit ok bestätigen, aber sich die Frage gar nicht durchlesen die von [lexicon]MeGUI[/lexicon] da kommt. Bzw. haben die Meldung schon ganz ausgeschaltet.
[lexicon]MeGUI[/lexicon] versucht nämlich zuerst ein ConvertToYV12() ins [lexicon]AVISynth[/lexicon] Skript zu schreiben.
Somit würde folgender Effekt entstehen:
RGB32 -> YV12 -> YUV444
Und das ist Witzlos, da dann das Video nicht mehr Infos beinhalten kann als YV12. Da es der geringste Farbraum ist.
Die Frage ob [lexicon]MeGUI[/lexicon] das reinschreiben soll, muss mit nein geantwortet werden. Erst dann ist es möglich.
RGB32 -> RGB32 -> YUV444
Auch hier wieder ACHTUNG bei der Wahl des Encoders für [lexicon]x264[/lexicon] hinsichtlich x64 vs x86.
Die 32Bit Version kann jeden Farbraum nutzen.
Die 64Bit Version ist zusammen mit [lexicon]AVISynth[/lexicon] mit einer Pipeline gekoppelt die ledeglich nur YV12 (YUV420), YV16 (YUV422) und YV24 (YUV444) umgehen kann. Sollten falsche Farbinformationen an die Pipeline gelanden, wie RGB24 oder RGB32, so wird die Pipeline dafür sorgen das es ein YV12 Video am [lexicon]Encoder[/lexicon] ankommt.
Sprich wer die 64Bit Version von [lexicon]x264[/lexicon] bei [lexicon]MeGUI[/lexicon] nutzt, der sollte das Skript so abändern das er auf YUV444 konvertiert mit BT.709 als Farbmatrix.
Sehr leicht im [lexicon]SSM[/lexicon] z.B. einzustellen
Sind diese Kriterien nicht erfüllt, so wird man keinen Effekt ersehen können und hat im Endeffekt nur ein sehr großes Video in YUV444 kodiert was eigentlich nur YV12 Material beinhaltet.
PS: Man sollte sich auch nicht zuviel von diesem Effekt versprechen. Es ist nur ein Minimaleffekt, da YT dann wirklich mit dem saubersten Video was hochgeladen wird den YT-Encode vollzieht. Und dieser Effekt fällt meist besser aus, da keine Unreinheiten des Farbraumes (Interpolations Effekte) enthalten sind.
der Unterschied von rgb24 zu yv24 ist sehr gering, kleine rundungsfehler
Die sich aus den Farbkoeffizienten der YUV Farbmatrix beziehen bei der Umrechnung von RGB -> YUV oder YUV -> RGB.
ob ich das auf regelmäßig verwende zum [lexicon]Hochskalieren[/lexicon]
Dafür würde ich es nun nicht grad verwenden. Weil dadurch wird das Encoden danach ziemlich Zeitintensiv sein.
oder ob ich mir das für Videos aufspare, die nicht einlesbar sind.
Dafür sollte es am Besten gedacht sein. Auch um die Möglichkeit [lexicon]VFR[/lexicon] Videos mittels [lexicon]AVISynth[/lexicon] und den Plugins FFMS2 oder L-Smash in [lexicon]CFR[/lexicon] zu wandeln und in die [lexicon]NLE[/lexicon] zu laden. Das ist denk ich mal der tiefere Sinn dafür, bestimmte widerspenstige Videos ladbar zu machen^^
Der 5820K war mit alle Kernen so 50% ausgelastet warum er nicht 100% macht verstehe ich nicht jaja besser als über 7 stunden [lexicon]rendern[/lexicon] mit 1440p
Generell ist der [lexicon]x264[/lexicon] ein [lexicon]CPU[/lexicon] [lexicon]Encoder[/lexicon]. Zudem kommt noch hinzu das [lexicon]Encoder[/lexicon] [lexicon]Frame[/lexicon] für [lexicon]Frame[/lexicon] abarbeiten beim [lexicon]Encodieren[/lexicon] und nicht alle auf einmal nehmen beim Verarbeiten.
Sprich: Die [lexicon]CPU[/lexicon] Auslastung wird nur soweit ausgelastet wie es für die Frames die es verarbeitet gebraucht werden.
Bei [lexicon]x264[/lexicon] gibt es jedoch irgendwo eine Einstellung wo man die Grenze der Framevorberechnung erhöhen kann. Ergo würde die [lexicon]CPU[/lexicon] mehr ausgelastet werden. Zumindest glaube ich das es da was gab. @De-M-oN hatte mir da mal was gesagt gehabt das man das erhöhen bzw. senken kann.
Wieso sollte es dann qualitativ sinnvoller sein? Sinnvoller, ja, weil [lexicon]MAGIX[/lexicon] es sonst nicht lesen kann. Aber qualitativ sinnvoller ... müsste sich nix nehmen, ob [lexicon]AVISynth[/lexicon] zu RGB konvertiert oder die [lexicon]NLE[/lexicon].
Ja, da hab ich mich auch gefragt was De-M-oN da wollte xD
Ob nun [lexicon]AVISynth[/lexicon] das macht oder die [lexicon]NLE[/lexicon]... es wird konvertiert xD
Hau mal eine [lexicon]MediaInfo[/lexicon] von der [lexicon]AVI[/lexicon] des Frameservers raus.
Sind alles Unkomprimierte Formate
Unkomprimiertes YUV 420, 422, 444 oder halt Unkomprimiertes RGB
Zeile 2 sollteste deinen eigenen Pfad zur avfs.exe eingeben.
@RealLiVe
Thx
@GrandFiredust
Wo du das ? da herbeziehst weiß ich auch nicht. Aber eventuell steht es in der Batchdatei so drin. ;D
Batchdatein niemals vorher in Unicode speichern. Weil das Zeichensystem zwischen DOS-Console und Windows sind extrem unterschiedlich. Die ersten 127 Zeichen sind identisch, sofern ANSI genutzt wird.
