kann ich dann bedenkenlos auf 60fps aufplustern ohne dass es nicht wie unechte 60fps wirkt?
Wofür? Lad doch in 50 hoch.
Die Platte sollte 60 aber locker packen.
Beiträge von De-M-oN
-
-
Sättigung etwas erhöht
warum des O.O
Hoffentlich nich wegen tv vs pc range ausgleich XDSpline 100
würd ich mittlerweile spline36 nehmen.
Wenn man die Aufnahme neu muxed, also über avidemux müsste das bei avi gehen, dann ist ja nicht mehr Frame, Ton, Frame, Ton, usw...
Sonder ganzes Video, ganzer Ton, was das abspielen der Datei deutlich vereinfacht für die CPU, was bei mir bisher das Laggen in der Aufnahme bisher immer behoben hat.non-interleaved ist für'n En- und Decode eines Einzelstreams (nur video wird decodiert zb) von Vorteil, aber sowie beides genutzt wird - sprich vor allem beim Abspielen, ist non-interleaved eher sehr langsam, weil die HDD ja ständig mitm Lesekopf riesige hin- und her sprünge machen muss dann. Da wäre interleaved sehr anzuraten.
-
Eine höhere Auflösung würde bei dem, was ich mache (größtenteils Videos über Spiele, die manchmal nicht mehr als 640x480 Pixel darstellen konnten), keinen Sinn ergeben
Natürlich würde es das. Du solltest es eig. mittlerweile mitbekommen haben das Youtube auf höherer Auflösung bessere Videoqualität schmeißt. Und auch bei alten Spielen ist 1080p nicht das gelbe vom ei.
-
stellt Premiere immer statt anstatt der im Video vorhandenen 44,1 khz 16 bit Stereo
eben 44,1 khz 32bit floatpoint Stereo ein.Das ist nicht schlimm. Bittiefen upsampling kostet keine Qualität.
Würde dir aber empfehlen in 48khz und 24bit aufnehmen und es später mit einem guten ditherverfahren auf 16bit exportieren.
Bei 24bit hast du mehr spielraum bis zum clipping und die filter haben mit 24bit eine bessere basis. -
-
Naja er benutzt ja bereits avisynth und da liester dann halt 2 statt nur 1 video ein, seh das problem nicht ;D
-
Du machst statt 1 Video, 2 Video in SSM.
-
Würdest du bei 10mbit upload noch auf 20 oder 19 runter gehen mit CRF?
Auf alle Fälle.
FPS würd ich mind 50 machen. Erst dann kommt das Bild richtig schön weich. Am besten 60. Ich mach 50 weil meine Capture Karte bei 2560x1600 RGB nicht mehr als 51 fps bringt.
-
Wenn du mit Afterburner lossless aufnimmst, ist das eh die wesentlich bessere Option.
-
Weshalb ich dann eher beim nativen 1080p bleiben würde, denn mein Monitor macht nicht mehr (1920x1200 Monitor)
Wenn du die 1920x1200 belassen würdest, hättest du a) keine Skalierung b) 3-fache Bitrate auf youtube c) Keine Ränder auf Vollbild mit deinem Monitor -> 3 Fliegen mit einer Klappe :O
-
im falle 16:9 musste 2048x1152 nehmen
-
DooM 2016. Will aber erst paar Patches abwarten und vor allem eine bessere Grafikkarte.
-
Beim Klonen muss die Auflösung der beiden Geräte identisch sein.
Wenn die Karte da nur 720p liefert ist das natürlich schlecht. Die Karte muss auf 1080 laufen, wenn auch dein Monitor 1080 hat. Sagt ja schon die Logik, denn die Grafikkarte dupliziert ja nur die erste Ausgabe auf die 2. Ausgabe.
-
2160p 22.000 kbit/s (H.264) ~ 34.000 kbit/s (VP9)
ohne bitratecap mittlerweile
Zumindest bei den Kanälen wo es eben so ist.Ist tatsächlich richtig, solang du das lokal betrachtest, nicht umsonst schreiben die extra dabei das man sich extra an die angegebenen Formate halten soll, da der frühere Flashplayer gar nicht damit klarkam, mittlerweile geht es besser mit dem HTML5 äquivalent.
Auch der Flash Player konnte schon 4k
nicht richtig, es wird das format der hochgeladenen Datei angezeigt, das ja weiterhin 1152p beträgt, die umrechnung im player erfolgt jedoch tatsächlich als downscaling auf 1080p
blödsinn. Der Trugschluss kommt vllt das du einen 1080p monitor hast.
nicht richtig, es wird das format der hochgeladenen Datei angezeigt, das ja weiterhin 1152p beträgt, die umrechnung im player erfolgt jedoch tatsächlich als downscaling auf 1080p, wir haben uns einen vereinfachten player im code mal genauer in der uni angeschaut und da wird wirklich pixelinformation abgerufen bzw umgerechnet beim scalieren. sprich wenn der player so eingestellt ist das 1920x1080 Pixel rauskommen sollen, dann helfen da auch keine virtuellen Pixel oder ähnliches, die informationen werden entsprechend einfach nicht genutzt, die nächste freigegebene playerstufe wäre ja 1440p sprich um ein wesentlich besseres Bild zu bekommen müsstest du das entsprechend in 1440p abspielen, damit deine GrafikKarte das dann wieder in 1080p umrechnet (davon ausgegangen das du keinen 4K monitor besitzt) das ganze hin und herrechnen wirkt sich statistisch gesehen auf die gesamtfehlermenge aus, die halt nicht mal eben durch eine parität wieder "korrigiert" werden können. Simple Rechnung: 1920x1080 = 2073600 Pixel sagen wir jeder Rechner macht 1 promill Fehler sprich in einem bild hast du 2073 Fehler so jetzt macht das aber nicht nur dein Rechner sondern auch der YouTube Rechner und der Endgerät Rechner dann bist du schon bei ~3 promill Fehlern und jedes mal umrechnen bringt einen weiteren Rechenschritt hinzu sprich ein weiteres Promill, sodass du mit der Methode wie du es zZ hochlädst @Spieluin eine wesentlich höhere Fehlerdichte aufweist, wie zB bei einer CBR (was schon mal ein Rechenschritt ist der unnötig ist) aber wenn du das jetzt auf Maschinencodeebene betrachtest wird das immer absurder und absurder ich mein bei nem 23min Video (1380sek = 41400 frames [bei 30FPS] ) hast du 85.847.040.000 Pixel und somit mindestens ~850mio Fehler in dem Video hast. wohingegen die andere Methode "nur" ~400mio Fehler hat allein schon durch die zusätzlichen Rechenschritte. Die Zahlen sind grob gerundet aber man sieht doch schon nen deutlichen Verlust der eigentlich durch das verschlimmbessern kommt. Natürlich habt ihr recht wenn ihr mit einer VBR einen Kompromiss zwischen Kompression und Leistung finden wollt, die CBR ist rein rechnerisch allerdings der VBR mit nur ~ 50% so vielen Fehlern im deutlichen Vorteil. Und das mit dem Player hatte ich ja auch schon erklärt! Hoffe ihr versteht die Argumentation.
Ich hab das zitierte hier nur bis zu den ersten paar sätzen gelesen, und den thread bisher noch nicht weiter gelesen, einfach weil es bis hierhin schon zu sehr weh tut was für ein Müll hier steht.
Alles anzeigenCodeAlles anzeigenCode
2048x1152 bzw 1920x1200 bei mir im Falle 16:10
ist ganz klar kein Unterschied zwischen1920x1080 bzw 1728x1080 bei mir im Falle 16:10
http://www.abload.de/gallery.php?key=a31jj3lv
Da ist auf gar kein Fall ein Unterschied zu sehen.
Und das ID 315 von Youtube sogar ohne Bitratecap läuft (sprich das was man ab 1750 Pixelhöhe bekommt) und mit einem recht guten CRF läuft, ist selbstverständlich auch kein Unterschied zu 1920x1080 mit nur 5000 kbit Bitrate (wenn High Framerate, sonst noch weniger)
2048x1152 läuft mit bis zu 15 mbit Bitrate und die Datei liegt sehr wohl auch in 2048x1152 vor. *facepalm*
Abtastrate: 96 kHz (Schwachsinn, Youtube Codiert hauptsächlich in 44,1 kHz), 48 kHz (Teilweise, die 1440/2160o@60 haben Opus das mit 48 kHz Codiert wird, wobei aber gegenüber den anderen Stufen die Bitrate reduziert wurde...)
Ich würd die 48khz nutzen. So muss Opus nicht upsamplen und auf VP9 läuft halt Opus.
Opus supported nur 48 khz, jedoch wurde die Bitrate von Opus von 160 auf 128 reduziert.
Nun laufen AAC als auch Opus in 128. Was aber noch ok ist bei der Effizienz dieser Codecs.edit: Ok habs nun ganz gelesen. Naja immerhin haste nun gerallt das bei 2048x1152 die bessere Qualistufe läuft. Aber anfangs dachte man wirklich nur so wtf teste es doch wenigstens mal bevor du sowas erzählst ala 2048x1152 sähe schlechter aus und diesem wirrwarr.
Und nein Youtube belässt es auf 2048x1152. Warum sollten die das auch umändern.
-
MagicYUV gehört nicht dazu. UtVideo schon, soll aber etwas langsamer laufen als die VFW-Variante.
nicht soll, das ist einfach so. War schon mir durch doom9 forum bekannt, das der originale Decoder performanter ist, aber gerade bei OBS konnt ich das dann auch brutal merken.
__
naja schärfere Resizer machen es noch schlechter komprimierbarer und drückt dann natürlich auch auf die Youtube Ergebnisse. Spline36 ist ein neutraler Skalierer. -
Weil ich dachte, dass von mp4 -> mp4 weniger Verlust bedeutet als von mp4 -> Rawavc. Weil die Qualität eben wie du schon sagtest bereits sehr drunter gelitten hat.
der Container hat ja nichts mit dem inhalt zu tun
Bei rawavc haste dein video roh. (Kein container) -
bei CRF18 musses sauber sein.
10bit encoding würde noch banding verhindern. Dann bliebe lediglich noch das 4:2:0 chroma subsampling über.
Evtl nimmt deine kamera eh nicht höher als 4:2:0 auf.
Das krisseln was du beschreibst klingt aber eher nach noise. Und noise kommt von deiner kamera. Und je schlechter die Lichtverhältnisse sind desto mehr noise produziert deine Kamera.
Es gibt aber bei avisynth sehr gute denoiser.
Aber da würdest dich dann von magix trennen müssen.
Avisynth ist insbesondere für Videorestauration sehr gut geeignet.
Noise erhöht die Dateigröße deutlich, verlängert den encode und kann durch schlichter höherer bitrate nicht beseitigt werden, da dieser Bestandteil deines Quellvideos und der Encoder denkt somit natürlich das es schlicht detail ist den du behalten willst und investiert entsprechend encodingaufwand und datenrate hinein, wobei 6std etwas unrealistisch erscheinen je nach länge des videos. -
Ich würde aber nur grob draus schlüsse ziehen, da sie einfach durch zu vielem verfälscht wird.
Video bearbeiten = 1 view = doofe Watchtime
Kommentarlink in E-Mail führt auf Videoseite, Video bekommt aufruf und schlechte Watchtime weil du oder der Zuschauer lediglich auf den Kommentar eingehen wollte.
[...] -
Wenn du es weg lässt, wird der Encode minimal schneller.
Wenn nicht nach 4x4 Partitionierungsmöglichkeit gesucht wird, geht es deutlich schneller schon.
4x4 Blöcke finden Anwendung bei detailreichen Videos, wo 4x4 weniger groben Übergang liefern kann als 8x8. Das kann also Anwendung finden bei zb Texturen mit hoher Detaildichte (feine Maserungen einer Kieselsteinwand oder ähnliches)Einfach aus dem Grund das Filme Block Fragmente aufweisen, die mit Deblock nachgebessert werden können. Bei Spiele hat man diesen Effekt nicht.
Deblock ist schlichtweg der deblocking Filter für die DCT Kompression. Das findet auch bei Lossless Quellen Anwendung, wenn der Encoder dies als nötig empfindet. Bei stärkerer Kompression halt.
Damit werden die Blöcke etwas geblurt, dafür aber die Blockübergänge weniger sichtbar. Dies hat bei einer starken Kompression einer enormen Qualitätssteigerung zufolge.http://encodingwissen.de/codec…-inloop-deblocking-filter
Mit den beiden Parametern bestimmst du halt wie empfindlich er reagieren soll und wie stark er arbeiten soll.
Psy Optimierungen einfach weg lassen.
Das wäre schlecht. Das trägt nämlich groß zur Kompression bei.
Für Spielevideos ist aber der default psy absolut in Ordnung.Die PsyRD (psychovisuelle Stärke) ist ebenfalls für bereits verlustbehaftetes Material vorgesehen
Nein ist er nicht. Deblocking als auch die psy optimierungen sind fester Bestandteil eines H.264 Encodes und sind eines der vielen Gründe, warum H.264 effizienter als xvid ist.
Dabei spielt es keine Rolle ob die Quelle Lossless oder Lossy ist. Bei Lossless lassen sich diese Techniken jedoch besser anwenden. -
Ich habe meinen Livestream von Twitch auf YT exportieren lassen und mir dann als mp4 gezogen. Wenn ich damit jetzt einen Zusammenschnitt in Vegas machen und dann über SSM/MeGUI encodieren will, was wähle ich bei MeGUI aus? Einfach Fileformat mp4 statt Rawavc und bei audio weiterhin zu flac konvertieren?
Warum ändern? Encodier doch ganz normal wie immer. Nur sei dir bewusst, das dem Material mittlerweile ganz schön Verlust ausgesetzt sein wird bei all den transcodes, die es hinter sich hat (Dein Stream, Youtube, nochmal x264 etc). Und der Audio leidet darunter ja ebenso langsam sehr.