Ich vermute einfach, dass du etwas beim Installieren des HD Mods etwas vergessen oder verkehrt gemacht hast.
Somit weiß ich nun aber, dass es definitiv geht und kann ausgehend von identischen AB Einstellungen zukünftig darauf beharren, dass die jeweilige Person etwas falsch gemacht hat. 
Beiträge von Kayten
-
-
@Vrall
Bezüglich Thief Gold:
Habe gerade zufälligerweise meine Humble Bundle Keys durchstöbert und ein nicht eingelöstes Thief Gold für [lexicon]Steam[/lexicon] entdeckt.
Eingelöst, installiert, nach Anleitung mit dem HD Mod gepatcht und mich daraufhin an eine Testaufnahme gewagt.
Funktionierte problemlos in meinem kurzen Test. Mit Hook und demnach mit HUD vom [lexicon]Afterburner[/lexicon]. Mit @De-M-oNs Einstellungen keine Änderungen im RTSS nötig.Anmerkung: Performance mit [lexicon]Dxtory[/lexicon] v2.0.129 ist um ganze 20-30 [lexicon]FPS[/lexicon] besser (~48FPS vs. ~74FPS) bei identischen [lexicon]Codec[/lexicon]-Einstellungen (UtVideo).
Hier ein Video dazu, aufgezeichnet mit [lexicon]Dxtory[/lexicon]. Kenne das Original Thief zwar nicht, sieht für mich aber sehr "HD" aus. -
Bisher zwischen 102MB und 3,21GB, meistens aber ca. 1GB, auch wenn der Thread an sich völlig irrelevant ist ohne weitere Angaben. Wurde aber schon mal erwähnt.
Ich bin so deprimiert.... ich habe gerade 8 Stunden an einem 900 MB großen Video hochgeladen. Im Normalfall sind meine Videos so 200-700 MB groß, je nach Spiel... aber wenn ich lese 24 GB in einer Stunde, möchte ich weinen.
Wenn die Dateigröße so ausschlaggebend für dich ist, würde ich wirklich probieren die etwas runter zu drücken. Falls du das schon bereits probiert hast, überlies es einfach.- (Nero)[lexicon]AAC[/lexicon] statt [lexicon]FLAC[/lexicon] fürs Audio. Mit adaptiver [lexicon]Bitrate[/lexicon] von 640 kbit/s sparte das bei mir beim Testen über 40% Dateigröße (Reine Audiospur, 106MB -> 60MB) bei einer Laufzeit von 22 Minuten. Hören wird den Unterschied höchstwahrscheinlich keiner. Mit 320 statt 640kbit/s waren es noch mal 10MB weniger.
- Maximum [lexicon]GOP[/lexicon] Size in [lexicon]MeGUI[/lexicon] in der [lexicon]x264[/lexicon] Konfiguration auf 0 (Infinite) stellen, dann kannst du zwar lokal nicht mehr vernünftig vor- und zurückspulen, sollte aber bei geringerer Komplexität einiges an Dateigröße einsparen so wie ich das gelesen habe und für YT selbst ist das unwichtig.
Wer anderes weiß bestimmt noch mehr um die Dateigröße zu verringern ohne (großartig) Qualität einzubüßen.
-
@Vrall
Ich versteh die Frage nicht ganz wenn du sowieso schon auf 45FPS kommst.Würdest du beispielsweise mit 30FPS aufnehmen und das auf 45FPS hochrechnen lassen, indem du im [lexicon]SSM[/lexicon] bei ChangeFPS die gewünschte FPS Zahl einträgst, bekämst du so trotzdem den HFR Encode (mehr [lexicon]Bitrate[/lexicon]), obwohl dein original Material nur in 30FPS vorläge.
Edit: 41FPS reichen für den HFR Encode.
-
@De-M-oN
Ich hatte mal vor einiger Zeit ein 40 und ein 45FPS Video hochgeladen. Das 40FPS Video bekam kein HFR, das 45er schon.
Alles dazwischen hatte ich natürlich nicht getestet. Gerade mal nachgeholt und zum Schluss gekommen, dass 41FPS Minumum für den HFR Encode sind.
Ob die [lexicon]Bitrate[/lexicon] auch entsprechend schon bei 41FPS ansteigt habe ich aber nun nicht überprüft, gehe ich beim HFR Encode aber mal von aus.
Lag also nicht ganz richtig mit den 45FPS, aber wer lädt denn auch mit 41FPS hoch?
-
Deswegen hat De-M-oN...
Das ist schön für De-M-oN, nur heißen andere meist nicht De-M-oN und haben scheinbar nicht das Glück häufiger solche Encodes zu bekommen.
Ich hingegen warte immer noch auf den ersten HFR Encode mit mehr als 1080p bei einem öffentlichen Video. -
Kommt drauf an was du erreichen willst.
Flüssiges Video und "perfekte" Bildqualität sind allgemein gesagt nun mal zwei Gegensätze auf YouTube. Irgendeinen Kompromiss musst du eingehen.
Bei 45FPS hättest du die bestmögliche Bildqualität die mit nativem HFR Material möglich ist.
Mit 25FPS -> 50FPS hättest du nochmal höhere Bildqualität aufgrund der geringeren Anzahl an unterschiedlichen Bildern pro Sekunde kombiniert mit der höheren HFR [lexicon]Bitrate[/lexicon].Wenn du höhere Bildqualität haben willst, wäre es aber sinniger erst die [lexicon]Auflösung[/lexicon] zu erhöhen, das steigert die [lexicon]Bitrate[/lexicon] wesentlich mehr als ein HFR Encode. Desweiteren muss man bedenken, dass YouTube aktuell quasi nie höher kodiert als 1080p@60FPS.
Aus meiner Sicht wäre 1152p@45FPS (wenn YouTube es kodieren sollte) aktuell der beste Kompromiss mit Schwerpunkt auf Bildqualität bezüglich Kodierzeit, Dateigröße, Aufnahme, Uploadzeit und Framerate. Hängt aber natürlich wieder vom Spiel, der Internetleitung und der eigenen Hardware ab.
-
In Zukunft nehme ich dann eh mit den leistungsfähigeren 40FPS auf.
40FPS sind für YouTube aber recht sinnfrei.
Für HFR bräuchtest du meiner Erfahrung nach mindestens 45FPS, ansonsten bietet dir YT hinterher maximal 30FPS an.
Wenn du HFR haben willst, solltest du entweder direkt mit 45FPS aufnehmen oder es nachträglich auf 45FPS hochrechnen lassen. -
Was heißt "brauchen", Screenshot sagt halt mehr aus.
Klingt rein von der Geschwindigkeit her nach einer Alternative zur Seagate, müsste man sich mal genauer drüber informieren. -
Hatte De-M-oN dann deswegen gemeint "Klingt nach Seagate" ?
Genau. Da es aber keine Seagate ist, wäre jetzt ein Test mit CrystalDiskMark interessant um die genaue Geschwindigkeit herauszufinden.
Ist ja vielleicht eine gleich schnelle Alternative zur Seagate. -
Verkauft Intenso irgendwie Toshiba Festplatten unter den ihrem Namen ?
Aber natürlich. Die stellen keine Festplatten her, die kaufen selber welche, bauen die in ihre Gehäuse und verkaufen die dann unter ihrem Namen. Ganz gewöhnliche Praxis. -
@obiwanjunobi
Die Externe natürlich, über die wurde schließlich geredet.
Screenshot von der aus [lexicon]CrystalDiskInfo[/lexicon], damit man sehen kann um welche genau es sich handelt. -
@obiwanjunobi, @Spieluin
Wäre interessant zu wissen welche [lexicon]HDD[/lexicon] verbaut ist. Besteht die Möglichkeit einen Screenshot von der jeweiligen [lexicon]HDD[/lexicon] in [lexicon]CrystalDiskInfo[/lexicon] (nicht Mark, oberer Bereich reicht) zu machen, falls das Programm bei USB-HDDs auch funktioniert? Genaue Bezeichnung und Firmware Version würden mir auch genügen. Ansonsten auf Wunsch Seriennummer ausschwärzen oder unter Optionen -> Seriennummer ausblenden verstecken. -
Da es etwas aus dem Blickfeld gerät und ich doch sehr an einer Lösung meines Problems mit dem [lexicon]Afterburner[/lexicon] interessiert wäre, zitiere ich mich wieder mal selbst:
Es ist auch unter Windows 7 reproduzierbar. Frisch installiertes Windows 7 nur mit den nötigsten Programmen zum Aufnehmen.
Die Symptome lassen sich desweiteren auch künstlich erzeugen indem im Hintergrund ein Prozess aktiv ist, der die [lexicon]CPU[/lexicon]-Auslastung immer auf 100% treibt, wie beispielsweise Prime95 (oder ein Encode mit [lexicon]x264[/lexicon]?).
Das niemand beim Aufnehmen Prime95 laufen haben wird ist klar, aber so lässt sich immer nachvollziehen, was ich bei einer normalen Aufnahme mit dem AB für Probleme habe.
[lexicon]Dxtory[/lexicon] interessiert es übrigens kein Stück, wenn Prime95 im Hintergrund läuft, während der AB die Aufnahme völlig zerschießt.Vielleicht könnte ja jemand anderes das auch mal testen und es somit bestätigen, dann wüsste man, dass es vielleicht ein allgemeines Problem des AB wäre.
Tritt es bei anderen nicht auf, so ist es höchstwahrscheinlich irgendeine Einstellung die diese Probleme hervorrufen kann. Wäre wichtig herauszufinden welche das ist, damit dem vorgebeugt werden kann.
Gerade diejenigen, die den [lexicon]Afterburner[/lexicon] recht häufig empfehlen sollten ebenfalls an dem Grund dafür interessiert sein. Denn dank dieses Problems muss ich auf andere Software wechseln.
Mit so einem möglichen Fehler würde ich den AB daher nur ungern anderen vorschlagen, auch wenn es nur bei schwächeren CPUs auftreten sollte. -
@Vrall, @TheWaywolf
Wenn man aus Sichts eines Let's Players den [lexicon]CPU[/lexicon] Opa bedenkt, der in seiner zeitlich angebrachten Rente noch in meinem PC arbeitet, ist das nichts außergewöhnliches bei meinen Kodiereinstellungen.
Immer in 10bit auf slow mit CRF19 und mindestens 1152p. Daher muss mein Notebook manchmal auch zum Kodieren herhalten, und das ist sogar schneller. -
@Vrall
Zwei Stunden Kodierzeit für 20 Minuten sind doch recht human, ich bin da eher 4-6 Stunden gewöhnt. -
schlägt er mir für 400MB 3 Stunden vor!
Wo ist das Problem? Das es 3 Stunden dauert oder das es 400MB sind?
Ohne [lexicon]MediaInfo[/lexicon] des Rohvideos und Log von [lexicon]MeGUI[/lexicon] lässt sich da gar nichts sagen. -
Ich dachte das wäre in sofern gelöst, dass eine Desktopaufnahme ohne Hook mit dem AB zum gewünschten Ergebnis führt?
Das war zumindest das Letzte, was ich mitbekommen habe.ich greife für das Spiel auf [lexicon]FRAPS[/lexicon] zurück
Wenn das funktioniert kannst du das natürlich auch machen, fehlt halt die Möglichkeit die Audiospuren nachträglich anzupassen. -
@Sagaras
Tut mir Leid, ich hatte es extra ein paar Sekunden später wieder raus editiert, ist mir dann auch bewusst geworden. -
weil ich meine 720p Videos entweder auf 1080p mit 60fps, oder auf 1170p mit 30fps [lexicon]hochskalieren[/lexicon] möchte.
Mal ein Ratschlag abseits des Kodierens:
Bleib bei der FPS Zahl mit der du auch aufgenommen hast. Falls du also vor hast, dein 30FPS [lexicon]Rohmaterial[/lexicon] auf 60FPS hochrechnen zu lassen um eine höhere [lexicon]Bitrate[/lexicon] zu bekommen, würde ich mich als Zuschauer schon beschweren, wenn die jeweilige Person "60FPS" anbietet, die in Wirklichkeit nur 30FPS sind, auch wenn der Gedanke dahinter die Verbesserung der Qualität ist. Ist aber nur meine Meinung.
Manche Zuschauer könnten sich hintergangen fühlen.@TheWaywolf
Was meinst du mit gemischte Audiospur?
Der [lexicon]SSM[/lexicon] kann Audiospuren aus deinem Material extrahieren, egal ob das jetzt eine, zwei oder drei oder x Spuren sind.
Falls du mit "gemischte Audiospur" meinst, dass Spiel und Stimme bereits in einer Spur zusammenhängen, die der [lexicon]SSM[/lexicon] dann extrahieren soll, so ist auch das möglich, ist schließlich auch nur eine Spur.