Hoffentlich ist TW3 da besser
Ich gehe mal davon aus das der neue Teil eher noch deutlich bessere Grafik haben wird. Von daher - eher nicht besser 
Beiträge von De-M-oN
-
-
Es liegt vor allem an der starken Vegetation. Rasen, Büsche etc haben auf Bewegung etwas zu viel Feinheiten, keine Ähnlichkeiten. Du brauchst für Komprimierung solide Flächen.
Animes zb lassen sich hervorragend komprimieren und da können auch unglaublich gut b-frames eingesetzt werden wenn es zur Verlustkompression kommt.
-
Meiner Erfahrung nach ist UTVideo YUV420 aus irgendwelchen mysteriösen Gründen sehr unperformant im direkten Vergleich dazu.
jup.
-
Das ist derzeit ein Bug
Wovon OverDev schreibt, ist ein Bug
Nein. Das ist Intention. Jede Wette.
Youtube will das der User bei Wahl von 1440p auch 1440p Video hat.
Youtube hat ja auch angepasst das da bei HFR nicht mehr stur 60fps steht, sondern die echte.Das bei Wahl von 1080p dann ein anderer Encode abgespielt wird, sieht der User ja ohne Nachforschung nicht.
Nein das wird kein Bug sein. Definitiv Intention.
Zitat von GrandFiredustProbier es erstmal mit 2560×1440, da ich glaube dass [lexicon]Magix[/lexicon] 1152p nicht akzeptiert.
Tut es.
ZitatWird das am ende nicht in youtube als 1440p angezeigt?
Nope. 1080p wird durch deren 1440p codierung dann ersetzt.
Erst bei 2560x1440 läuft 1440p seperat.
-
Ich benutzt 3 Threads - egal ob RGB oder YUY2.
RGB zieht aber mehr Leistung als YUY2.
Wie das beim Drachen andersrum sein kann ist mir ein Rätsel.
Auch die Framekompressionszeit wäre mir bei 2560x1600 mit nur 1 Thread zu viel.
-
schon versucht aber bedenke das ich nebenher auch Aufträge für Firmen rendere (Texturen,3D Meshing/Sculpting) und es sich nicht so verträgt. (Schließlich muss ich ja auch Arbeiten und Geld verdienen )
Schnelleres [lexicon]x264[/lexicon] Preset = Schnellerer Encode.
Irgendn Preset wird dein Geschwindigkeitsnerv schon passen. Alles eine Sache der Konfiguration. Und [lexicon]x264[/lexicon] ist gewiss nicht langsam. Im Gegenteil, sogar schneller als andere Software - nur hat [lexicon]x264[/lexicon] auch komplexeres Encoding - und wenn du mehr Speed willst, dann musstes halt dahingehend einstellen.
Was auch ordentlich Dampf bringt wäre bei b-frames eine 0 einzutragen und reference frames auf 2. Kann aber auf die Dateigröße drücken. B-frames sind der Kompressionseffizienz sehr dienlich - können aber beschwerlich eingesetzt werden bei Spiele. Bei Point&Click würd ich sie aber da lassen. b-frames spielen ihre effizienz bei ruhigen szenen aus, wo sich die Frames nur marginal untereinander unterscheiden. B-frames sind besonders hilfreich bei Animes oder halt point&click spiele etc. B-frames weglassen kann aber doppelte encodespeed bedeuten.
Wenn man so Spiele wie Arma oder ähnlich schwer komprimierbares Material hat, wird es einem weniger schmerzen b-frames wegzulassen.B-frames weglassen würde ich des weiteren nur bei diesen [lexicon]CRF[/lexicon] (constant rate factor / constant quality) encodes. Bei bitratenfixiertes encoding wäre das nie im Leben ein gedankengang.
-
Die Erklärung wäre also erst dann wirklich korrekt gewesen, wenn ich das Beispiel umgedreht hätte, also von mehr nach weniger FPS?
Das hängt vom Konvertierungsverfahren ab.
Vegas' sein doofes Resampling sortiert nicht frames raus, sondern behält alle frames via überblendung. Darum der [lexicon]Ghosting[/lexicon] Effekt. Bzw besser gesagt - die Inhalte der überschüssigen Frames werden auf den übrig gebliebenen Frames angewendet (überblendung)
Du hast aber kein [lexicon]Ghosting[/lexicon], wenn du die überschüssigen Frames einfach rauslöscht, ohne dessen Inhalt auf den vorigen und nächsten [lexicon]frame[/lexicon] zu übertragen, sondern eine simple stupide rauslöschung.
-
Letzteres ist das, was wir haben wollen. Da tritt dann auch kein [lexicon]Ghosting[/lexicon] auf oder sonstwas.
Wobei auch von 25 auf zb 45fps kein [lexicon]Ghosting[/lexicon] entsteht. Das passiert bloß dann, wenn man zb bei FPS änderung von 45 fps auf zb 25 fps runter die Frames nicht rauswirft, sondern überblendet - und sowas macht Vegas leider standardmäßig und daher gibt es viele [lexicon]Ghosting[/lexicon] videos auf yt.
-
Kannst du mir noch sagen Drache, ob es auf Youtube dann nicht mehr ruckelt, wenn ich es nun ohne Encodierung hoch lade?
Falles es wirklich nur am Decodespeed hapert - dann ja.
-
Das Video hat auf der 1080p Stufe die 1152p. Ich habe es so encodiert..
Nein hat es nicht. Es ist allgemein bekannt, das bei HFR derzeit nur bis 1080 encodet wird. Dein Video jedoch hat 50fps.
Und wenn dein Video mit CRF18 und 2048x1152 bereits schon 42 mbit [lexicon]bitrate[/lexicon] braucht - ist es kein wunder das es auf yt nicht gut verendet.
Aber wenn du nichtmal ingame [lexicon]Motion Blur[/lexicon] verwendest biste mit Arma auf yt erstrecht am Arsch. Da wäre schon fast der Rat in 1st person zu spielen. Eine Simulation in 3rd person zu spielen klingt jetzt auch ein bissl fragwürdig xD
-
Wo genau finde ich jetzt die Log
In [lexicon]MeGUI[/lexicon]'s Log ordner.
ZitatIst das Format iwie besser oder warum das anstatt [lexicon]MKV[/lexicon] ? Muss ja einen Grund haben
Dann wird der rohe videostream geschrieben und nicht in [lexicon]MKV[/lexicon] gemuxt. [lexicon]x264[/lexicon] benutzt kein mkvmerge, sondern haali.
Und den haali [lexicon]mkv[/lexicon] muxer find ich ehrlich gesagt ziemlich scheiße und der schrieb auch in deinen Header so'ne Schmu [lexicon]GOP[/lexicon] Werte rein.
Außerdem wenn du roh schreibst fällt der [lexicon]MKV[/lexicon] muxvorgang seitens [lexicon]x264[/lexicon] ja dann auch weg - sprich die Datei wird schneller bei Encodeende geschlossen.
Auch ist es so dann einfacher für MKVMerge - als wenn MKVMerge komische werte sieht von einem schlechten Header.Und [lexicon]muxen[/lexicon] tuste ja wegen Audio eh nochmal. Also ist 2x [lexicon]muxen[/lexicon] sowieso ja unnötig.
-
Ich meinte damit compress-as-is.
Damit wird das Video doch überhaupt nicht (verlustfrei) komprimiert.
Lesen
compress as is heißt : Komprimiere es so wie es ist.
Geht RGB ein wird in RGB geschrieben. Würde 4:2:0 eingehen würde er 4:2:0 schreiben usw.
Zitat von GelberDrache92Mit dem Parameter qp=0
Der parameter ist --qp 0
[lexicon]OBS[/lexicon] fährt da bloß sein eigending.
-
Bilder der Config, also da wo der [lexicon]x264[/lexicon] Eingestellt wird.
Nein die Log.
Und für [lexicon]x264[/lexicon] config tuts die commandline - diese geht letztendlich an den [lexicon]encoder[/lexicon]. Wozu Bilder? Und die commandline hat er ja schon genannt und steht in der [lexicon]Mediainfo[/lexicon] auch nochmal.
Aber generell: [lexicon]MeGUI[/lexicon] Log. Da steht script encode, farbkonvertierungen und alles was man wissen will drin.
ZitatFormat_Settings_GOP : M=1, N=2
Das sind jedoch seltsame Werte.
Stell bei [lexicon]MeGUI[/lexicon] : rawavc als format ein und nicht [lexicon]mkv[/lexicon] und muxe später dann mit mkvmerge in [lexicon]mkv[/lexicon].
-
Bilder von [lexicon]Megui[/lexicon] reiche ich noch nach. Was brauchst du da denn alles genau ?
Die Log. keine Bilder bitte.
-
Bilder von [lexicon]MeGui[/lexicon]
Log von [lexicon]MeGUI[/lexicon]. Will kein Bilderbuch.
[lexicon]MeGUI[/lexicon] log vom letzten encode. Da steht auch script usw alles drin.
____
Beschreib doch mal das Problem. Was genau gefällt dir denn nicht? -
Ingame [lexicon]Motion Blur[/lexicon] verwenden. Ist besser als auf 2D Frames aufgetragenes Motionblur - was zudem auch richtig hart die Encodespeed ausbremst.
Bei 10bit YV24, CRF14 sollte die lokale Qualität aber fantastisch sein
-
Ich hab auf einigen Videos bei denen Ich weiß dass meine Zuschauer sie so oder so sehen wollen lange Werbung geschaltet und noch einen einzigen Kommentar darüber erhalten, wenn man's nicht auf jedes 2-minütige Video klatscht ist es wohl in Ordnung für die Zuschauer
Kanalwechsel ist halt leichter.
-
[lexicon]TMPGEnc[/lexicon] 6 ist nice.
Man kann nun mit gedrückter rechter maustaste nen bereich markieren und den mit entf taste raushauen - und audio wird dabei mit berücksichtigt - von daher endlich kein extra schnitteditor mehr - endlich vernünftiges cutten möglich
Allerdings hab ich immer noch paar Dinge - die zwar nicht tödlich sind - aber dennoch mich stören und habe es denen daher mal auch geschrieben, und zwar das hier.
ZitatAlles anzeigen[lexicon]x264[/lexicon]:
-> Why I can't set slices to zero? Slices reduce efficiency and aren't necessary for standard [lexicon]h.264[/lexicon] encodes. They are only necessary for hardware player - but I dont encode for hardware player.
-> Why is at encoding mode: Quality based (meaning [lexicon]CRF[/lexicon] encode) the max [lexicon]bitrate[/lexicon] value forced? [lexicon]CRF[/lexicon] doesnt need that and the sense of [lexicon]CRF[/lexicon] is that you dont limit it with [lexicon]bitrate[/lexicon] - the sense of it is to have a visual consistent quality for each [lexicon]frame[/lexicon]. Default should be that vbv-maxrate and vbv-buffer is deactivated so that you can enable them optional if you really want it. But its a bit bad that its forced.
-> Why I can't set max [lexicon]GOP[/lexicon] length to zero? zero would mean --keyint-infinite means an unlimited [lexicon]gop[/lexicon] length. [lexicon]x264[/lexicon] supports that - and yes it will make seekability bad - but I dont need that. It is for youtube anyway.
-> Why does the AVI [lexicon]Decoder[/lexicon] only read the first audio stream of a AVI file? I have 2 audiostreams in my avi file - but [lexicon]tmpgenc[/lexicon] sees only the first.
-> General suggestion would be in general to offer a custom commandline where you can set options which have higher priority over the [lexicon]GUI[/lexicon] - Then I could set for example myself an infinite [lexicon]GOP[/lexicon] length etc.
-> For the quality setting - you changed [lexicon]crf[/lexicon] value to a quality % value - can you maybe show in a bracket the correspondend [lexicon]crf[/lexicon] value of it? Its a bit awkward to do the math.
-> Good would be [lexicon]encoder[/lexicon] updates - instead of having to wait for a whole new program version to get new [lexicon]encoder[/lexicon] versions.
I would looking forward for an answer to this mail. Thank you
Und bin mal höchst gespannt ob und was sie drauf antworten.
-
Wofür kauft man sich denn sonst eine Konsole?
Weiß ich nicht. Andere scheinen daran ja lieber zu spielen^^
-
Ich habe nix gegen Konsolen. Ich habe aber was gegen Exklusivtitel und gegen hingerotzte PC Ports.
Ich kauf mir doch keine Konsole nur weil das Spiel nur für Konsole gibt - ne wirklich dann hol ich mir lieber 'nen Emulator. Und wenn die Konsole zu neu ist ala gibt noch kein Emulator dafür - dann warte ich halt - ich hab zeit.
Am Emulator kannste eh noch die Grafik aufbohren - insbesondere bei älteren Konsolen - wo du alleine schon durch die Kabelverbindung schlechtere Qualität hast als am Emulator der dir RGB Ausgabe liefert ohne irgendwelche Verluste durch composite oder sonstigem kabelgedöhns. Mal von Anti aliasing filter ganz zu schweigenAußerdem muss ich dann nicht mit 'nem Gamepad rumfuchteln ich kommt mit den Dingern aufn tot nicht klar. Was eig. sehr schade ist, denn ich würde sehr gerne mal Mortal Kombat zb spielen - aber für solche Spiele machtn Gamepad leider sinn. Aber ich kann damit einfach nicht umgehen
Die meisten Spiele kommen aber zum Glück eh für'n PC die ich mag.
