Beiträge von De-M-oN

    ok also 4:2:2
    Und du konvertierst das gerad auf 4:2:0 runter. Beabsichtigt?
    x264, custom commandline hat ein --output-csp mit dabei? Wenn nicht würde es eh zu YV12 (4:2:0) konvertiert werden.


    Das sollte jedoch nicht die FPS auf 5 runter drücken. Aber vllt mal schnelleres Preset als slow versuchen. Medium zb.

    Was hat der YV12 Konvert da unten verloren? Du hast MeGUI eine YV12 konvertierung adden lassen. Das kostet bereits Zeit und falls du höheres als YV12 (4:2:0) verwendest auch Qualität und schmeißt das höhere weg nur um es anschließend wieder aufzublasen mit output-csp.
    Bedenke auch, das du für die avs4x264mod pipeline nur YV12, YV16 oder YV24 in SSM verwenden kannst.


    Auch würd ich dir eher Spline36 empfehlen.

    Bermuda Syndrome würde mir da höchstens einfallen. Kann mich aber jetzt nicht an einem Roller erinnern. Hab aber auch nur damals den Beginn des Spiels angespielt.

    Deswegen hatte mich das Material interessiert. Dass bei quasi Standbildern eine niedrige Bitrate ausreicht, sollte mehr als klar sein.

    Brauchst doch nur auf die Encodeeinstellungen gucken. Da steht CRF21, von daher isses CRF Encode.


    Aber ich würde nicht nur 1920x1080 auf youtube hochladen, das geht bei halbwegs komplexerem Material nicht gut aus.



    kann das video kann viel b-frames nutzen (GOP Max = 0)

    b-frames hat er auf 0. Aber ja bei inkomplexem material würden die nochmal ordentlich die Dateigröße reduzieren :D

    Hm, vielleicht stell ich mich da etwas blöd an, aber ich dacht halt die Größe/Quali kommt von der Auflösung und den FPS. Wo genau spielt die Bitrate da rein? In der Auflösung/Qualität der einzelnen Frames, oder wie? ^^'

    Die Größe des Frames sagt dir ja nichts über die Qualität des Frames.

    Woanders hab ich dann wieder gelesen, man solle für YouTube-Upload nicht VBR nutzen, sondern CBR?

    Wer so'n Quatsch empfiehlt gehört echt geschlagen, CBR sollte man NIE empfehlen.


    CBR 2500 kbit Bitrate:
    http://killerinstinct.ath.cx:2…20x1080-2500kbit-CBR.html


    VBR 2pass 2500 kbit:
    http://killerinstinct.ath.cx:2…0-2500kbit-VBR-2pass.html


    Hier kann man schön sehen, wie der unwichtige, dunkle Teil bei Doom bei CBR besser von weg kommt, da diese ja ebenso mit 2500 läuft und dann der komplexe, wichtige Teil eben auch nur 2500 abbekommt wegen CBR.
    Bei VBR wird beim dunklen Teil weniger Bitrate genommen, damit der komplexe, wichtige Teil erheblich besser von weg kommt. Macht Sinn :)

    MPEG 2 ist selbstverständlich nicht lossless, im Gegenteil ^^



    Rendere mit Vegas 13 in Sony AVC/MVC | AVC, 1920/1080, Cabac,
    60 FPS, 25.999.360 Bitrate in MP4

    das solltest du in jedem Fall anders machen. Und Ark in nur 1920x1080? Ich möchte nicht wissen, wie stark die Blockpampe dann auf Youtube ist. Da schauert ja schon der Gedanke daran bereits :S
    Erstrecht bei solch schwer komprimierbaren Spielen sollte man in jedem Fall Youtube nicht bloß 1080 geben. Das kann einfach nicht gut gehen.
    Auch trau ich dem extrem ineffizienten Encoder von Vegas keine saubere Qualität bei Ark mit 26mbit zu.

    Peak bitrate sollte gar nicht erst beschränkt werden
    Und die Average Bitrate wird nicht erfüllt, weil du nur 1pass encodierst und MainConcept auch alles andere als ein guter H.264 Encoder ist. Dazu gibt es kaum Einstellungen zum Encoder.
    Das bitratenratespiel müsste gar nicht sein.


    Was bitrate ist? Na kennste keine MP3s? Da redet man ja auch von Bitraten und da sollte eig. auch bekannt sein, das 128 kbit MP3s nicht die besten sind.
    Eig. sollte es doch logisch sein, was die Bitrate ist? Es definiert halt die durchschnittliche Datenrate/sek die dein Video haben soll. Mehr Dateigröße = Mehr Endqualität. Wieviel Bitrate für ein sauberes Bild nötig ist, hängt halt von dem Videomaterial (wie komprimierbar ist es?) dem benutzten Encoder ab, wo MainConcept nicht unbedingt die Glanzleistung von Effizienz ist, und natürlich die Einstellungen am Encoder ab.

    alles kann 4:4:4 predictive.
    Solang man kein Windows timeline programm benutzt. Deren h.264 decoder sind einfach allesamt für die tonne, wo halt der h.264 decoder auch seinen job verfehlt, wenn er die Hälfte der h.264 Features nicht lesen kann.
    Ist eig ein Armutszeugnis.


    Des weiteren klingt 2.90 gb auf 15min 4k alles andere als nach Lossless

    Nein, ASIO wird von DXTory nicht unterstützt. Vielleicht kann man mit einer virtuellen Soundkarte was dran drehen, die den Ton vom Interface mit frei bestimmbaren Parametern entgegennimmt und über DXTory abgreifbar ist, aber das ist auch nur ein nerviger Workaround für etwas, was eigentlich so laufen müsste.

    Was wieder zusätzliche Latenz bedeuten würde :D



    Ich soll doch meine Netzwerk Karte ausstecken, die macht vielleicht Probleme

    Was durchaus richtig ist.
    Insbesondere onboard WLAN kann gerne für größere Systemlatenzen sorgen.


    Siehe 2. Bild den Text:


    http://www.thesycon.de/deu/latency_check.shtml

    Steinberg

    Die Interfaces haben durchaus viel Latenz. Bei den Skype Kontakten ging da via Afterburner nur die hohen 500ms Latenz eines DirectSound. WASAPI war nicht möglich, da war nach kurzer Zeit die Mikrofonaufnahme abgebrochen (Afterburner)


    Die PreSonus 22VSL die ich hab kommt mit ~28ms daher. AmarecTV zeigt das in einem Fenster an. Das ist ein sehr guter Wert. AmarecTV benutzt via WASAPI einen Puffer von 40ms, was ich auch bei Afterburner als Wert vermuten würde.

    Also DXTory hat schon einen recht gutmütigen Audiopuffer, das ist schon bitter, wenn es selbst dort zu langsam ist o.o


    Afterburner hat einen viel kleineren Puffer, das macht die Audiolatenz in der Aufnahme geringer, aber verlangt auch geringe Latenzen der Geräte.


    DXTory kann nur WASAPI ansprechen, nutzt hierbei aber einen recht hohen, eher für WASAPI unüblich hohen Puffer, daher schon erstaunlich das du selbst da mit der Latenz Probleme kriegst.


    Systemlatenz kann auch weiter verringert werden wenn kein onboardsound benutzt wird und im BIOS deaktiviert ist. Bei Windows 7 muss HPET genutzt sein, ich glaube ab 8 wird ein anderes Timing verwendet, bin da gerad nicht sicher.
    Soviel wie möglich an Programmen und Diensten im Hintergrund beenden und alle nicht benötigten Onboardcontroller deaktivieren.