Fehlermeldung alleine nützt nichts. Das zugehörige Script ist nötig.
Beiträge von Kayten
-
-
Solange [lexicon]OBS[/lexicon] kein VfW [lexicon]Codec[/lexicon] unterstützt, welcher weniger Leistung zieht als [lexicon]x264[/lexicon]
"In theory it should be possible with [lexicon]obs[/lexicon]-mp, but it will probably not be a high priority. ffmpeg is working on all platforms and has a wide support for different codecs." - [lexicon]OBS[/lexicon] Forum, Dezember 2015.
Das ist das einzige blöde, dafür aber bis zu 4 Tonspuren, man müsste sich mal mit den Entwickler in Kontakt setzen.
"Multitrack recording will eventually come to FFmpeg, so hopefully that will help some. Right now, [lexicon]AAC[/lexicon] is the only [lexicon]encoder[/lexicon] because that is the only thing that is really supported by RTMP." - dodgepong, [lexicon]OBS[/lexicon] Forum, September 2015Könnte also theoretisch alles irgendwann noch kommen. Frage ist nur wann.
-
@GelberDrache92
Da habe ich ihn doch schon drauf hingewiesen, die [lexicon]MediaInfo[/lexicon] ist das Ergebnis des korrigierten Befehls, zumindest habe ich das so verstanden. -
Ich habe das so genannt, weil ich nicht alle Monitore der Welt kenne. Vllt gibt es ja einen oder mehrere die TV Output haben oder sogar neben PC Output supportet werden. Wer weiß?
Abgesehen davon, dass heutige HDTVs sowohl TV als auch PC Range beherrschen, finde ich es recht sinnlos wegen einiger Geräte für alle TV Range als Standard einzustellen. Nun sollte man aber auch bedenken, dass PC(!) Monitore, die über DiplayPort (PC only, bis auf eine Ausnahme, Stand 2013) angeschlossen sind, ebenfalls davon betroffen waren. Da kann man sich leider nur an den Kopf fassen.Wieso heller? Wird doch dunkler, bzw. wirkt gesättigter.
Ich denke er wird versuchen die Sättigung seiner Farben zu verstärken, damit diese trotz TV Range noch kräftig wirken. -
Vllt hatts sichs bei neuerem Nvidia Treiber geändert?
Ich würde eher behaupten Nvidia sei unfähig das einheitlich zu gestalten.Zwei Möglichkeiten zwischen TV und PC Range zu entscheiden. Die Option bei der [lexicon]Auflösung[/lexicon] ist vermutlich deswegen hinzugekommen, weil Nvidia manche Bildschirme nur mit TV Range angesprochen hat (sowohl über HDMI, als auch über DisplayPort), was sich nur beheben ließ, wenn man eine benutzerdefinierte [lexicon]Auflösung[/lexicon] erstellt und verwendete. Macht man dies, kann man auch nicht mehr auf TV Range stellen, wie man auf den Bildern sieht.
-
Das einzige was mir spontan auffällt ist das hier:
custom command line: --output -csp i444
Falsche Angabe des gewünschten Farbraums, sollte --output-csp "i444" heißen, ohne Leerzeichen nach output. Ob die Anführungsstriche notwendig sind, weiß ich nicht. -
Aber natürlich, bist du einmal auf YV12 sind die Informationen weg und kommen auch nicht zurück, wenn du wieder auf YV24 gehst, sonst bräuchtest du schließlich nicht mit besserem Farbraum aufnehmen.
Mach es so wie Sagaras vorschlägt und stell im [lexicon]SSM[/lexicon] auf YV24, sonst bringt dir dein RGB Material rein gar nichts (wenn du nicht hoch skalierst) und du könntest auch direkt in YUV420 aufnehmen. -
und zwar habe ich eine schreibrate von 180MB/s ist das ausreichend für die standart empfehlung?
Abhängig von [lexicon]FPS[/lexicon] und [lexicon]Auflösung[/lexicon], aber grundsätzlich schon.wie legt man denn profile an?
Die werden von [lexicon]Dxtory[/lexicon] automatisch erstellt, wenn du ein neues Spiel startest.
Also einmal das Spiel starten während [lexicon]Dxtory[/lexicon] läuft, danach kannst du die Einstellungen des Profils verändern. -
RawCap Funktion fehlt.
Hat hier irgendwer diese Funktion schon mal verwendet?
Wenn keiner Erfahrungswerte dazu schreiben kann, müsste ich die erstmal testen.Die Threads beeinflusst auch den Auflösungsskalierer von [lexicon]DXTory[/lexicon].
Gut zu wissen. Wo kommt man an solche Infos?
Ist aber eher eine sehr nebensächliche Info, denn wer Dxtorys Skalierung nutzt, wird sowieso zurechtgewiesen und davon abgebracht. -
Da es zwar einen Thread für OBS und sogar zwei für den MSI Afterburner gibt, aber keinen für Dxtory, wird es Zeit, dass dies nachgeholt wird.
So kann bei generellen Fragen direkt auf diesen Thread verwiesen werden, wodurch sich die Frage vielleicht auch schon klärt.Was ist Dxtory?
Dxtory ist ein Aufnahmeprogramm von ExKode für DirectX7-12, OpenGL sowie Vulkan Anwendungen und ist hier erhältlich.
Angeblich sollen laut Website auch DirectDraw Anwendungen aufnehmbar sein, habe ich allerdings noch nie in Aktion gesehen.
Die aktuelle Version ist zurzeit Dxtory 2.0.141.Grundlegende Einstellungen
Die eigentlich nicht erklärt werden müssen, sich aber von den Standardeinstellungen unterscheiden können.Aufnahmespezifische Einstellungen
Basierend auf den im Forum häufig empfohlenen Einstellungen.- Aufnahme-Codec festlegen. Standardempfehlung: MagicYUV (klick) in der 64bit Variante (blaue "64" in Dxtory)
- Codec-Einstellungen anpassen. Abhängig vom gewählten Codec, siehe Einschub unten.
- Aufnahme-FPS auf die gewünschten FPS stellen. Häufig verwendete Werte: 30, 41, 50, 60
- Optional: Mauszeiger in der Aufnahme anzeigen lassen
Einschub: Welchen Codec verwenden und wie einstellen?
Für jede Kombination von Software (Aufnahmeprogamm, Spiel), Hardware (CPU, Festplatte) und Benutzer (Qualitätsansprüche) kann ein bestimmter Codec bzw. dessen Konfiguration gut oder weniger gut geeignet sein. Kompromisse hierbei sind teils unvermeidlich.
Die Empfehlung hier im Forum ist aktuell MagicYUV 1.2 oder MagicYUV 2.0. Der Codec ist verlustfrei und anpassbar an die eigenen Qualitätsanforderungen und Hardarebegebenheiten.
Wer trotzdem einen anderen Codec probieren möchte (warum auch immer), hier eine kurze Übersicht über verschiedene (Lossless-)Codecs und deren möglichen Anwendungsfall:MagicYUV 1.2 Kann je nach Einstellung variabel angewendet werden, siehe hierzu den MagicYUV-Thread (klick). Meine persönliche Empfehlung. MagicYUV 2.0 Analog zu MagicYUV 1.2, jedoch nochmals verbessert, dafür allerdings zwangsweise kostenpflichtig. UtVideo YUV420 BT.709 VCM (Predict Left) Nicht empfohlen! Unsinnig hohe CPU Belastung ohne Vorzüge gegenüber der Standardempfehlung bei minderer Qualität! UtVideo YUV420 BT.709 VCM (Predict Median) Mögliche Notlösung bei besonders schwacher HDD und sehr starker CPU. Geringere Qualität als bei der Empfehlung. UtVideo YUV422 BT.709 VCM Standardempfehlung. Mit Predict Median wird die Belastung etwas von der Festplatte auf die CPU verlagert, während mit Predict Left die Festplatte stärker belastet wird. UtVideo RGB VCM Dann verwenden, wenn Material mit geringer Auflösung (z.B. von GBA/NDS Emulatoren) später hochskaliert oder das letzte bisschen Qualität herausgeholt werden soll.
Der PC wird hierbei grundsätzlich stärker belastet als beim empfohlenen Codec. Der Unterschied zwischen Predict Left und Predict Median gilt auch hier.Dxtory Video Codec Sollte nur in Sonderfällen verwendet werden, wie bei einer besonders schwachen CPU und extrem starken Festplatten.
Hierzu in den Einstellungen des Codecs keinen Haken bei "Compress" setzen und den gewünschten Farbraum wählen (ähnlich wie bei MagicYUV). Empfohlenes Minimum: YUV420.
In dieser Einstellung wird unkomprimiert aufgenommen und somit extrem viel Platz (~178MB pro Sekunde bei 1080p 60FPS) auf der Festplatte benötigt!
Über die Advanced Settings lassen sich Priorität und Threadverteilung bestimmen. Wurde bisher zu selten getestet für aussagekräftige Beurteilungen.Lagarith Lossless Codec Nicht empfehlenswert. Verursacht hohe CPU Belastung und nutzt im YUV-Farbraum die für YouTube ungeeignete BT.601 Farbmatrix. Lediglich für RGB Aufnahmen einigermaßen sinnvoll. x264vfw Nicht verwenden. Zum Aufnehmen ungeeignet. Sehr hohe CPU Belastung, generell verlustbehaftet und keinerlei Vorzüge gegenüber anderen Codecs. Advanced Settings - Optimierung & Problemlösung
Wenn mal etwas nicht so läuft wie es soll. Alles optional.(Un)abhängige Profile
Zu bequem immer wieder die Einstellungen zu wechseln für jedes Spiel?Nicht weiter erläuterte Features
Weitere Features von Dxtory, die in diesem Tutorial (bisher) nicht erklärt wurden (und vielleicht auch nie werden):- Aufnahme auf mehrere unterschiedlich schnelle Festplatten via RawCap
- Nutzung des DirectShow Outputs (z.B. in Zusammenarbeit mit OBS)
- Clipping und Margin während der Aufnahme
Alternativen zu Dxtory
Mögliche Alternativen zu Dxtory sind:
Korrekturen und Ergänzungen erwünscht! -
Ich als Zuschauer schaue praktisch nie in die Videobeschreibung, höchstens um vielleicht den einen oder anderen Link herauszufischen (z.B. die Playlist!).
Daher ist eine Zusammenfassung der Folge in der Videobeschreibung für mich recht zwecklos. Im Zweifelsfall spoilert diese mich sogar.
Wobei ich die Idee mit der Zusammenfassung der letzten Folge recht interessant finde, auch wenn deren Nutzen für jemanden wie mich wahrscheinlich recht gering ist.Was ich mir meistens wünsche ist ein Link zur Playlist, und zwar als allererstes.
Hat für mich den Vorteil, dass ich das Video nicht mal anklicken muss nur um zur Playlist zu gelangen (und somit die Zuschauerbindung nicht unnötig runterziehe), denn der Beginn der Videobeschreibung wird schließlich in der Aboseite angezeigt und somit auch der Link, wenn dieser genau dort zu finden ist.
Gerade wenn man mittendrin ein Projekt mitverfolgen möchte oder einige Tage später Folgen nachholen will, kommt man so recht schnell an die entsprechenden Videos. -
Zum Thread: 1152p@60FPS
das [lexicon]Rendern[/lexicon] des Videos mit 60 [lexicon]FPS[/lexicon] einfach doppelt solange dauert, wie die Aufnahme lang ist
Bedeutet, du kodierst mit ~30FPS, ist doch ein guter Wert? Gibt bestimmt einige, die sich wünschen würden so schnell kodieren zu können. Ich bin da noch die ~4FPS meiner alten [lexicon]CPU[/lexicon] gewöhnt, die sich mit Videomaterial eines Egoshooters quälen musste. -
Wie stellt man ein, dass der Mouse Cursor mit aufgenommen wird?
Ist leider nicht möglich. Features wie Hardware-Encoding haben beim Entwickler scheinbar Vorrang.Bei manchen spielen zerhackt er das Video, aber ganz ungleichmäßig, so als ob die Aufnahme gestoppt und wieder gestartet wird.
Wenn sich die [lexicon]Auflösung[/lexicon] des Spiels ändert, so ist das völlig normal, dass mehrere Dateien erstellt werden, ansonsten mal das Dateisystem der jeweiligen [lexicon]Festplatte[/lexicon] auf NTFS stellen.Das Aufnehmen trotz Änderung der [lexicon]Auflösung[/lexicon] funktioniert übrigens nur auf Windows 7 oder mit Hook. Ist beides nicht gegeben (Windows 8 oder höher mit Desktopaufnahme) so wird die Aufnahme gestoppt, was die Aufnahme von einigen Spielen zur Qual werden lässt auf neueren Betriebssystemen.
-
Aus meiner Sicht zu viele Threads, maximal 3 sollten ausreichen, wenn man bei gängigen Auflösungen bleibt.
Warum YUV422? Nutzt du das auch hinterher? Ansonsten reicht YUV420. -
Trotzdem ist die Qualität um Dimensionen besser. Ergo muss es eine andere Möglichkeit geben, gute Qualität in dieser [lexicon]Auflösung[/lexicon] zu erhalten.
Bitte meinen Beitrag auch ganz lesen und nicht die Hälfte weglassen. Das von dir verlinkte Video hat den [lexicon]VP9[/lexicon] Encode bekommen und sieht daher besser aus.
Jeder auch nur etwas größere YouTuber bekommt [lexicon]VP9[/lexicon] Encodes, du dagegen meistens nicht. Bedeutet, dass das selbe Video bei dir schlechter aussehen würde als bei jemand größerem.Zusätzlich: Ich habe beide von dir verlinkten Videos (sowohl Main Concept als auch die [lexicon]x264vfw[/lexicon] Variante) mit Firefox angesehen und sie laufen beide gleich (un)flüssig.
Manchmal lief für ein paar Sekunden eins der beiden flüssig. Habe ich dann etwas zurück gespult und mir die Stelle abermals angeschaut war es nicht mehr flüssig. Und das bei beiden Encodes.
Mit Chrome dagegen überhaupt kein Problem. Ich glaube du versuchst Dinge zu ändern, die du nicht ändern kannst. -
Nun, wie kann ich dafür sorgen dass Youtube beim neuencodieren möglichst wenig bis garkeine Qualität verliert? Irgendwelche Einstellungen müssen sich ja darauf auswirken.
Gar nicht. Du kannst YouTube höchstens besseres Material liefern (Niedrigerer [lexicon]CRF[/lexicon] oder gar [lexicon]Lossless[/lexicon]) oder passend skalieren.Ergebnis ist leider nicht besser.
Dein 1152p Video hat keinen [lexicon]VP9[/lexicon] Encode und damit auch kein 1152p bekommen, bedeutet es hängt weiterhin auf der normalen 1080p Stufe mit normaler [lexicon]Bitrate[/lexicon].
Daher ist es auch logisch, dass das skalierte Video nicht besser aussieht als das Original.
[lexicon]VP9[/lexicon] Encodes sehen grundlegend besser aus als Videos mit [lexicon]H.264[/lexicon], da YouTube hier scheinbar die Einstellungen beim Kodieren etwas besser gewählt hat.
[lexicon]VP9[/lexicon] bekommt man recht willkürlich, ab einer bestimmten Viewerzahl (?) aber eigentlich immer. Alle größeren YouTuber haben daher den [lexicon]VP9[/lexicon] Encode. Du dagegen meistens nicht. -
Gibt es HFR nur mit [lexicon]VP9[/lexicon]?
Ohne [lexicon]VP9[/lexicon] gibt es HFR nur bis zu 1080p oder eben 1152p+ ohne HFR.
1152p+ mit HFR gibt es nur mit [lexicon]VP9[/lexicon].Wie kann man überprüfen ob man HFR hat?
Quasi wie hier erklärt: Ein allgemeiner Youtube-Thread
Nur, dass du hierbei auf die Angabe hinter dem "@" Zeichen bei Resolution achten musst. "@41" steht dann für 41FPS (= HFR).
"@30" oder darunter ist dementsprechend kein HFR. -
wenn mein Quellmaterial ([lexicon]OBS[/lexicon], Elgato GameCapture) in 720p /1080p aufgenommen wurde, und ich dies auf 1152p hochskaliere, wird das ganze dann nicht gestreckt und die Qualität "schlechter"?
Prinzipiell ist die Idee richtig, aber durch die höhere [lexicon]Auflösung[/lexicon], bekommst du mehr [lexicon]Bitrate[/lexicon] von YT was in besserer Qualität resultiert.
Bedeutet einfach gesagt, dass der Gewinn durch die 1152p [lexicon]Auflösung[/lexicon] wesentlich größer ist, als der (teilweise gar nicht vorhandene) Verlust (Verlust = Unwiderruflich anders als das Original) durch das Skalieren.Nur nochmal zur Sicherheit: Die Angaben bzgl. der [lexicon]Auflösung[/lexicon] (z.B. 1080p) sind Angaben ohne Seitenverhältnis. Hast du nun ein Video mit 1920x1080 (1080p im 16:9 Format) musst du natürlich auch 2048x1152 (1152p im 16:9 Format) wählen. Unter "strecken" verstehe ich nämlich, dass beispielsweise ein 4:3 Video auf 16:9 gestreckt wird, und das ist furchtbar.
Woher kommt der wert 41 [lexicon]FPS[/lexicon]?
Diese Zahl wurde durch ausprobieren herausgefunden. Lade ein 40FPS Video hoch und es bekommt letztlich nur 30. Lade ein 41FPS Video auf YouTube hoch und es behält seine 41FPS. 41 ist da der ermittelte Mindestwert für HFR Videos.
Falls die Frage aber eher in die Richtung geht "Warum wählt YouTube 41FPS als Minimum?": Irgendwo muss eine Grenze gezogen werden.
Man könnte das bestimmt einigermaßen begründen mit unterschiedlichen Formaten (HFR in Kinos = 48 [lexicon]FPS[/lexicon], bedeutet 48 sollten mindestens unterstützt werden), die kenne ich nun aber nicht alle. -
Warum 8 beim [lexicon]Frame[/lexicon] Divide Count? Hälfte der logischen Kerne wäre 4, wobei du mit 3 oder gar 2 bei der [lexicon]CPU[/lexicon] prima klar kommen solltest. Im Zweifelsfall ausprobieren.
[lexicon]HDD[/lexicon] ist aus meiner Sicht auch schnell genug, solange die [lexicon]Auflösung[/lexicon] oder der Farbraum nicht weiter erhöht werden. -
Wenn die Nutzung von [lexicon]Avisynth[/lexicon] über den [lexicon]SSM[/lexicon] hier schon angepriesen wird, gibt es doch bestimmt eine Person die mir meine [lexicon]Avisynth[/lexicon] Frage von >hier< beantworten kann?
Welche Probleme können durch Multithreading in [lexicon]Avisynth[/lexicon] auftreten, wie lassen sich diese entdecken und welche Vorgehensweisen sind prädestiniert für Probleme mit MT? Sehr geringe/hohe [lexicon]Auflösung[/lexicon] des Quellvideos, viele Filter, eigene Funktionen, was halt so bekannt ist.
[...]
Wie viele Threads nutzt SetMTMode(x) standardmäßig? So viele wie logische Kerne vorhanden sind?
Kann das MT im Script wieder deaktiviert werden, vielleicht über SetMTMode(0)?@UntilTheError
UtVideo YUV422 BT.709 VCM ist das was du brauchst.
Wählst du in den Einstellungen Predict Left so wird die [lexicon]HDD[/lexicon] mehr beansprucht und die [lexicon]CPU[/lexicon] etwas entlastet, bei Predict Median ist es genau umgekehrt. Beim [lexicon]Frame[/lexicon] Divide Count (Anzahl der verwendeten Threads) musst du ausprobieren, manche sagen die Hälfte der logischen [lexicon]CPU[/lexicon]-Kerne wäre ideal, andere kommen mit 3, 2 oder gar 1 aus.
Was die Geschwindigkeit der [lexicon]HDD[/lexicon] angeht: Hängt von dem aufgenommenen Material, der [lexicon]Auflösung[/lexicon], den [lexicon]FPS[/lexicon] und dem [lexicon]Codec[/lexicon] ab. Idealerweise so schnell wie möglich. Einfach ausprobieren oder du testest deine [lexicon]HDD[/lexicon] mit CrystalDiskMark und zeigst uns das Ergebnis.