Aufnahmeeinstellungen + Rendering

    Zitat von Sanexius

    doch klar ich speichere sie auf die ssd und verschiebe sie auf die hdd obwohl meine HDD eigentlich auch recht gut ist mit ca 180mb/S


    Dann würde das aber wenig Sinn machen wenn deine HDD sowieso schon 180mb/s kann. Mehr würde darauf garnicht geschrieben werden bei 1080p.
    Auf der HDD hättest du auch mehr Platz und dein System wäre was schneller weil nicht ganze Zeit auf der SSD geschrieben wird.
    Man sollte eigentlich nie Aufnehmen und das System/Spiele auf der gleichen Platte haben.

    Zitat von Karmaalp

    Dann würde das aber wenig Sinn machen wenn deine HDD sowieso schon 180mb/s kann. Mehr würde darauf garnicht geschrieben werden bei 1080p.
    Auf der HDD hättest du auch mehr Platz und dein System wäre was schneller weil nicht ganze Zeit auf der SSD geschrieben wird.
    Man sollte eigentlich nie Aufnehmen und das System/Spiele auf der gleichen Platte haben.

    das spiel ist auf der hdd gespeichert, das aufnahmeprogramm auf der ssd.
    sollte das program was auf der ssd gepseichert ist die videos auf die hdd speichern?
    so meinst du es`?

    Grundsätzlich würde ich empfehlen: SSD für Windows, Programme und Spiele, HDD nur für die Aufnahme. Letztendlich macht es keinen großen Unterschied, wo das Aufnahmeprogramm installiert ist, da während der Aufnahme keine Festplattenlast vom Aufnahmeprogramm selbst kommt.

    Zitat von Julien

    Grundsätzlich würde ich empfehlen: SSD für Windows, Programme und Spiele, HDD nur für die Aufnahme. Letztendlich macht es keinen großen Unterschied, wo das Aufnahmeprogramm installiert ist, da während der Aufnahme keine Festplattenlast vom Aufnahmeprogramm selbst kommt.

    Zitat von Julien

    Grundsätzlich würde ich empfehlen: SSD für Windows, Programme und Spiele, HDD nur für die Aufnahme. Letztendlich macht es keinen großen Unterschied, wo das Aufnahmeprogramm installiert ist, da während der Aufnahme keine Festplattenlast vom Aufnahmeprogramm selbst kommt.

    bei 120 gb ssd wäre das nicht so gut die games auf die SSD zu installieren

    Ich bin ja mal gespannt, was ab Februar so passiert, wenn AMD mit Ryzen kommt und sich SMT plus Multicore langsam etabliert. Die Encodierzeiten werden bei den neuen Prozessoren ja deutlich besser als z.B. mit einem i5. Mit meinem i7 3930k@stock encodiere ich ein 2 Stunden Video in 1080p in knapp 4 Stunden, wenn es sich um komplexes Material handelt (Ego Shooter, Gras....ich hasse Gras^^).Und die neuen Ryzen sind laut Blender-Benchmark einen Tacken schneller als mein 3930k. Mein alter i5 3570k, der in etwa auf Augenhöhe mit dem i5 6500 sein dürfte, ist weniger als halb so schnell wie der 3930k.

    Ich nehme mit OBS bzw. Fraps auf und schneide mit dem PowerDirector von CyberLink. Ich habe einen i7, die GTX 980, Programme laufen auf der SSD, 16GB RAM. Die Kodierung (.264) dauerte bei Videos von 20 min. (1080, 60fps) in der Regel auch eine Stunde; wenn ich aber auf Hardware-Videokodierung schalte (im PowerDirector auswählbar), werden daraus schnell nur noch sechs Minuten. Länger kann es wieder
    werden, wenn abgesehen vom Rendern noch Dinge vor der Kodierung geändert werden, d. h. viele Schnitte gesetzt, Filter draufgelegt etc.

    Ja, bei den Encodier-Vorgängen ist meistens (wenn man es nicht auf die Grafikkarte legen kann), der Prozessor eben entscheidend. Habe ich auch gemerkt, als ich damals von meinem i5-3470 auf den Xeon 1231 gewechselt bin. Die Encodierzeiten betrugen nur noch die Hälfte bis zu zwei Drittel der Zeit von vorher und auch Battlefield 3 ließ sich auf einmal flüssig streamen. Fürs reine Zocken ist ein guter i5 meist völlig ausreichend, wenn es dann aber um's Aufnehmen und die Videobearbeitung geht, geht der auch recht schnell mal in die Knie.


    Die langsame Verarbeitungsgeschwindigkeit von H264-Material kann ich übrigens auch bestätigen. Als ich anfangs meine Streams mit x264 und qp=0 aufgenommen habe, hat das Encodieren mit MeGUI auch rund doppelt so lange gedauert, wie vergleichbares Material, was ich über DxTory aufgenommen hatte.

    Zitat von Peacemaker666

    Die langsame Verarbeitungsgeschwindigkeit von H264-Material kann ich übrigens auch bestätigen. Als ich anfangs meine Streams mit x264 und qp=0 aufgenommen habe, hat das Encodieren mit MeGUI auch rund doppelt so lange gedauert, wie vergleichbares Material, was ich über DxTory aufgenommen hatte.

    Was aber auch ganz normal ist, da einer seits das Decodieren mir Leistung in Anspruch nimmt, aber der Hauptfaktor bei dir ist das das Material in Avisynth mit FFMS2 geladen werden muss und diese Laderotine läuft dann nur auf einem Thread

    Zitat von GelberDrache92

    und diese Laderotine läuft dann nur auf einem Kern

    Auf einen Thread. Nicht mit Kern verwechseln.


    Bei Hyperthreading laufen 2 Threads auf ein Kern.
    Im Normalbetrieb oft 1 Thread auf ein Kern


    1 Thread ist sozusagen 1 Ausführungsreihenfolge innerhalb eines Prozesses. Threads kannst du daher nicht sehen, weil Virtuell. ;D
    Sprich jeder CPU Kern kann nur eine Ausführungsreihenfolge erledigen. Und eine CPU kannst du sehen. Ist also Physisch. ^^
    Nicht zu verwechseln jetzt das man in Windows mehrere Programme starten lassen kann. Die würden alle, sofern sie mit 1 Thread programmiert worden sind der Ausführungsreihenfolge auf einen Kern arbeiten.


    In einem Thread arbeitet der SSM, wenn aber VirtualDub aufgerufen wird, wird im Thread der Prozess pausiert für SSM, so das der SSM in einem Warteprozess liegt und auf eine Rückmeldung von VirtualDub wartet das es geschlossen wurde.
    Würde man das nicht machen würde VDub und SSM gleichzeitig verarbeiten und es würde zu Fehler kommen.
    Dennoch arbeiten beide nur auf einen Kern. Nur das ich den Threadprozess für ein Programm pausiert habe.
    Sprich es können mehrere Aufgaben auf einem Thread gelegt werden die Simultan ablaufen.


    Bei Hyperthreading hat man einen zusätzlich virtuellen Thread um die ganze CPU Leistung auszuschöpfen. Weil eine CPU meist noch brach liegt und gut zu 35 - 50% nur genutzt wird. Mit Hyperthreading kann man dann diese zu gut 100% nutzen, dank zusätzlichen Thread.


    Bedeutet ein 16 Kerner kann mit Hyperthreading max. 32 Threads beinhalten. Und das kann man beim SSM z.B. bei Multithreading einstellen als Maximal Wert.


    Im SSM selbst kann man aber L-Smash nutzen. Anders als FFMS2 arbeitet L-Smash mit mehreren Threads. Jedoch ist es dann meist von Vorteil den Multithreading Prozess von AVISynth ganz abzuschalten oder zumindest die Sourcen kein Multithreading zuzuweisen. Denn L-Smash hat von Haus aus Multithreading. Muss aber nicht limitiert werden.


    Problem bei L-Smash ist aber das es ganz schnell auch mal nach hinten los gehen kann. Kommt dann auf das Quellmaterial an. Diesbezüglich hat L-Smash auch 2 Einleseverfahren. 1mal mit der LibAV Bibliothek was dem FFMS2 sehr ähnlich ist. Und dem ohne der LibAV Bibliothek. Da werden dann nicht mehr so viele Formate unterstützt. Hauptsächlich aber AVC kodierte Materialien. Und das auch nicht alle Problemlos. Da sollte man dann vorsichtig sein.


    Beim SSM habe ich FFMS2 genommen, da dieser A) mehr Formate unterstützt und B) die Verarbeitung recht zuverlässig auch ist.
    Allerdings mit einem Thread nur, aufgrund das es Probleme geben kann wenn mehrere Threads dafür verwendet werden würden.



    Dennoch ist eine H264 Aufnahme die Lossless geschah in einen Video-Stream drin der mit Decodern dekodiert wird, die an sich für Verlustmaterial ausgelegt sind. Und so ist auch der Video-Stream. Sprich in einem lossless H264 Video Stream sind immernoch alle Elemente einer Verlustkompression vorhanden, auch wenn die Frames Vollbilder meist darstellen.
    Das macht auch die Aufnahmenverarbeitung auch so langsam bei solchen Aufnahmen.


    Bei UtVideo oder MagicYUV gibt es nix im Video Stream was auf einen Verlustcodec hindeutet. Da ist halt auch nicht viel drin. Da gibt es nur den Header und die Video Daten. Und die Video Daten sind noch komprimiert. Alle Frames sind dann I Frames.


    Bei H264 Lossless ist nicht jeder Frames ein I Frame, sondern ab und an sind auch P Frames mit dabei.


    Das sind so alles Faktoren.


    Also wer meint das H264 besser für Aufnahmen geeignet ist, der ist auf dem Holzweg ^^
    Selbst mit GPU Unterstützung wie bei NVenc bei der Aufnahme, wird die Verarbeitung wieder auf das Grundproblem treffen. Decodierung des Inhalts. Und der dauert dann. ^^

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden