Beiträge von Kayten

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Mit MT im [lexicon]SSM[/lexicon] angehakt sind SetMTMode(3) vor den Quellen und SetMTMode(2) vor den Filtern normal.
    Funktioniert bei meinem modifiziertem Script aber halt nicht zuverlässig. Daher die Frage, welche Vorgehensweisen generell zu Problemen mit MT führen können.


    Zitat von Spieluin

    Ich habe mit MT 2 bis zu 65 [lexicon]FPS[/lexicon] erreicht mit einem Xeon E3 1231v3.


    Als Vergleichsbasis reicht das nicht aus, ich kodiere in YV24, CRF19, 10Bit. Warum? Weil meine Hardware das zeitlich erlaubt.
    Desweiteren ist die Komplexität des Videos entscheidend.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Ist zwar eher eine [lexicon]Avisynth[/lexicon] Frage, passt aber wohl am ehesten hier hin.
    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.
    Ich habe beispielsweise ein modifiziertes Script aus dem [lexicon]SSM[/lexicon], welches bei Standard MT Einstellungen die unterschiedlichsten Probleme aufweist beim Kodieren, über Bildfehler bis hin zum Crash. Das [lexicon]Quellvideo[/lexicon] hat eine geringe [lexicon]Auflösung[/lexicon] von 512x192.
    Ohne MT kodiert es einwandfrei, aber dafür qualvoll langsam mit gerade ~10FPS.
    Meine Erkenntnisse bisher waren nach vorsichtigem Einfügen des SetMTMode Befehls:

    • SetMTMode(2) vor den Filtern bringt einen vernachlässigbaren Geschwindigkeitsvorteil, wenn die Kodierung den Großteil der [lexicon]CPU[/lexicon] beansprucht, verursacht (von alleine) aber auch keine Probleme.
    • SetMTMode(3) vor AVIload/AVISource führt zu einem enormen Geschwindigkeitsvorteil auf insgesamt ~30FPS, sorgt aber in Kombination mit SetMTMode(2) vor den Filtern für Crashes/Bildfehler und ohne dieses sind vereinzelt falsche Frames im Endvideo vorhanden.
    • SetMTMode(3,1) verhält sich genau wie ohne MT, was nicht verwundert, da nur ein Thread aktiv ist.
    • SetMTMode(3,2) und SetMTMode(3,3) lassen die [lexicon]FPS[/lexicon] quasi linear skalieren auf ~20, respektive ~30FPS und scheinen bisher auch keine Fehler zu produzieren, ob nun zusammen mit SetMTMode(2) oder ohne und lassen sogar bis zu 33% [lexicon]CPU[/lexicon] Reserven offen.

    Mehr habe ich bisher noch nicht getestet. Entspricht das ungefähr den Erfahrungen, die andere mit MT gemacht haben?
    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)?

  • [Referenz] Die perfekte Festplatte

    Hatte hier geschrieben, dass ich mich nochmal mit meinem RAID0 auseinandersetze, wenn ich einen anderen Chipsatz habe.
    Das ist nun der Fall und daher hier mal ein paar Vergleiche, vielleicht auch für @De-M-oN interessant.



    Manches mag unter die Messtoleranz fallen, aber der Einbruch der Random 512KB-Schreibgeschwindigkeit beim Write-Back gehört wohl nicht dazu. Was das nun genau aussagt kann ich aber nicht beantworten.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat von Sazoga

    HFR (mind. 41FPS): Check - wobei YouTube mir als Stufe 48 anzeigt, warum auch immer


    YouTube zeigt im Player nicht mehr die genaue [lexicon]FPS[/lexicon] Zahl an, sondern nur noch manche Zwischenstufen um die Denkapparate mancher Menschen zu schützen. In den Statistiken für Computerfreaks stehen weiterhin die genauen [lexicon]FPS[/lexicon].


    Zitat von Sazoga

    VP 9 Codierung: Check - zusammen mit HTML5


    Wo das? Bei mir hast du ganz offensichtlich kein [lexicon]VP9[/lexicon] sondern nur den H264 Encode. Das ist daher auch der Grund, warum du kein 1152p@HFR bekommst.
    Entweder länger warten bevor du das Video veröffentlichst und hoffen, dass du so bereits [lexicon]VP9[/lexicon] bekommst oder Neukodierung über Video verbessern erzwingen, dann sollte (wahrscheinlich, nicht garantiert) [lexicon]VP9[/lexicon] mit 1152p@HFR verfügbar sein.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Die Videos würde ich an deiner Stelle nicht löschen, sonst musst du die komplett neu kodieren.
    Wenn nur die Audiospur fehlerhaft ist, würde ich diese einfach korrigieren in bspw. [lexicon]Audacity[/lexicon] und neu mit dem Video [lexicon]muxen[/lexicon].
    Womit nimmst du auf? Bearbeitest du die Audiospuren in [lexicon]Audacity[/lexicon] oder sonst irgendwie? [lexicon]MediaInfo[/lexicon] einer Aufnahme?

  • MSI Afterburner - Kostenlose Alternative zu FRAPS und DxTory!

    @obiwanjunobi
    [lexicon]Dxtory[/lexicon] v2.0.0.130


    Passende [lexicon]MediaInfo[/lexicon] dazu:


    Kann bisher auch nicht nachvollziehen, warum das bei so vielen Probleme machen soll. Hatte bisher mit dem AB mehr Probleme als mit [lexicon]Dxtory[/lexicon].

  • MSI Afterburner - Kostenlose Alternative zu FRAPS und DxTory!

    Das wird höchstwahrscheinlich nichts am Interleave ändern, meine letzten Aufnahmen mit [lexicon]Dxtory[/lexicon] hatten alle einen Interleave-Wert von 100ms (6.00 video frames) bei 60FPS trotz HPET und sind synchron. Ich kenn die Bedeutung der Zahl nun nicht, aber einen negativen Einfluss konnte ich nun nicht feststellen.


    Wir bräuchten dringend einen eigenen allgemeinen Thread für Probleme mit [lexicon]Dxtory[/lexicon].

  • [Referenz] Die perfekte Festplatte

    Würde mich stark wundern, wenn die jeweilige SATA Geschwindigkeit zwischen den Festplatten aufgeteilt wird.
    Vielleicht gibt es da auch Unterschiede zwischen den Controllern, aber bei mir scheint jede [lexicon]Festplatte[/lexicon] annähernd volle SATA 2 Geschwindigkeit zu bekommen, meine [lexicon]SSD[/lexicon] wird auf ~265MB/s (CDM, lesend) begrenzt.


    Mal davon ab: Ich hüpf im Kreis! \o/
    Zumindest beim kurzen Test konnte ich mit mehr Ingame-[lexicon]FPS[/lexicon], besserem Farbraum und vollständig ohne auch nur einen einzigen gedroppten [lexicon]Frame[/lexicon] aufnehmen. Auch wenn die [lexicon]Bitrate[/lexicon] absoluter Overkill ist, selbst für das RAID, aber es ging!



    Ein leicht komprimierender, [lexicon]CPU[/lexicon] schonender [lexicon]Codec[/lexicon] wäre für mich ganz vorteilhaft, denn bei der Aufnahme oben hatte ich sogar tatsächlich wieder [lexicon]CPU[/lexicon] Reserven und das RAID wird die Schreibgeschwindigkeit wahrscheinlich auch nicht allzu lange mitmachen. UtVideo bringt mich teils häufig wieder ins [lexicon]CPU[/lexicon] Limit, unabhängig von den Einstellungen. [lexicon]Dxtory[/lexicon] [lexicon]Codec[/lexicon] mit YUV422 wäre ganz nett.

  • [Referenz] Die perfekte Festplatte

    Die Auswirkung der Sektorengröße scheint auch recht gering zu sein, wenn nicht sogar nachteilig bei höheren Werten. Nach mehrmaligem Wechseln der Sektorengröße (Schnellformatierung) mit anschließendem 10GB Test über [lexicon]Dxtory[/lexicon] komme ich auf ~363MB/s für 4KB und ~360MB/s für 64KB. Mit Einbezug der Messtoleranz lässt sich wohl sagen, dass es keinen Unterschied macht. Subjektiv steigt die Schreibgeschwindigkeit bei 4KB schneller an das Maximum.


    Zitat von De-M-oN

    Und mein RAID 0 an SATA 2 stecken will ich erstrecht net.


    Weshalb? Die Bedeutung von SATA 3 für HDDs scheint recht gering zu sein, denn mein [lexicon]Mainboard[/lexicon] kennt das nicht mal und scheint das RAID trotzdem ausreizen zu können.
    Keine Ahnung was bei mir nun der entscheidende Faktor ist, vielleicht ist es die Datenstreifengröße, vielleicht der Chipsatz, vielleicht sind meine 2TB HDDs tatsächlich etwas schneller.
    Wenn ich eine neue [lexicon]CPU[/lexicon]+MB Kombination besitze schaue ich mir die Werte noch mal an.

  • [Referenz] Die perfekte Festplatte

    Zitat von De-M-oN

    Und ich sehe gerad, das ich bei mir selber bloß die Datenstreifengröße auf 128 kb habe, aber cluster noch der standard von 4096 bytes.


    Ist eine höhere Datenstreifengröße besser? Ich könnte bis zu 256KB wählen.


    Hier mal meine Einstellungsmöglichkeiten:

    [IMG: http://abload.de/img/raid0settingsbpo60.png]


    Sektorengröße lässt sich bestimmt nachträglich über Windows ändern, ansonsten ist hier 4 KB das Maximum.
    Read & Write Policy lassen sich nicht ändern. "Gigabyte Boundary" klingt aus meiner Sicht falsch, kann ich aber nicht wirklich sagen.


    Edit: Mit 256KB Datenstreifengröße statt 64 und naiv gewählter Sektorengröße von 64KB (über Windows) sieht das Ergebnis nun wie folgt aus:


    Scheint daher was gebracht zu haben. ^^

  • [Referenz] Die perfekte Festplatte

    Da ich mir eine neue 2TB Seagate ST2000DM001 zugelegt habe um ein RAID0 zu bilden, teile ich hiermit die Daten der [lexicon]HDD[/lexicon], denn sie unterscheiden sich doch nicht gerade wenig von meiner bisherigen.



    Wie man sieht ist ein Geschwindigkeitsunterschied von ungefähr 10% vorhanden.
    Frage hierzu für die ich keinen extra Thread erstellen wollte: Ist ein RAID0 trotz der leicht unterschiedlichen Geschwindigkeiten unproblematisch?

  • MagicYUV - Ein neuer Lossless Codec!

    [lexicon]MagicYUV[/lexicon] wird aktuell nicht empfohlen aus diesem Grund und erste Wahl sollte daher im Moment UtVideo sein.
    Idealerweise UtVideo YUV422 BT.709 VCM, entweder mit Predict Median (Höhere [lexicon]CPU[/lexicon] Belastung) oder Predict Left (Höhere [lexicon]HDD[/lexicon] Belastung).


    Solltest du dennoch bei [lexicon]MagicYUV[/lexicon] bleiben wollen, würde ich den Haken bei Auto-Detect entfernen und die Anzahl der Threads manuell einstellen. Ausprobieren bis man das Optimum gefunden hat hilft da meist. Ansonsten sind das fast die Standardeinstellungen von [lexicon]MagicYUV[/lexicon]. Ob du die Compression method verändern willst musst du selber wissen, damit verschiebst du die Belastung zwischen [lexicon]CPU[/lexicon] und [lexicon]HDD[/lexicon].

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    1152p mit 41FPS ist so ziemlich das Optimum in Sachen Bildqualität, was man aktuell erreichen kann auf YouTube.
    Statt 1152p könntest du auch 1800p probieren, dann hättest du wieder die Originale 1080p Stufe, aber auf der 1440p Stufe wird dann das 1800p Video abgespielt mit der [lexicon]Bitrate[/lexicon] eines 4K (2160p) Videos.
    Wobei ich mir wegen diesen Testvideos und @De-M-oNs Kommentar dazu nicht wirklich sicher bin, ob sich 1800p überhaupt lohnt gegenüber 1152p.


    Wenn dir die Framerate nicht so wichtig ist, kannst du natürlich auch die Aufnahme-[lexicon]FPS[/lexicon] weiter verringern. Beispielsweise mit 24FPS aufnehmen, was früher häufiger gemacht wurde, als es HFR noch nicht gab. Das würde die Bildqualität weiter steigern da es wenigere unterschiedliche Bilder gibt, die sich die [lexicon]Bitrate[/lexicon] teilen. Ob das sinnvoll ist, musst du selbst entscheiden. Ich persönlich halte das für absolut unsinnig und bevorzuge hohe [lexicon]FPS[/lexicon] Raten, aber ich sehe auch fast immer einen Unterschied zwischen 50 und 60FPS Gameplay. ^^

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    @PlebUnity
    Idealerweise direkt mit 41FPS aufnehmen. Vorausgesetzt natürlich, das Spiel läuft auch mindestens mit 41FPS, was ich bei ARK aber aktuell eher bezweifle.
    Alternative wäre mit bspw. 30FPS aufzunehmen und nachträglich auf mindestens 41FPS hoch rechnen zu lassen. Ob das direkt so in Vegas funktioniert weiß ich nicht.
    Dann würdest du, wie bereits erwähnt, den HFR Encode auf YouTube bekommen, wodurch dein Video eine höhere [lexicon]Bitrate[/lexicon] erhält und besser aussieht.