Beiträge von Kayten

    Willst du den Prozessor übertakten können?


    Jetzt noch nicht, in Zukunft vielleicht. Was das angeht bräuchte ich wahrscheinlich mal nen kurzen Crash-Kurs.

    B250 Chipsatz

    Damit fällt das Übertakten flach.


    i5 oder i7

    Ich kann aktuell nicht anders als darauf zu verweisen, dass du mit einem AMD Ryzen gerade was Let's Plays bzw. die Kodierung dessen betrifft wohl besser beraten wärst. Problem ist da nur, dass deine Grundbasis diesbezüglich inkompatibel wäre und AMD keine CPU für den AM4 Sockel für zweistellige Beträge anbietet. Hieße entweder Geld aus dem Fenster zu werfen für einen kompletten Plattformwechsel oder länger zu warten mit dem Kauf bis mehr Geld zur Verfügung, um direkt eine anständige CPU zu verbauen.

    So viel extra Performance wird dir die 64bit höchstwahrscheinlich Variante nicht geben, wenn du jetzt bereits große Probleme hast. Ich würde eher die MagicYUV Einstellungen überprüfen.


    Ich hab 'ne GTX 1070 und kann ein Retro-Pixelspiel nichtmal in 60FPS Aufzeichnen mit dem MSI Afterburner

    Wodurch nicht geklärt ist, ob es nun an mangelnder CPU Leistung liegt oder nicht.

    Theoretisch müssten die Aufnahmeprogramme allesamt von BattlEye blockiert werden, werden sie aber nicht. Das einzige was blockiert wird, sind die Codecs. MagicYUV 2.0 wurde letztens signiert, damit es nicht mehr von BattlEye blockiert wird, wie im MagicYUV Thread geschrieben, aber ob das letztlich geholfen hat, kann nur jemand herausfinden, der MagicYUV 2.0 nutzt.

    Das Intro ist mit VEGAS Movie Studio 14 erstellt worden und als AVI gerendert (x264vfw, ja ich kenne die Nachteile).

    Um genauer zu sein: Du hast H.264 Material in einen AVI Container gepackt.


    Nachdem ich beide Videos in das Fenster gezogen habe und die Datei (mit COPY bei Audio und Video) neu gemuxed habe (als MKV natürlich) läuft das Intro wunderbar, das Gameplay dann aber plötzlich nur noch mit schwarzem Bild und komischen Audio-Artefakten (stottern, fiepen, etc).

    Das Aneinanderhängen von H.264 Material funktioniert meines Wissens nach nur, wenn alles mit den exakt gleichen Einstellungen kodiert wurde. Bei Audiospuren gilt vermutlich das selbe.


    Also habe ich folgendes gemacht: Das von Movie Studio gerendete AVI erneut durch Sagaras und meGUI in MKV gerendert und es damit probiert. Nun funktioniert die Wiedergabe von Intro und Gameplayvideo wunderbar!

    Hier umgehst du das oben genannte Problem, indem du das Material erneut kodierst. Qualitätsverlust inklusive.


    Gibt es hier eine bessere Lösung als das was ich probiere? Und vielleicht mache ich ja etwas falsch, was die beiden Fehler verursachen könnte?

    Zwei Möglichkeiten:

    • Das Intro verlustfrei speichern mit bspw. MagicYUV und es immer dann neu kodieren und zusammenfügen, wenn benötigt. (z.B. im SSM oder nachträglich via mkvmerge)
    • Falls Vegas einen Frameserver unterstützt: Das Intro via Frameserver über MeGUI mit den exakt gleichen Einstellungen kodieren, wie das Gameplaymaterial und nachträglich via mkvmerge o.ä. zusammenfügen.

    Variante 1 benötigt mehr Zeit und lokalen Speicherplatz als Variante 2, hat aber dafür den Vorteil höherer Flexibilität und Qualität, bspw. beim Wechsel der Auflösung, da das verlustfreie Material besser zur Skalierung geeignet ist.
    Der ganz schlaue kombiniert einfach beides und behält das verlustfreie Original immer in der Hinterhand, kodiert beim Wechsel der Videoauflösung das Intro genau einmal neu, verwendet es dann für alle Videos mit der neuen Auflösung und spart sich somit die Kodierung des Intros bei jedem Video machen zu müssen.

    Dann hast du wohl mal die Beschwerde von MeGUI weggedrückt, dass dein Video nicht in YUV420 vorliegt und die darin enthaltende Frage, ob MeGUI die Konvertierung immer automatisch hinzufügen soll, bestätigt. Daher fügt MeGUI wohl zu jedem deiner Scripts ein "ConvertToYV12" am Ende hinzu. ^^
    In irgendeiner Datei ließ sich das abstellen, @De-M-oN weiß da mehr.

    Das Einzige, was ich aus den Bildern wirklich herauslesen kann ist, dass du offensichtlich im GPU-Limit hängst und ein Wechsel der CPU dir keinen Performancevorteil bringt. Keine FPS Anzeige, keine genaue Auslastungsanzeige der CPU, lediglich Taktraten, die nicht wirklich viel aussagen und ein paar Prozentzahlen, von denen man nicht direkt weiß was sie bedeuten.

    Der Changelog der 2.0.0rc2 dürfte für einige interessant sein:

    2.0.0rc2


    Released: 2017.03.21.
    This is a bugfix release fixing issues with some recorder programs and BattlEye.

    • FIX: Core: Added decoder checks against invalid data which caused the codec to crash. This happened if the decoder received garbage data when opening invalid AVI files produced by some recorder programs (most notably Bandicam).
    • FIX: Windows/VFW: The codec DLL is now signed, allowing BattlEye to whitelist it. This will fix the issue of not being able to use the codec for recording in BattlEye-protected programs shortly (please allow some time for the whitelisting to be put in place)

    Also alle, die bisher Probleme mit der Aufnahme dank BattlEye hatten, sollten mal MagicYUV 2.0 probieren.

    Magic YUV Decoder (Generic)

    Ist wie der Name schon sagt nur ein Decoder für Pre-MagicYUV 2.0 Material, damit kannst du nichts anfangen. Wenn du dich an das MagicYUV Tutorial gehalten und so eingestellt hast, solltest du MagicYUV 4:2:0 wählen. Entspricht dann dem, was du vorher hattest.

    ich bin verwirrt

    Weshalb? Das ist unkomprimiertes YUV422 Material, 16 Bits pro Pixel, wie es in der MediaInfo steht.
    16 x 1920 x 1080 x 60 / 8 / 1024 / 1024 = 237,3046875MB/s. Entspricht ungefähr dem was in der MediaInfo steht: 1.991 / 8 = 248,875.
    Die Werte unterscheiden sich, da ich mit 1024 gerechnet habe und nicht mit 1000. Ersetzt man in meiner Rechnung die 1024 durch 1000 kommt dort 248,832MB/s bei heraus.

    unkomprimiertes 8-bit RGB-Material

    Sicher, dass du unkomprimiertes Material meinst und nicht verlustfrei komprimiertes?
    Solltest du wirklich unkomprimiertes 8-bit RGB Material meinen, so wirst du folgendes zum Ausrechnen der Bitrate nutzen können:
    Bits pro Pixel x Breite x Höhe x FPS / 8 / 1024 / 1024 = Bitrate in MB/s
    Bei einer üblichen Auflösung von 1920x1080 bei 60FPS kommt man auf 355,84MB/s. Da wird auch ein RAID0 aus zwei Festplatten nicht mehr viel helfen oder so gerade eben an der Kotzgrenze laufen und das auch nur für kurze Zeit, da die Festplatten nach innen hin langsamer werden.

    Wenn du die Videos direkt nach der Aufnahme hochladen willst, ohne weitere Bearbeitung, Encoding, etc., dann wäre OBS Studio mit x264 und der Qualitätsregulierungsmethode "CRF" eigentlich die richtige Wahl für dich. Bei der hohen Auflösung samt 60FPS wirst du aber wohl nicht um das CPU-Preset "ultrafast" herumkommen, woduch du große Dateien erhalten würdest.
    Funktioniert das nicht wie gewünscht, muss herausgefunden werden woran es liegt. CPU-Leistung, GPU-Leistung, HDD-Geschwindigkeit oder sonstige Eigenarten von OBS Studio, wie bspw. unterschiedliche Hz-Zahlen für Spiel und Monitor auf dem OBS läuft.


    Dxtory ist für mich ein Buch mit 7 Siegeln!

    Dxtory ist nach meinen Erkenntnissen der letzten Monate eigentlich sehr viel simpler als OBS Studio. Ansonsten gibt es im Forum auch ein >Tutorial<, genauso wie für OBS Studio, allerdings mit verlustfreier Aufnahme als Hauptaspekt.