Afterburner muss eig. gehen. Der kann Vulkan. Vllt RTSS nicht aktuell?
Im Afterburner Setup könnte noch eine ältere Version drin sein. Man kann den RTSS auch seperat updaten.
Beiträge von De-M-oN
-
-
Hochskalieren würd ich erst nach der Aufnahme machen. Sprich beim finalen Encode, weil während der Aufnahme wirds viel performance kosten.
-
De-M-oN: Danke für deinen Kommentar. Ich lass mir auch gerne etwas erklären oder mich verbessern, aber diesen Oberlehrer-Style kann ich nicht ab.
Naja 720p auf Youtube als kristallklare Quali zu betiteln war halt etwas merkwürdig, weshalb ich dich da einfach fragen musste wie lang du schon youtube nutzt^^
Und julien hat dir geholfen? MagicYUV ist auch verlustfreie Kompression xD Aber daran ist auch nichts verkehrt bei der Aufnahme.
-
Ja aber ich dachte es geht die ganze Zeit um den eigenen Encode? :3
Möglicherweise hab ich dich falsch verstanden. Auf mich klang das so, als wolltest du sagen, youtube encodiert die Videos in 24 mbit und wenn in 1440p hochgeladen auch die 1080p in 24 mbit
Aber dennoch muss ich wohl was korrigieren. Denn youtube beschränkt sich da gewiss nicht auf 24 mbit bei der Eingangsquelle. Wäre im Gaming auch bei den meisten komplexeren Spielen viel zu wenig Bitrate um ein für's Auge komplett verlustfreies Bild zu kriegen. So sollte das Quellvideo aber mindestens beschaffen sein, damit Youtube das beste aus ihren niederen bitraten aus dem Video noch retten kann. Gerade bei niederen bitraten braucht man die maximale effizienz des encoders und die wird nunmal erhöht, wenn das quellvideo möglichst sauber ist und nicht schon bereits verlust enthält. Daher verlustfrei für's Auge mindestens. Und da ja einige hier Tomaten auf den Augen haben und etwas als verlustfrei fürs auge betiteln was eindeutige, sichtbare kompressionsartefakte aufweist, solltet ihr noch einen Puffer anlegen ;D
Am sichersten wäre halt ein CRF oder CQP Encode. Sprich gar nicht erst bitratenfixiert codieren.... Aber das geht ja mit 99% der windows timeline programme nicht,zudem haben sie keine guten Encoder, was eines der gründe ist, weshalb ich diese programme einfach nie empfehlen kann. Ihre Encoder sind halt einfach alles andere als gut und dazu halt nur bitratencoding..
Bei deinem Doom 3 LP würd ich mir persönlich auch etwas mehr Quali wünschen
Weil:
bei 1080p erlaubt YT eine Bitrate von maximal 12k, also die Hälfte wie als wenn du in 1440p hochgeladen hättes
hauptsache die höhere Bitrate wird zugelassen.
Das stimmt halt so einfach nicht. Du darfst 1080p auch in 100mbit hochladen. Nur deren Transcode wird bei 1080p eben nur 3,5 mbit geben. Aber auf den 3,5 mbit bleibt halt mehr Qualität über bei einer in dem beispiel 100 mbit quelle gegenüber einer 12 mbit quelle, da der Encoder bei der 100 mbit quelle halt ein besseres input material hatte mit dem er besser arbeiten kann.
Da aber 3,5 mbit einfach erstrecht viel zu wenig sind, empfehlen wir halt mind. 2048x1152 zu verwenden, um ihren 1440p Encode zu erhalten der dann in 10 mbit vorliegt. Und ab 1750 pixel höhe bekommt man halt den 4k Encode, welcher in 15mbit codiert wird. -
Das sind doch keine Angaben wie Youtube ihre Transcodes macht
Das sind grobe richtlinien für DEINEN Encode^^Wär aber geil wenn sie diese Bitraten bei IHREN Transcodes nehmen würden. Vor allem bei VP9
Dann hätten wir echt nette quali auf youtube xD -
und da genehmigt dir YouTube eine Bitrate von bis zu 24k.
Das wär ja epic wenn dem so wär
10 mbit kriegste da.
Und 4k muss mit 15mbit auskommen.24mbit pff schön wäres.
Eventuell liegt es an meinen Augen, keine Ahnung ich hab gerade mal ein paar Videos von dir auf YouTube angesehen und hab dabei zwischen HD 60 fps und 1440 p rumgeswitched....
Also wenn du den Unterschied zwischen 3,5 mbit und 10 mbit nicht siehst, stimmt mit deinen Augen wirklich was nicht
Und der Monitor ist doch völlig irrelevant dabei xDDob du jetzt auf 1440 oder auf 1080 stellst
Das stimmt nicht. Die 1080p stufe hat nur 3,5 mbit. Die 10 mbit gibts nur bei 1440p.
Ich frag mich nur gerad woher du dir die 24 mbit nimmst.
Also 1080p oder selbst 720p sind meiner Meinung nach kein "Pixelbrei". Deswegen kann ich die "mindestens 1440p" nicht ganz nachvollziehen. Zumal ich selber nicht mal einen Monitor hätte, auf dem ich das voll wiedergeben könnte...
Wie lang bist du Creator oder Zuschauer auf Youtube? Weil das kann eig. nur 1 Tag her sein, wenn du so schreibst.^^
-
Würde trotzdem lieber auf einheitliche Sampleraten umsteigen. Macht es dem Aufnahmeprogramm deutlich leichter die Spuren synchron zu halten als wenn du mit unterschiedlichen Timings daher kommst.
Aktuell ist meine Hoffnung jetzt x264 direkt in Premiere. Scheint sogar schneller zu sein als MeGUI, was erfreulich ist.
Naja das wundert jetzt nicht. Hast ja so die 10 Umwege nicht mehr drin bis das Video denn endlich mal beim Encoder ankommt.
-
Was braucht man mehr?
Auflösung, Zoll, Besseres Panel
(TN Panel sind schnell, haben aber die niedrigste Bildqualität) -
Gibt es vllt irgendwo FPS Unterschiede? Sprich stimmen Premiere Sequenzeinstellungen, Script usw alles mit der fps rate des Quellvideos überein?
Und hast du vllt eine neue Aufnahmemethode? (Programm, schon im Besitz einer Capture Karte, oder sonstige Änderungen) ?Ist halt schwer zu sagen, wenn man nicht die Dateien und kein Programm vor sich hat.
-
Das es keine PNG mit Transparenzen gibt ist bewiesen.
Weil sie es nicht wollen werden. Das wird seine Gründe haben. Außerdem wer weiß was man mit Transparenz anstellen kann. Gibts bestimmt auch dann Trolle die ein Thumb hochladen was rein nur Transparenz hat, was dann spätestens bei den Videovorschlägen am Videoende zu ungewollten Klicks führen kann. Wäre 'ne Idee eines Grundes, aber es WIRD Gründe haben.
Kein Mensch weiß warum es nur JPG Thumbs gibt
Ein weiterer Grund wird Speicherplatz sein. PNGs sind verlustfrei.
Und selbst wenn du JPG statt PNG auf Youtube hochlädst, wird die JPG von Youtube neu komprimiert in eine stärker komprimierte Fassung (um die 80% Qualität falls die Irfanview Schätzung einigermaßen richtig geraten hat) Also nichtmal vollgas qualität beim JPG Maxres Thumb.
Daher wird es Speicherplatzgründe haben. Denn verlustfreies PNG ist auf detailbildern erheblich größer. Daher würd ich auch raten in PNG hochzuladen, weil JPG -> JPG Transcode ist auf jeden Fall sichtbarer Verlust, vor allem wenns auf 80% nochma runtergesetzt wird. -
Descent 2 Addon
6 Spiele für 12 Monate
Wie du glaubst das du Descent 2 Vertigo in weniger als 12 Monaten fertig hast
-
Hmm die Audiospur ist aber genausolang wie die video spur...
Ja. Aber das Timing passt halt nicht. Ab der 3. Minute ist dann irgendwas passiert, wo die Geschwindigkeit des Videos dem Audio hätte angepasst werden müssen, was DXTory in dem Fall verpeilt hat. Man hat die Möglichkeit die Geschwindigkeit des Videos(fps) oder des Audios(Samplerate) dauerhaft zu justieren damit sie in sync sind. Normalerweise wird die Geschwindigkeit des Videos genommen, weil beim Audio wäres blöd wenn man so viel Pitch Shifting drin hätte (Sampleratejustierung). Wenn aber beim Video verlangsamt / verschnellert wird, fällts halt eig. nicht auf, außer du gelangst in die extreme und dropst / insertest zu viele Frames. Dann führts natürlich zu einem ruckeligen Video, wenn zu viele Frames verworfen / dummys eingefügt werden.
Die Längen der Spuren haben daher nichts damit zu tun. Das Timing innerhalb muss eben vom Aufnahmeprogramm in sync gehalten werden. Eine stabile FPS Rate im Spiel die dauerhaft überhalb der AufnahmeFPS ist, als auch eine dauerhafte, ausreichende Festplattenschreibleistung machen es dem Programm deutlich leichter den sync zu bewahren, zumal dann meist gar nicht oder nur sehr geringfügig angepasst werden muss. Schwierige Aufgaben sind natürlich hierbei immer Ladescreens oder auch 'nen aufgetretener Ruckler. In solchen Situationen kann eine Anpassung dann sehr schnell nötig sein.Auch sollte im BIOS High Performance Event Timer (HPET) aktiviert sein und auch in Windows aktiv sein. In Windows 7 ist es standardmäßig aus und dann haste eine bedeutend langsamerere Timingaktualisierung. Ich glaube in dem MSI Afterburner Gaming Tutorial Reihe Thread müsste HPET erklärt sein im Startpost.
Grundsätzlich ist jede asynchrone Aufnahme aber rettbar. Je nach Schwere der Asynchronität halt mehr oder weniger Aufwand. Aber das sollte man dann wie beschrieben machen und nicht nur nach Gehör um bessere Ergebnisse zu erzielen.
-
Interleave weg und vor allem nicht h.264 in AVI stecken.
Nimm das Tutorial
x264vfw für Videoschnittprogramme
und CRF probier mal eher so 20 aus.Und was hat die Feldreihenfolge da verloren? Deine Videos sind selbstverständlich progressiv. So muss das auch in den Projekteinstellungen sein.
Und hoffentlich stimmen vegas fps und quellvideo fps überein und Resampling deaktiviert damit du auch kein hässliches ghosting hast. -
Was ist denn nach den 3min passiert? Ein Ruckler? Ein Ladescreen? Irgendwas passiert an der Stelle?
Wenn du Glück hast, musste nur den Audioanteil nach der 3.min verschieben. Blöd ist natürlich wenns ganz viele Stellen gäben sollte, wo sich der AV Sync weiter verschiebt. Dann musste die Stellen alle finden und jeweils einzeln verschieben.
Dazu wäre eine Timeline mit Spursplitfunktion und einer akkuraten Audiowellendarstellung von Vorteil, so das es so framegenau wie möglich gelingt.in MPC-HC mit + und - Tasten vom Numpad kannste den Audio live verschieben. Da könntest du dann ja vorab mal gucken um wieviel du verschieben musst, damit es in der 3.min wieder ungefähr passt und ob das in der Mitte und am Ende des Videos immer noch so passt.
-
Ohne Einstellungen kann niemand helfen.
Gibt hier aber auch nen Tutorial wegen x264vfw.
Probier's mit 'nem CRF von 20.
-
Nachdem man es dann selbst rausgefunden hat, greift man sich an die Kopf, wie kompliziert manche Tutorials beschrieben sind. Natürlich werden die Profis das Gegenteil behaupten, die sehen das aber auch nicht aus Sicht eines Anfängers und gehen immer davon aus, dass jeder ein PC / Software / Script Gott ist.
Tja woran hatts denn gehangen? Hättst ja mal 'nen Kommentar schreiben können? Oder hast du? Wenn nicht, selbst schuld. Man beißt ja nicht. Ich weiß auch nicht wie laienfreundlich ich das noch machen soll. Ich hab schon extra am Anfang nur das wesentliche gezeigt und im hinteren Teil dann ausführlich. Eig. musst du nur die gezeigten Schritte nachmachen und nicht erst das Video ganz angucken und dann versuchen alles ausm Kopf zu erinnern. Vllt liegt hier der Fehler. Weil Schritt für Schritt das machen was gezeigt wird, kann doch gar nichts schief gehen.
Das MeGUI Tutorial geht davon aus das das Scriptmaker Tutorial bereits gesehen wurde. Sonst ist das klar. Hat dennoch für 70 likes gereicht, von daher wirds wohl manchen geholfen haben.Was hat das Alter damit zu tun? Bin auch 30 und hab zeitlich keinerlei Probleme. Und 'nen Scriptgott bin ich wahrlich nicht. Das wär schön. Dann könnte ich tolle Mods für Doom 2 machen. Und komplexere Scriptkonstrukte in avisynth kriegt auch eher Sagaras hin und nicht ich. Aber der Basiskram den nur Lets Player brauchen, ala bissl Schnitt, Übergangseffekte oder das bloße Einlesen von Videos ist nun wirklich mega easy .. Das ist nun wirklich keine Kunst.
_
TMPGEnc 6 ist ganz ok, aber extrem langsam bei H.264 Quellen im Player. Ich mein der Player könnte ja zumindest puffern, was Avisynth by design nicht kann und trotzdem spielt sich ein Avisynth Script zu einer MKV Datei in Virtualdub nahezu ruckelfrei ab, während es in TMPGEnc 6 eine völlige Diashow ist.
Auch der Encode ist stinkenlangsam in TMPGEnc. Wahnsinn wie ein Programm so langsam sein kann. Selbst mit NVEnc nur ~20fps. Lediglich der Export zu einem externen VfW Codec geht in normalem Tempo. Bei den internen Encodern ist jedenfalls x264 als auch NVEnc todeslangsam in dem Programm.Wenn eine Timeline GUI gewünscht ist - ich kann halt für Windows nichts empfehlen. Alles schrott. TMPGEnc hat eben diese massiven Performanceprobleme und auch paar einschränkungen bei den Encodesettings die aber noch akzeptabel sind, aber die Performance ist einfach miserabel. Höchstens Shotcut könnte Potential haben. Aber auch das hatte bei mir paar Bugs und Performanceprobleme beim Player. Aber ka wie sich das mittlerweile entwickelt hat.
Im Linuxbereich scheint die Situation deutlich besser zu sein. -
CQP = kleinerer Wert = höhere Qualität. Nicht das du von andersrum ausgehst.
Das stimmt zwar alles schon, aber in diesen spezifischen Fall scheint es ja eine ganz klare Zusammengehörigkeit zu geben.
Game + Aufnahme kommen auf 100% CPU Auslastung -> Video zeigt eindeutige Decoder schwächen.
Decoden über die GraKa und ZACK alles gut.Ich wollte nur sagen das genau das auch bei 20% CPU passieren kann und nicht wie in dem Fall dann wirklich bei 100. Weil sehr viele denken immer die CPU kann unterhalb 100% nicht schuld sein.
Und die Warnung nicht in MP4 aufzunehmen, sondern in MKV würde ich Beachtung schenken. Die ist nicht nur Deko.^^ -
Hab eigentlich immer gedacht die CPU Auslastung die OBS zeigt, wäre die komplette Auslatung. Naja wieder was gelernt.
Selbst wenn. Die CPU kann auch bei 20% schuld sein. Genauso wie sich manche gerne beschweren das Spiel xy sei schlecht optimiert weil es 100% CPU Nutzung erreicht. Das spricht eher FÜR die Anwendung, denn dann hat sie gute multithreadingfähigkeit, wenn die CPU voll ausgereizt werden kann. Wird in Spielen eher selten passieren, weil das meiste einfach linear abgearbeitet werden muss. Und trotzdem ist insbesondere bei den Arma basierten Spielen die CPU der limitierende Faktor, auch wenn sie dort nicht ansatzweise 100% hat eben wegen der nicht so guten parallelisierbarkeit. Ihr referenziert euch viel zu sehr auf diese % um zu gucken ob die CPU limitiert. Das ist einfach falsch.
-
Naja könnte dir dann halt 'ne Commandline für ffmpeg geben nach deinen Wünschen und darin pässte dir halt den Pfad zum Video immer an dann.
Oder du guckst dir Sagaras Scriptmaker und MeGUI an.
Aber 'ne commandline den videopfad immer anzupassen wäre vermutlich leichter. Wenn du eine Nvidia Grafikkarte hast und dir Dateigröße nicht so mega wichtig ist, könnte man auch eine sehr hohe Encodiergeschwindigkeit erhalten.Bei der Bitrate mit deiner aktuellen Software würde ich mal so bei diesem Spiel mind. 100 mbit anstreben und 2pass encoding wär natürlich bei bitratenencode sinnvoll, kostet aber mehr zeit. Und keine max/peak bitrate. Wenn nicht deaktivierbar, dann maximalwert dort.
-
Und das Profil kannst du ruhig auf High belassen, das hat keinen Einfluss auf die Geschwindigkeit.
Doch hat es.