Beiträge von Kayten

    eigentlich neuem PC


    AMD A8-6600K APU Prozessor mit 4x 3900 MHz, 8 GB RAM mit 1600 MHz, Grafikkarte GeForce 9800 GTX


    Bleiben wir bei "eigentlich". :S
    Gerade die GPU ist inzwischen doch etwas sehr veraltet und bei der CPU handelt es sich nicht gerade um die beste aus AMDs Sortiment, welches aktuell sowieso häufig den kürzeren zieht im Gegensatz zu Intels.
    Schau dir die Links zu den Tutorials an, dort wirst du wohl am meisten Geschwindigkeit herausholen können.
    Erst wenn du dich für eine der drei Möglichkeiten entschieden hast, kann man dir weitere Tipps geben.
    Am schnellsten sollte die Variante ohne Vegas sein, wenn dir höhere Geschwindigkeit so wichtig ist, musst du wohl Kompromisse beim Komfort eingehen.

    Das heißt, wenn ich bei Vegas "rendern als..." anklicke, ist das eigentlich eine Kodierung als das fälschlicherweise angedachte Rendern?


    Da ich solche Software bisher nicht verwendet habe, kann ich auch nicht sagen, wann der Begriff korrekt verwendet wird und wann nicht. ^^
    Wenn du letztlich eine Datei erhältst, so bezeichnet "Rendern" eigentlich "Rendern + Kodieren".
    Mal ganz grob gesagt:
    Rendern: Bild zusammenfügen
    Kodieren: Bild verschlüsseln (Dateigröße verringern)
    Und das wird halt häufig in einen Topf geworfen.

    Kann der 360er eig. auch Force Feedback?

    Gibt es Controller, die sowas heutzutage nicht unterstützen?
    Das einzige Problem dürfte eher sein, dass NFS2 nur DirectInput (alt) und nicht XInput (neu) nutzt um mit dem Controller zu kommunizieren.
    DirectInput läuft inzwischen über XInput und wird dort nicht komplett unterstützt, wie man bei Microsoft nachlesen kann.

    The Xbox 360 Controller is properly enumerated on DirectInput, and can be used with the DirectInputAPIs. However, some functionality provided by XInput will be missing from the DirectInput implementation:

    • The left and right trigger buttons will act as a single button, not independently
    • The vibration effects will not be available
    • Querying for headset devices will not be available


    Selbstverständlich gibt es findige Leute, die sowas trotzdem ermöglichen, da es natürlich auch andere Spiele gibt, welche Force Feedback über DirectInput nutzen und der Bedarf an einem Fix daher recht groß ist/war. Beschäftigen musste ich mich selbst mit sowas bisher nicht, da ich keinen X360 Controller besitze. Aber was ich auf die Schnelle gefunden habe:
    [Guide] Enable force feedback rumble for Xbox360 Controller
    xinput to dinput wrapper? (Wird sogar explizit NFS2 SE angesprochen!)


    Und Xbox 360 vs Xbox one Controller?

    Eine Frage, die ich selber gerne beantwortet hätte, ich stehe quasi vor der selben Entscheidung. ^^

    Gibts da große Unterschiede?

    Die Gamepads die ich bisher in den Händen hatte waren zwar zum Großteil älter, aber gerade mein letzter verbliebener PS2-Controller hat im Vergleich mit neuen Xbox 360 oder Xbox One Controllern sehr schwergängige Analog-Sticks.
    Würde daher auch schätzen, dass mit den Xbox Controllern deutlich feinere Abstufungen möglich sind, eben weil der initiale Widerstand sehr gering ist.


    Also wirklich so, das ich dann in einer langgezogenen Kurve den Stick z.B. halb nach rechts halten kann und das auch stabil geht ohne das ich immer nachkorrigieren muss?

    Das sollte eigentlich möglich sein, solange das Spiel mehr als nur "rechts/links" versteht.
    Kalibriert ist der Controller aber schon? Wenn nicht würde ich mich mal hier umschauen:
    Systemsteuerung > Hardware und Sound > Geräte und Drucker > Rechtsklick auf den Controller > Gamecontrollereinstellungen > Eigenschaften

    Der Beginn des Videos deutet recht klar darauf hin, dass die CPU überfordert ist, wie Julien schon schrieb. Der letzte Teil sieht für mich wie ein recht gewöhnliches 30FPS Video aus.
    Würde dir aber bei der CPU mal ans Herz legen ein anderes Aufnahmeprogramm auszuprobieren, wie zum Beispiel den MSI Afterburner (klick) mit dem UtVideo oder MagicYUV Codec, dann gäbe es zumindest kein Ratespiel von der Bitrate her und die CPU würde deutlich entlastet werden.

    Warum dann überhaupt wechseln, wenn UtVideo (RGB?) bereits problemlos funktioniert?
    Ansonsten folgendes:

    • CPU Auslastung beim Aufnehmen überprüfen
    • Environment Information von Dxtory posten
    • Testweise Threadanzahl in den Einstellungen des Codecs höher stellen

    trotz eigentlich neuem PC nimmt das Rendern doch ziemlich viel Zeit in Anspruch.


    Was ist für dich "viel Zeit" und "neuer PC"? Bei mir dauert ein ~20 Minuten Video ungefähr ~45 Minuten in der Verarbeitung (ergo "Kodierung", fälschlicherweise auch öfters "Rendern" genannt), allerdings deutlich höherqualitativ als deine 720p@30FPS.
    Du wirst hier sehr viele Vorschläge bekommen, die dein bisheriges Vorgehen abändern wollen. Angefangen bei Aufnahme, Verarbeitung bis hin zur Optimierung wegen YT-spezifischer Dinge, da du keinerlei Rahmen gesetzt .


    Als erstes verweise ich dich mal auf ein Tutorial:
    x264vfw für Videoschnittprogramme (Erklärt an Magix)
    Damit solltest du schon mal an Qualität und Geschwindigkeit zulegen.
    Alternativ zu diesem Tutorial gäbe es noch einen Weg über den DebugMode Frameserver, SagaraS Scriptmaker und MeGUI, zu dieser Konstellation gibt es allerdings kein Tutorial. Manche würden wahrscheinlich auch vorschlagen die Videobearbeitungssoftware komplett wegzulassen, dürfte für jemanden mit Intro und ohne weitere Kenntnisse allerdings eine riesige Umstellung sein, wenn auch die qualitativ beste und schnellste Methode.


    Solltest du das alles nicht in Betracht ziehen gilt ansonsten dieses Bild von Julien aus diesem Beitrag (klick):


    Je schneller du dein Video kodieren willst (Speed), desto mehr Abstriche musst du bei den anderen beiden Punkten (Qualität, Kompression/Dateigröße) machen.


    Über GPU rendern ist bei mir leider nicht möglich.


    Rendern über GPU wäre ratsam, Kodierung über GPU hingegen nicht. Letzteres kann die CPU deutlich effizienter, den scheinbaren Geschwindigkeitsvorteil von GPUs erkaufen diese sich mit minderer Qualität und würde die CPU ebenfalls auf diese Qualität getrimmt, wäre sie dabei deutlich schneller.


    Nun noch meine persönliche Meinung: Ich würde dir raten mit mehr als 720p zu kodieren, idealerweise 1152p, wodurch du die Qualität eines 1440p Videos auf YT bekommst. Denn die Auflösungseinstellung im YT-Player ist mehr ein Qualitätsschalter. Desweiteren wären für mich 60FPS Pflicht, würde aber alles eher die Verarbeitungsdauer deiner Videos erhöhen als verkürzen.

    Ich wüsste nicht, was gegen die 250 Ohm Variante spricht. Benutze meine nun nicht am Handy, aber selbst dort war die für mich noch annehmbar laut. Keine Ahnung was ihr mit euren Ohren macht, aber 8-9Uhr Stellung auf der 22VSL reicht für mich aus für angenehme Hörlautstärke. Noch mehr als genug Luft nach oben um sich die Ohren wegzupusten.
    Kann mir einfach nicht vorstellen, dass jemand ernsthaft die Lautstärke der 13 Uhr Stellung oder mehr dauerhaft benötigt, da kann die Umgebung doch schon quasi mithören, trotz der geschlossenen Bauweise. ^^

    Man muss natürlich bedenken, dass die Dateien sehr groß sind.

    Ratschlag für alle Zukünftigen: Konvertiert WAV zu FLAC Dateien. Qualitativ genau gleichwertig, allerdings komprimiert und benötigt daher weniger Speicherplatz.

    @SaBeX
    Ich kenn deinen Workflow nicht, keine Ahnung womit du deine Scripte für MeGUI erstellst.
    Im Fall vom SSM sollte das eigentlich recht offensichtlich sein:

    • Auflösung-Tab
    • Nearest Neighbour (PointResize) auswählen
    • Die Zielauflösung per Hand eingeben, die korrekte aus der Liste wählen oder alternativ geht das mit Sicherheit auch über Resize Factor mit 2x, genutzt habe ich das aber noch nicht.

    Aufnahme in 1080p RGB aus, bis 1800p ge"spline"t

    Würde ich nicht tun, mit Spline36 von 1080p auf 1800p skaliertes Material wird schlechter aussehen als ein PointResize von 1080p zu 2160p.
    Die Anzahl der zu skalierenden Pixel ist einfach zu hoch. Mit kleinen Schritten wie 1080p->1152p würde es bestimmt gut funktionieren, aber bei einem solchen Unterschied würde ich auf 2160p statt 1800p zurückgreifen.
    Keine Ahnung ob du den guten VP9 4K Encode bekommst oder nicht, für den dürfte aber auch gelten was ich hier (klick) geschrieben habe.

    Ist das normal oder liegt das an falschen Einstellungen?

    Ja, ist normal, liegt aber nicht an UtVideo, sondern:

    Ich habe gestern das erstmal mit Obs Studio aufgenommen.

    An OBS/FFmpeg.
    Um genau zu sein liegt es meiner Vermutung nach daran, dass Audio und Videospur in winzig kleine Stücke aufgeteilt sind, welche jeweils abwechselnd in der AVI vorzufinden sind. Das an sich ist nichts besonderes und Dxtory sowie MSI AB praktizieren das auch (was auch definitiv sinnvoll ist), nur macht OBS/FFmpeg diese Audio-/Videoblöcke so klein, dass die Festplatte noch weniger direkt nacheinander einlesen kann als ohnehin schon, weswegen immer erst gesucht werden muss, wo sich der nächste Block befindet, um diesen dann einlesen zu können.
    Mag sein, dass die Erklärung nicht zu 100% korrekt ist, aber das Prinzip dürfte recht deutlich werden.


    Hier noch Teile von MediaInfos:
    OBS: Interleave, duration : 29 ms (1.74 video frames)
    Dxtory: Interleave, duration : 100 ms (6.00 video frames)
    Bei OBS kommen nach 29ms Audiospur bereits wieder Videodaten, bei Dxtory erst nach 100ms Audio.


    Könnte natürlich auch sein, dass FFmpeg/OBS die AVI intern etwas anders strukturiert als Dxtory, das kann ich aber nicht auf die Schnelle nachweisen.

    Hab es jetzt mal versucht, den Spielesound erst via. VLC zu konvertieren und dann via. Audacity mit meiner Stimme zusammenzuschneiden

    Ist bereits der extrahierte Sound asynchron oder wird es erst asynchron bei Muxen?
    Sollte ersteres der Fall sein würde ich statt VLC den SSM mit VFR->CFR Converter testen und hierüber dann die Audiospur extrahieren, danach in Audacity bearbeiten und muxen. Nicht selbst probiert, könnte mir aber vorstellen, dass es etwas bringt.
    Möchtest du das Video auch noch bearbeiten, wäre der Frameserver der beim SSM mit dabei ist, eine Möglichkeit direkt synchrones Material zu erhalten ohne neu zu kodieren.

    Also müsste OBS nicht in mp4 aufnehmen sondern in avi

    Nö, du musst es nur richtig in das Skript einbinden und das macht der SSM automatisch. Mir kommt es eher so vor, als hättest du mal mit einem Video ein Script über den SSM erstellt, dieses Script nachträglich verändert und die MP4 dort eingetragen. Das funktioniert nicht.
    Wenn du dich mit AviSynth nicht auskennst würde ich dir raten nicht im Script im herumzufummeln, sondern ein neues Script über den SSM zu erstellen, der sorgt dann schon dafür, dass es richtig verarbeitet wird.

    @icey
    Willst du deine Stimme nachbearbeiten, kommst du um extra Software neben Dxtory nicht drum herum.


    Variante mit Audacity:

    • Spiel und Stimme mit Dxtory aufnehmen
    • WAV aus AVI extrahieren (mit Dxtory oder SSM)
    • Beide WAVs in Audacity laden
    • Audiospuren in Audacity bearbeiten
    • Alles exportieren als WAV oder FLAC

    Weil du nun aber mit Vegas arbeitest, vermute ich mal, dass die exportierte Datei samt Video nun in Vegas importiert werden muss, damit diese vernünftig bearbeitet werden können. Kann auch sein, dass Vegas bereits Tools zur Audiobearbeitung mitbringt, dann könnte man direkt beide unbearbeiteten Audiospuren in Vegas laden, dort bearbeiten und Audacity weglassen. Kann ich aber nicht genau beantworten, da ich keine NLE verwende.


    Wenn du den Frameserver korrekt eingestellt hast, lässt sich dann auch Audio (aus Vegas) weitergeben. Bedeutet, du wählst in MeGUI bei Audio Input die AVI des Frameservers.


    Habe aber eher das Gefühl, dass du selbst nicht weißt wie du vorgehen willst, bei so vielen Threads in denen du gerade aktiv bist.

    Jetzt fehlt immer noch das Script, bzw. dessen Inhalt.


    Aber bereits mit diesen Infos fällt mir folgendes auf:

    AviSource: Could not decompress frame 0

    Format : MPEG-4


    AviSource kann kein MP4 öffnen und würde daher mal hinterfragen, ob der SSM überhaupt korrekt verwendet oder ob nur ein bereits vorhandenes Skript verändert wurde.
    Hätte auch besser in den SSM oder MeGUI Thread gepasst.

    Kann ich irgendwie die Enkoderlast verringern und die CPU-Last im Gegenzug erhöhen?

    Die CPU wird durch den Encoder belastet, nur nutzt dieser Encoder scheinbar nur einen CPU-Kern, wodurch ein Großteil der Leistung einfach brach liegt.
    Wenn MSI AB oder Dxtory tatsächlich mehrere Fenster gleichzeitig aufnehmen können, so würde ich dir raten das auszuprobieren. Musste ich bisher noch nie machen und kann daher nicht sagen, ob es funktioniert, kostet im Fall des AB aber schließlich nichts.