Beiträge von Kayten

  • Aufnahme ruckelt mit Dxtory

    Gesamte Hardware, Geschwindigkeitstest deiner Aufnahmefestplatte mit CrystalDiskMark und die [lexicon]Environment Information[/lexicon] von [lexicon]Dxtory[/lexicon] posten, dann lässt sich da vielleicht etwas sagen.

  • Ich weiß was ich mache, aber was mache ich eigentlich?

    Würde mich dennoch mit jemanden in Kontakt setzen, der TMPEnc auch selbst nutzt.
    Wird hier zwar als die qualitativ hochwertigste Videobearbeitungssoftware gehandelt, welche Version du nutzt hast du allerdings nicht geschrieben.
    Sollte es sich um eine ältere Version handeln, weiß ich nicht ob diese Empfehlung auch gilt bzgl. der Kodierung.
    Kannst du beispielsweise nicht [lexicon]x264[/lexicon] ([lexicon]Encoder[/lexicon]) nutzen über deine Version, so würden schon sehr viele davon abraten.


    Ansonsten noch Hinweise für YT:
    Wenn möglich, nimm deine Videos mit mehr als 1920x1080 auf (z.B. mit 2048x1152 als guter Kompromiss), dadurch gibt es eine höhere Qualitätsstufe auf YT, die jeder bekommt, der im Player auf 1080p klickt. Bestimmt der Player die Qualität automatisch, so ist die ursprüngliche 1080p Stufe noch verfügbar.
    Sollte die Aufnahme in 1152p nicht möglich sein, dann lass deine Videos vom jeweiligen Programm [lexicon]hochskalieren[/lexicon] auf 1152p ([lexicon]SSM[/lexicon], TMPEnc, was auch immer).

  • Ich weiß was ich mache, aber was mache ich eigentlich?

    Dann bekommst du jetzt noch ein paar Hinweise auf den Weg.


    Zitat von RetroRuebe

    ABER wenn ich jetzt die beiden Audiospuren aus dem Video mit dem Programm herausschneide, wie bekomme ich die dann wieder ins Video?


    Bei [lexicon]MeGUI[/lexicon] gibt es ein "Audio Input", dort kommt die Audiospur rein, die du erst mit dem [lexicon]SSM[/lexicon] extrahierst und mit [lexicon]Audacity[/lexicon] bearbeitet hast. Kein Synchronisieren notwendig, nur Lautstärkeanpassung, fertig zum Speichern.


    Zitat von RetroRuebe

    Er sagt Audio vorhanden und ob ich diese für die Vorschau aktivieren möchte. Egal was ich anklicke sobald die Vorschau in [lexicon]VirtualDUb[/lexicon] beginnt kommt folgende Fehlermeldung: Cannot open File "Pr" das System kann die angegebene Datei nicht finden.


    Das müsste sich @Sagaras selbst mal anschauen, bist aber höchstwahrscheinlich nicht der erste mit diesem Problem, die Lösung steht mit Sicherheit schon irgendwo im Thread des [lexicon]SSM[/lexicon]. Ich nutze die Funktion nicht, daher kann ich dazu nichts sagen.


    Zitat von RetroRuebe

    Wenn ich die VIdeodatei so mit [lexicon]VirtualDub[/lexicon] öffne, wird sie abgespielt allerdings nur mit der Tonspur vom Ingamesound


    Das ist normal, da Spiel und Stimme in getrennten Audiospuren vorhanden sind, wie bei einer DVD. Und bei einer DVD mit mehreren Sprachen willst du schließlich auch nicht, dass alle gleichzeitig abgespielt werden.


    Zitat von RetroRuebe

    [lexicon]Audacity[/lexicon] nehme ich meine Stimme auf, schöner Klang und so


    Da machst du dir das Leben nur unnötig schwer. Du hast bereits zwei perfekt synchronisierte Audiospuren, nimmst aber dennoch den umständlichen Weg über die Aufnahme mit [lexicon]Audacity[/lexicon].


    Zitat von RetroRuebe

    [lexicon]TMPGEnc[/lexicon]


    Finde ich ziemlich übertrieben für jemanden, der nur Anfang und Ende eines Videos wegschneidet.
    Natürlich ist damit auch deutlich leichter deutlich mehr möglich, aber nur um zwei Schnitte zu machen ist das aus meiner Sicht rausgeschmissenes Geld.

  • Ich weiß was ich mache, aber was mache ich eigentlich?

    Der [lexicon]Codec[/lexicon] muss dafür auch installiert sein, sonst klappt das natürlich nicht. UtVideo gibt es hier (Klick).
    Im [lexicon]Afterburner[/lexicon] das "Video Format" auf "VFW Kompression" stellen und danach rechts daneben auf "...", dort kannst du dann UtVideo auswählen.


    Wenn du etwas präzisere Empfehlungen bekommen möchtest, wäre es hilfreich wenn du deine Hardware samt Geschwindigkeitstest deiner Aufnahme-[lexicon]HDD[/lexicon] mit CrystalDiskMark hier postest.

  • Ich weiß was ich mache, aber was mache ich eigentlich?

    Bei meinen Erklärungen werde ich recht oberflächlich bleiben, Details wären zum aktuellen Zeitpunkt vielleicht etwas überfordernd.


    1.

    Zitat von RetroRuebe

    Frage: Die Datei die aufgenommen wird ist ja sher groß, soweit ich das jetzt genau verstanden habe, ist das so da diese Datei "Losless" ist? Also "Fehlerfrei" aufgenommen wird?


    Zitat von RetroRuebe

    Frage: Die Aufnahme wird von Overwolf direkt als [lexicon]MP4[/lexicon] gespeichert, ich habe gelesen andere Formate sollen besser sein, bzw Codecs aber wie sage ich denn nun meinem Programm, "Los mach das jetzt so!"


    "Als [lexicon]MP4[/lexicon] gespeichert" -> Mit 99% Sicherheit nicht verlustfrei ([lexicon]lossless[/lexicon]), sondern verlustbehaftet ([lexicon]lossy[/lexicon]).
    Wo du das umstellen kannst? In den Einstellungen des jeweiligen Programms. Gibt es dafür keine Einstellungen, so kann Overwolf das nicht.
    Keine Ahnung was für dich große Dateien sind, aber für mich normal sind beispielsweise 220GB für eine Stunde Aufnahme.


    Zitat von RetroRuebe

    Frage: Ist Overwolf schlechter als andere Aufnahmeprogramme und wenn ja, warum?


    Siehe oben, bietet Overwolf dafür keine Einstellungsmöglichkeit, so würde ich es bereits als schlechtes Programm einordnen. ^^


    2.

    Zitat von RetroRuebe

    Frage: Warum ist nun eine [lexicon]wav[/lexicon].datei besser als eine [lexicon]mp3[/lexicon]


    [lexicon]WAV[/lexicon] ist unkomprimiert und [lexicon]Lossless[/lexicon], [lexicon]MP3[/lexicon] ist komprimiert und [lexicon]Lossy[/lexicon], [lexicon]WAV[/lexicon] hat daher die bessere Qualität, bei großen Dateien.
    Gibt auch [lexicon]Lossless[/lexicon] und komprimiert, wie beispielsweise [lexicon]FLAC[/lexicon], selbe Qualität wie [lexicon]WAV[/lexicon], nur kleinere Dateien, allerdings größer als [lexicon]MP3[/lexicon].


    Zitat von RetroRuebe

    Frage: Sollte ich die Video-datei vor dem Bearbeiten "kleiner" machen oder versaue ich damit die Aufnahme?


    Bringt rein gar nichts und wird dir bei deiner Vorgehensweise die (sowieso nicht sonderlich gute) Qualität weiter verschlechtern.


    Zitat von RetroRuebe

    Frage: Mache ich etwas Falsch da ich das Video 2 mal bearbeiten muss im Movie Maker?


    Was meinst du mit "2 mal bearbeiten"? Anhand des Textes vermute ich, dass du das Video speicherst und dann nochmal in den Movie Maker ziehst?
    Wenn ja: Bei jedem Speichervorgang mit dem Movie Maker erleidet das Video massiven Qualitätsverlust.


    4.

    Zitat von RetroRuebe

    Frage: Was macht das Programm da eigentlich?


    [lexicon]Handbrake[/lexicon] komprimiert mit verlustbehaftetem Verfahren, eigentlich sinnlos in deinem Fall, da du schon ein verlustbehaftet komprimiertes Video vom Movie Maker bekommen hast.


    Zitat von RetroRuebe

    Frage: Was ist ein 20 RF?


    (C)RF ist die Qualitätsangabe, hierbei stehen geringere Werte für bessere Qualität und höhere für schlechtere.
    Beim (C)RF Verfahren werden alle Frames (Einzelbilder des Videos) mit gleicher Qualität kodiert, dafür wird dann so viel (oder wenig) [lexicon]Bitrate[/lexicon] verwendet wie nötig.


    5.

    Zitat von RetroRuebe

    Frage: Ist das normal, dass Videos so lange brauchen um hochgeladen zu werden (Natürlich spielt es hierbei eine Rolle was für eine Internetleitung man hat!...oder?)
    Frage: Kann man diesen ganzen Prozess irgendwie beschleunigen?


    Nein, lässt sich nicht beschleunigen außer durch eine Internetleitung mit besserem Upload.



    Grob gesagt ist dein Ablauf folgender:
    Overwolf (kenne ich nicht, [lexicon]lossy[/lexicon]) + [lexicon]Audacity[/lexicon] -> [lexicon]Windows Movie Maker[/lexicon] ([lexicon]lossy[/lexicon]) -> [lexicon]Windows Movie Maker[/lexicon] ([lexicon]lossy[/lexicon]) -> [lexicon]Handbrake[/lexicon] ([lexicon]lossy[/lexicon])
    Ich formuliere es mal sehr vorsichtig: Das ist mehr als suboptimal.


    Der hier häufig empfohlene Ablauf ist folgender:
    Lossless Aufnahme -> Verarbeitung -> Kodierung (Lossy)
    Die allerletzte Speicherung des Videos wird verlustbehaftet gemacht. Nicht, weil das die qualitativ beste Möglichkeit ist, sondern weil ein Kompromiss zwischen Uploadzeit und Qualität gemacht werden muss. Die meisten Internetleitungen würden sonst mit [lexicon]Lossless[/lexicon]-Videos viele viele Stunden beschäftigt sein.


    Für [lexicon]lossless[/lexicon] Aufnahme sind folgende Programme hier gebräuchlich:
    MSI Afterburner | Gaming Tutorial-Reihe [Beta] (kostenlos)
    Dxtory - Einstellungen & Sammelthread (kostenpflichtig)
    Open Broadcaster [Aufnahme] | Gaming Tutorial-Reihe (Für das besser geeignete [lexicon]OBS[/lexicon] Multiplatform gibt es leider noch kein Tutorial, beides kostenlos)


    Großer Vorteil: [lexicon]MSI Afterburner[/lexicon] und [lexicon]Dxtory[/lexicon] (sowie über Umwege auch [lexicon]OBS[/lexicon] Multiplatform) können den Spielsound und deine Stimme gleichzeitig in getrennten Audiospuren aufnehmen. So kannst du nachträglich Spiel und Stimme abmischen und das Synchronisieren von eben diesen entfällt.


    Für ganz simple Verarbeitung (Schneiden) reicht der SagaraS Scriptmaker (GUI).
    Für Audiobearbeitung ist [lexicon]Audacity[/lexicon] gut geeignet und für hochqualitative Kodierung (von Videobearbeitungsprogrammen auch gerne mal mit "[lexicon]Rendern[/lexicon]" gleich gesetzt) könntest du zu [lexicon]MeGUI[/lexicon] greifen:
    MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)


    Änderst du deinen Workflow hierauf um, so kannst du generell mit folgendem rechnen:

    • Größere Dateien bei der Aufnahme
    • Zeitersparnis beim Bearbeiten
    • Bestmögliche Qualität


    Bevor nun weiter erklärt wird, wäre es nun wahrscheinlich sinnvoll, wenn du dir die jeweiligen Programme anschaust und danach mögliche Fragen stellst oder deine Erwartungen erläuterst. ^^

  • Encoding-Talk

    Mehr als 4 Threads bringen mir bei 1080p Material keinen Performancevorteil, [lexicon]x264[/lexicon] lastet die [lexicon]CPU[/lexicon] trotzdem zu 100% aus und da mir schon ein paar Kodiervorgänge abgeschmiert sind, limitiere ich die aktuell auf 4.
    Geschwindigkeit war für meinen Test aber vollkommen irrelevant, letztlich ging es darum, dass vpxenc trotz 60FPS Angabe hinterher 59,94FPS in den [lexicon]WebM[/lexicon]-[lexicon]Container[/lexicon] schreibt. ^^

  • Encoding-Talk

    Prinzipiell richtig, da ich aber einen Größenvergleich von [lexicon]Lossless[/lexicon]-Encodes machen wollte, habe ich FFmpeg den 8Bit Input in 10Bit umwandeln lassen, da die 8-zu-10Bit Konvertierung bei vpxenc scheinbar anders läuft als über [lexicon]x264[/lexicon] und die [lexicon]Encoder[/lexicon] somit unterschiedliches Material kodierten. Unbrauchbar für einen Test.


    Hier mal die gesamte Zeile, samt FFmpeg:

    Code
    ffmpeg -v quiet -i "[input]" -pix_fmt yuv444p10le -f rawvideo - | vpxenc --fps=60/1 --i444 --input-bit-depth=10 --bit-depth=10 -w 2048 -h 1152 --best --passes=1 --profile=3 --frame-parallel=1 --lossless=1 -o "[output]" -


    Input ist ein [lexicon]Avisynth[/lexicon] Script mit folgendem Inhalt:

    Code
    SetMTMode(3,4)

    AVISource("E:\Capture\Dxtory\TBoIA-090.avi", audio=false).AssumeFPS(60,1)

    Trim(112020, 112139)

    Spline100Resize(breite, hoehe)

    ConvertToYV24(matrix = "Rec709", ChromaResample = "Spline16")

  • Encoding-Talk

    Keins davon, da FFmpeg damit nichts mehr zu tun hat, der 10Bit Encode lief via Pipe über vpxenc. Der 8Bit Encode, der direkt über FFmpeg läuft, ist einwandfrei.
    Die Parameter variierten bei mir immer etwas, da ich am ausprobieren war, aber grob sah es so aus:
    vpxenc --fps=60/1 --i444 --input-bit-depth=10 --bit-depth=10 -w 2048 -h 1152 --best --passes=1 --profile=3 --frame-parallel=1 --lossless=1 -o "[output]" -

  • Encoding-Talk

    Wenn vor dem [lexicon]Muxen[/lexicon] 59,94FPS und eine Dauer von 1,983 Sekunden drinsteht und hinterher 60FPS und 2 Sekunden, dann wird das sehr wohl etwas gebracht haben, wenn über [lexicon]MKVToolNix[/lexicon] die [lexicon]FPS[/lexicon] auf 60 gesetzt werden.
    Sowohl vor, als auch nach der Korrektur ist das Video 1:1 identisch mit dem [lexicon]Lossless[/lexicon] [lexicon]x264[/lexicon] Encode, was ich in einem der vorherigen Posts gezeigt habe.
    Eine reine [lexicon]FPS[/lexicon] Änderung bei gleicher Frameanzahl verändert die Frames selbst schließlich nicht.
    Vielleicht hat der [lexicon]Encoder[/lexicon] auch einfach nur falsche Daten im [lexicon]WebM[/lexicon] Header hinterlassen, ich weiß es nicht.
    Auf jeden Fall zeigte FFprobe nicht die 60FPS an, die ich vpxenc übergeben hatte.

  • Encoding-Talk

    Zitat von De-M-oN

    Man kann die [lexicon]FPS[/lexicon] doch bestimmt als Parameter angeben oder nicht?


    Ja, kann man auch. Muss man sogar, sonst bleibt er standardmäßig bei 30FPS, wenn rawvideo über FFmpeg eingespeist wird.
    Gebe ich aber 60/1 oder 60000/1000 an, kommt hinterher 59,94 raus. ^^
    Vielleicht übersehe ich auch eine Option, aber beheben kann ich das nur, wenn ich neu muxe.
    Ansonsten zählt das wohl als Bug dieses Builds.

  • Encoding-Talk

    Zitat von De-M-oN

    Ein [lexicon]CLI[/lexicon] [lexicon]Encoder[/lexicon] wäre halt schön


    Gibt es, allerdings sind die Binaries nicht direkt zum Download verfügbar, nur die Source. Oder ich suche an den falschen Stellen.
    Daher entweder selber kompilieren oder eine fertige Version im Internet finden.


    Falls jemand damit rum spielen möchte, Version 1.5.0 gibt es beispielsweise bei Doom9.
    Die Parameter sind aber sehr dürftig dokumentiert, wenn überhaupt. Beinhaltet anscheinend auch teils schon VP10 Code.
    Nehmt euch aber sehr viel Zeit, wenn ihr etwas davon ausprobieren solltet. Dauert bei mir irgendwie immer 10x bis 20x länger als mit [lexicon]x264[/lexicon]. ^^


    Edit: Oh, wie ich in meinem letzten Post schon geschrieben habe, der [lexicon]Encoder[/lexicon] verhaut mir bei 60FPS Encodes immer die [lexicon]FPS[/lexicon] Angabe und schreibt dort immer 59,94 rein. Einmal neu [lexicon]muxen[/lexicon] und dabei die [lexicon]FPS[/lexicon] Angabe korrigieren reicht hierbei. ^^

  • Encoding-Talk

    Auch FFmpeg kann [lexicon]Lossless[/lexicon] [lexicon]VP9[/lexicon] kodieren, man füge dafür zu libvpx-[lexicon]vp9[/lexicon] den -lossless 1 Parameter hinzu, die Angabe in der Übersicht dazu ist daher wohl falsch. Die 8Bit [lexicon]Lossless[/lexicon] Encodes auf der vorherigen Seite kamen auch von FFmpeg.
    Für mehr als 8Bit ist aktuell vpxenc vonnöten, ist über FFmpeg bisher nicht möglich.

  • Encoding-Talk

    @Sagaras
    Auch [lexicon]VP9[/lexicon] beherrscht 10Bit Kodierung. Seit wann genau weiß ich allerdings nicht.


    Hier zwei zwei [lexicon]MediaInfo[/lexicon] von unabhängig voneinander kodierte Videos ([lexicon]Lossless[/lexicon], 10bit, YUV444) mit dem selben Quellmaterial.
    Video 1:


    Video 2 ([lexicon]VP9[/lexicon]):


    Da die [lexicon]MediaInfo[/lexicon] des [lexicon]VP9[/lexicon] Encodes recht wenig aussagt, hier nochmal die Ausgabe von ffprobe:


    Das [lexicon]VP9[/lexicon] Video musste nochmal neu gemuxt werden, da mir sonst immer nur ein 59,94FPS Video ausgegeben wurde, trotz 60FPS Angabe beim Encode.


    Zum Schluss die Absicherung, dass das dekodierte Videomaterial identisch ist via ffmpeg -loglevel error -i "[input]" -map 0:v -f md5 -.

    [lexicon]x264[/lexicon]-Encode

    [lexicon]VP9[/lexicon]-Encode

    MD5=4ac12cf8ca4b47e858f2f5322e79df99

    MD5=4ac12cf8ca4b47e858f2f5322e79df99


    Ergebnis ist identisch, wenn ich also keinen Fehler gemacht habe, dürfte es sich hierbei um zwei vollkommen gleichwertige 10Bit Encodes handeln. ^^
    Nutzen würde ich [lexicon]VP9[/lexicon] trotzdem nicht, aus den von dir schon genannten Gründen.

  • Encoding-Talk

    Ist zwar ein Zitat aus einem anderem Thread, passt thematisch aber am ehesten hierhin.


    Zitat von De-M-oN

    Auch kann [lexicon]VP9[/lexicon] nichts höheres als 4:2:0.


    Woher hast du diese Info? Es mag letztlich wahrscheinlich nicht relevant sein, da [lexicon]x264[/lexicon] höchstwahrscheinlich die bessere Wahl bleibt, aber nach einer Überprüfung mit ffmpeg -h encoder=libvpx-vp9 erhalte ich folgendes Ergebnis:
    Supported pixel formats: yuv420p yuv422p yuv440p yuv444p


    Da mir eine einfache Angabe nicht ausreicht, habe ich mal zwei YUV444 [lexicon]Lossless[/lexicon]-Encodes über FFmpeg ausgetestet. Hier dazu die [lexicon]MediaInfo[/lexicon] der [lexicon]x264[/lexicon] Variante:


    Und die des [lexicon]VP9[/lexicon] Encodes, wenn auch recht nichtssagend:


    Um herauszufinden ob diese beiden Encodes identisch sind, habe ich ffmpeg -loglevel error -i "[input]" -map 0:v -f md5 - genutzt.
    Dabei kam folgendes heraus:

    [lexicon]x264[/lexicon]-Encode

    [lexicon]VP9[/lexicon]-Encode

    MD5=088f78adfb30ffeb6c4d49631cf0eb20

    MD5=088f78adfb30ffeb6c4d49631cf0eb20


    Nach berechnetem MD5-Hash des dekodierten Videomaterials durch FFmpeg sind beide Videos somit vollkommen identisch.

  • Encoding-Talk

    Alternativ kann man auch einfach über [lexicon]MeGUI[/lexicon] schneiden, kombiniert einmaliges Bearbeiten in [lexicon]Audacity[/lexicon] mit Verarbeitung außerhalb des Scripts.

  • Encoding-Talk

    @GelberDrache92
    Einfach ja, dauert aber viel zu lange bis die [lexicon]AVI[/lexicon] neu geschrieben ist, daher zeitaufwendig. Abgesehen vom Speicheraufwand.
    Alternativ einfach über [lexicon]AviSynth[/lexicon] erledigen, @SiggySmilez.
    Hierfür die jeweiligen Audiospuren ohne Cuts über den [lexicon]SSM[/lexicon] extrahieren. Diese bearbeitest du in [lexicon]Audacity[/lexicon] und speicherst diese darauf als [lexicon]WAV[/lexicon].
    Nun erstellst du dir einfach eine AVS-Datei mit folgendem Inhalt:


    Code
    AVISource("X:\Pfad zum Video hier\Deine Videodatei.avi").AudioDub(WAVSource("Y:\Pfad\zur\WAV\Deine Audiospur.wav"))


    In diesem [lexicon]AviSynth[/lexicon] Script wird die Audiospur der [lexicon]AVI[/lexicon] durch den Sound der bearbeiteten [lexicon]WAV[/lexicon] ersetzt.
    Diese AVS kannst du wie eine ganz gewöhnliche Videodatei in den [lexicon]SSM[/lexicon] ziehen und weiter verarbeiten mit Cuts oder abspielen in bspw. [lexicon]MPC[/lexicon]-HC zur Begutachtung.

  • Dxtory - Einstellungen & Sammelthread

    Natürlich ist es ärgerlich wenn eine [lexicon]Festplatte[/lexicon] ausfällt, aber wenn meine Aufnahmeplatten ausfallen sollten, ist mir das eigentlich recht egal im Vergleich zu den restlichen Festplatten.
    Warum? Weil da nur [lexicon]Rohmaterial[/lexicon] drauf ist, welches später eh wieder gelöscht wird.
    Da fände ich es für mich viel schlimmer, wenn die [lexicon]HDD[/lexicon] ausfallen sollte, die alle kodierten und hochgeladenen Folgen beherbergt und somit alles, was ich überhaupt mal aufgenommen habe. Das Thema kommt mir auch gerade sehr bekannt vor und war bei dir wohl sowieso ein Sonderfall, wenn ich mich nicht irre.


    Edit: Den verlinkten Artikel habe ich schon mal in ausführlicherer Form gesehen und dort wurden, wenn ich mich richtig erinnere, weder die 1TB noch die 2TB Platten (welche ich verwende) von Seagate erwähnt. Gehört aber wohl nicht in diesen Thread, sondern eher in den [lexicon]HDD[/lexicon]-Thread.

  • Dxtory - Einstellungen & Sammelthread

    Zitat von Schauerland

    Ich spiele grad mit [lexicon]OBS[/lexicon] Multiplatform und utvideo via ffmpeg rum, leider ist das Ergebnis immer ULH0


    die Parameter müsste man in [lexicon]OBS[/lexicon] so setzen können:


    pix_fmt=yuv422p pred=median


    Hatte ich auch schon mal vor längerer Zeit probiert und klappte nicht wirklich, schien bei mir damals auch nur Single-Threaded zu sein, also völlig unbrauchbar.
    Solange FFmpeg aber kein Multitrack Recording beherrscht, wird das für mich aber sowieso nicht in Frage kommen.


    Zitat von SiggySmilez

    Was für eine mindest schreibgeschwindigkeit der [lexicon]hdd[/lexicon] würdet ihr dafür denn empfehlen?


    Lässt sich nicht pauschal beantworten, umso mehr, umso besser. Hängt letztlich vom jeweiligen Spiel, dem verwendeten [lexicon]Codec[/lexicon] sowie [lexicon]Auflösung[/lexicon], [lexicon]FPS[/lexicon] und Farbraum ab.


    Zitat von SiggySmilez

    sind 200mb/s denn ausreichend für 1080p60fps?


    Solange man nicht gerade im RGB Farbraum aufnehmen möchte und stattdessen bei YUV422 oder gar YUV420 bleibt, würde ich dem bedenkenlos zustimmen. Gerade bei der [lexicon]HDD[/lexicon] sollte man nicht zu knapp kalkulieren, denn erstens mögen diese es gar nicht, wenn sie voll ausgelastet werden und zweitens werden sie langsamer je mehr Speicherplatz belegt ist.


    Zitat von Schauerland

    Ich würde keine Seagate mehr nehmen.


    Der obligatorische Kontra-Beitrag: Meine Seagates erfreuen sich ihres Lebens und leisten gute Arbeit im RAID0.