Encoding-Talk

Das mit der Performance habe ich auch schon gehört, aber bisher kann ich mich über die Performance von DxTory nicht beklagen. Asynchronität bei den Aufnahmen habe ich seit der internen Soundkarte auch nicht mehr, und vorher waren die bei DxTory und Afterburner gleich asynchron. Tempo-Verändern um 0,04% hat da dann geholfen. Was mich am Afterburner eher gestört hat, wenn man dann mal aus dem Spiel rausgeklickt hat oder irgendwas abgestürzt ist, dass dann die Aufnahme wie oben schon gesagt wurde, erstmal hinüber war und glaube ich nur verhältnismäßig kompliziert wieder zu retten war. Bei DxTory sind die Rohdateien dann direkt bearbeitbar gewesen.

Zitat von Peacemaker666

Bei DxTory sind die Rohdateien dann direkt bearbeitbar gewesen.

Jup, Dxtory scheint da wesentlich gutmütiger zu sein als andere Programme. Mir ist gestern auch Need For Speed abgeschmiert und zum allerersten Mal musste ich eine Rohaufnahme mit VirtualDub und Direct Stream Copy retten (dauert nur ein paar Minuten), davor ist mir The Division schon tausendfach abgeschmiert und noch nie hat die Dxtory-Aufnahme auch nur ein klitzekleines Problem bereitet. Meistens nimmt sie sogar noch ein Stück weiter auf, wenn das Spiel schon weg ist, was den Übergang zum nächsten Clip sehr viel angenehmer macht.

Zitat von Peacemaker666

Was mich am Afterburner eher gestört hat, wenn man dann mal aus dem Spiel rausgeklickt hat oder irgendwas abgestürzt ist, dass dann die Aufnahme wie oben schon gesagt wurde, erstmal hinüber war und glaube ich nur verhältnismäßig kompliziert wieder zu retten war.

Genau... Spiel starten, zwei mal die Aufnahmetaste drücken und fertig...

Richtig. Wenn man eine weitere Aufnahme startet, ohne den afterburner zu beenden (!), dann schließt der die Datei korrekt ab und alles ist gerettet.

Zitat von strohi

Richtig. Wenn man eine weitere Aufnahme startet, ohne den afterburner zu beenden (!), dann schließt der die Datei korrekt ab und alles ist gerettet.

Gut zu wissen. Das ist mir tatsächlich neu. Aber wie gesagt, ich benutze den auch so gut wie gar nicht.

Zitat von Peacemaker666

Das mit der Performance habe ich auch schon gehört, aber bisher kann ich mich über die Performance von DxTory nicht beklagen.

Wo ich mit Probleme hatte, war:

a) OpenGL (ganz problematisch mit DXTory)
b) High Framerate. Also wirklich. Da hatt ich mit Afterburner locker flockig die doppelte Leistung. DXTory hatte meine FileFPS nichtmal erreicht, während Afterburner über 100 spiel fps blieb.

Und ja: Dank seperatem Encodeserver geht es wie von GelberDrache beschrieben nachträglich zu schließen

Musste mich nur wegen Dead Space mit dem Afterburner beschäftigen (Leistung unter Fraps war ... bescheiden) und bin echt relativ überrascht, wie performant das ganze läuft, wenn man mal alles richtig eingestellt hat...
Auch wenn ich die Qualität sicher noch etwas tweaken könnte.

Ach und noch Punkt c)

DXTory neigt recht schnell dazu neue Dateien zu beginnen.

Bei Dosbox hat der bereits von einem Wechsel von DOS in ein Spiel schon eine neue Datei angelegt, ja gar schon wenn bloß spiel eine cutscene abspielt - obwohl die Auflösung sich überhaupt nicht ändert.

Afterburner schreibt hier durchgängig in eine Datei.

Das mit dem beginnen neuer Datei war halt oft problematisch mit NFS 1 zb. Weil der tut dann so hastig die Aufnahme beenden und wieder starten, das er teilweise zu lange brauch zum beenden und dann der Start nicht erfolgt und muss dann manuell die Aufnahme starten, wodurch dann wertvolle Sekunden der Cutscene flöten gehen.

Ich benutzte nur noch OBS.

Zitat von De-M-oN

DXTory neigt recht schnell dazu neue Dateien zu beginnen.

Bei Dosbox hat der bereits von einem Wechsel von DOS in ein Spiel schon eine neue Datei angelegt, ja gar schon wenn bloß spiel eine cutscene abspielt - obwohl die Auflösung sich überhaupt nicht ändert.

Hatte ich jetzt tatsächlich auch nur mal bei Dosbox und da auch nur, wenn Dosbox zum Spiel gewechselt ist. Das ist dann allenfalls beim ersten Part ausschlaggebend, wenn man die Introsequenz vollständig draufhaben will. Dass im Spiel mal die Auflösung wegen einer Cutscene geändert wird, hatte ich bei meinen Dos-Spielen bisher noch nie.

Könnte mal jemand @Defender833 darauf hinweisen, dass Youtube die Videos nicht danach enkodiert, welche Bitrate sie haben, sondern mit welcher AUflösung und mit welchen FPS sie hochgeladen wurden. Und dass man bei komplexem Videomaterial sehr wohl einen Unterschied zwischen "in 1080p hochgeladen" und "in 1152p hochgeladen" sieht.

Ich habe keine Lust diese Diskussion unter einem meiner Videos zu führen.

hier der Link zu besagtem Video weil ich keine Lust habe die gesamte Argumentation hierhin zu kopieren.

Natürlich spielt die Qualität des Eingangsmaterials, ebenso wie die Auflösung und Framerate, eine entscheidende Rolle dabei, was nach YouTubes Verarbeitung hinten raus kommt.
Die Mischung machts.

Vom Eingangsmaterial hängt doch meines Wissens nach auch ab welcher Encoder benutzt wird, oder?
Also mit 2048*1152 und 50 oder 60FPS bekomme ich immer VP9 und da muss man schon zugeben, dass es besser aussieht als der "Normale Encode"

Ich denke die 1152p laufen dann auf der 1080p-Stufe, weil es keine Extra-Stufe seitens des Players gibt. Also zumindest die "Statistik"-Schaltfläche zeigt dann eine Wiedergabe mit den 2048*1152p des Ursprungsmaterials bei im Play ausgewählten 1080p

Sinnlos ist allerdings wirklich sowas in den Titel zu schreiben, weil nach "1152p" kein Mensch sucht und die technischen Spielereien dieser Art dem allgemeinen Zuschauer erstens völlig latte, zweitens völlig unbekannt sind

Liste der vbv-max
bis 30 Fps 41 - 60 Fps
720p 2.000 kbit/s (H.264) 3.000 kbit/s (H.264)
1080p 4.000 kbit/s (H.264) 5.000 kbit/s (H.264)
1440p 10.000 kbit/s (H.264) 15.000 kbit/s (VP9)
2160p 22.000 kbit/s (H.264) ~ 34.000 kbit/s (VP9)

Wie man jetzt sehen kann haben wir von der Fps her 2 Encoding Stufen. Einmal bis 30 Fps und einmal das High Framerate (HFR), dieses geht von 41-60 Fps. Zusätzlich kann man sehen das gerade die 1440p und 2160p sehr hohe maximal durchschnittliche Bitraten. Dadurch erzielen wir gerade bei diesen Stufen sehr gute Videoqualität. Einen großen und sehr entscheidenden Punkt gibt es bei den 1440p/2160@HFR Stufen zu beachten. Diese sind nämlich nur in VP9 vorhanden. Der Codec VP9 komprimiert die Videos deutlich stärker, braucht dafür aber auch 10-20x so lange. Dadurch haben wir bei der 1440p Stufe die 15.000 kbit/s hat, wenn man es mit H.264 vergleich, etwa eine Bitrate von 20.000 kbit/s, was die 2160p Stufe bedeutet, aber das nur mit etwa 44,5% der Pixel, was zu einer extrem Steigerung der Qualität führt.
Zusätzlich wird das Encoding der 1440p und 2160p Stufen nicht erst durch die Auflösung von 2560x1440 bzw 3840x2160, sondern Bereits durch eine Auflösung von 2048x1152 und 3200x1800 ausgelöst. Wodurch wir im Fall der 1440p Stufe noch mal etwas über ⅓ an Pixel sparen.

@Defender833 Bei deiner Signatur fehlt ein Komma.

Zitat von Sev

Vom Eingangsmaterial hängt doch meines Wissens nach auch ab welcher Encoder benutzt wird, oder?
Also mit 2048*1152 und 50 oder 60FPS bekomme ich immer VP9 und da muss man schon zugeben, dass es besser aussieht als der "Normale Encode"

Ich denke die 1152p laufen dann auf der 1080p-Stufe, weil es keine Extra-Stufe seitens des Players gibt. Also zumindest die "Statistik"-Schaltfläche zeigt dann eine Wiedergabe mit den 2048*1152p des Ursprungsmaterials bei im Play ausgewählten 1080p

Sinnlos ist allerdings wirklich sowas in den Titel zu schreiben, weil nach 1152p kein Mensch sucht^^

Ist tatsächlich richtig, solang du das lokal betrachtest, nicht umsonst schreiben die extra dabei das man sich extra an die angegebenen Formate halten soll, da der frühere Flashplayer gar nicht damit klarkam, mittlerweile geht es besser mit dem HTML5 äquivalent.

Zitat von CoRori

@Defender833

Wenn Du die Statistiken des Players abrufst wirst Du sehen, dass YouTube 1152p bei entsprechenden Videos wiedergibt, obwohl man nur 1080p auswählen kann

nicht richtig, es wird das format der hochgeladenen Datei angezeigt, das ja weiterhin 1152p beträgt, die umrechnung im player erfolgt jedoch tatsächlich als downscaling auf 1080p, wir haben uns einen vereinfachten player im code mal genauer in der uni angeschaut und da wird wirklich pixelinformation abgerufen bzw umgerechnet beim scalieren. sprich wenn der player so eingestellt ist das 1920x1080 Pixel rauskommen sollen, dann helfen da auch keine virtuellen Pixel oder ähnliches, die informationen werden entsprechend einfach nicht genutzt, die nächste freigegebene playerstufe wäre ja 1440p sprich um ein wesentlich besseres Bild zu bekommen müsstest du das entsprechend in 1440p abspielen, damit deine GrafikKarte das dann wieder in 1080p umrechnet (davon ausgegangen das du keinen 4K monitor besitzt) das ganze hin und herrechnen wirkt sich statistisch gesehen auf die gesamtfehlermenge aus, die halt nicht mal eben durch eine parität wieder "korrigiert" werden können. Simple Rechnung: 1920x1080 = 2073600 Pixel sagen wir jeder Rechner macht 1 promill Fehler sprich in einem bild hast du 2073 Fehler so jetzt macht das aber nicht nur dein Rechner sondern auch der YouTube Rechner und der Endgerät Rechner dann bist du schon bei ~3 promill Fehlern und jedes mal umrechnen bringt einen weiteren Rechenschritt hinzu sprich ein weiteres Promill, sodass du mit der Methode wie du es zZ hochlädst @Spieluin eine wesentlich höhere Fehlerdichte aufweist, wie zB bei einer CBR (was schon mal ein Rechenschritt ist der unnötig ist) aber wenn du das jetzt auf Maschinencodeebene betrachtest wird das immer absurder und absurder ich mein bei nem 23min Video (1380sek = 41400 frames [bei 30FPS] ) hast du 85.847.040.000 Pixel und somit mindestens ~850mio Fehler in dem Video hast. wohingegen die andere Methode "nur" ~400mio Fehler hat allein schon durch die zusätzlichen Rechenschritte. Die Zahlen sind grob gerundet aber man sieht doch schon nen deutlichen Verlust der eigentlich durch das verschlimmbessern kommt. Natürlich habt ihr recht wenn ihr mit einer VBR einen Kompromiss zwischen Kompression und Leistung finden wollt, die CBR ist rein rechnerisch allerdings der VBR mit nur ~ 50% so vielen Fehlern im deutlichen Vorteil. Und das mit dem Player hatte ich ja auch schon erklärt! Hoffe ihr versteht die Argumentation.

Kam grade noch als gesonderter Kommentar zu dem Thema:

"Also zunächst mal: Bitrate =/= Auflösung. Du kannst 1080p in geringer bitrate haben (heißt mehr Artefakte) und in hoher (heißt mehr Daten). Wenn deine Bandbreite kein Problem ist, nimm eine hohe bitrate (vorausgesetzt deine Hardware macht das mit). Youtube rendert die Daten dann in die einzelnen Auflösungen um.
Apropro Auflösungen: 1152p ist eine s**Auflösung. Warum? Weil quasi kein Monitor diese verwendet. Das heißt egal wie man es anstellt, man muss aus diesen 1152 pixeln pro Spalte 1080 machen. Machen die Youtubeserver wenn du das Video hochlädst und deine Grafikkarte, wenn du dir das Rohmaterial ansiehst.
Was dann passiert? Die 72 pixel zu viel werden mit ihren Nachbarpixeln zusammen gerechnet und der Durchschnitt davon dargestellt. Das Ergebnis ist dann ein verwaschenes Bild.
Und um die sicher kommende Diskussion von wegen Nvidia Hyperscaling gleich abzuwürgen: Da werden Auflösungen genommen, die entweder das Doppelte oder das Anderthalbfache der Zielauflösung sind und sich somit sauber ins Zielformat umrechnen lassen."

Ich bitte dich doch immer noch ein 1080p hochgeladenes The Witcher 3 Video neben meinem 1152p Video laufen zu lassen und dann mal die Artefaktbildung zu vergleichen, wenn man mit Geralt schnell durch die Welt reitet. Du wirst sehen, dass sich bei meinem Video sehr viel weniger Artefakte bilden werden als bei dem in 1080p hochgeladenen Video.

Und bei meinen Videos von schlechter Qualität zu reden, grenzt schon an Dreistigkeit.