Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
Und der Unterschied zwischen Predict Median und Predict Left macht definitiv keinen Größenanstieg um 100% aus, eher im einstelligen Prozentbereich. Unterschiedliches Material dürfte da eher für den Größenunterschied sorgen.
@Julien
Darauf habe ich bisher nie wirklich geachtet, da ich den Re-Encode in 99% der Fälle sowieso immer per Hand anstoßen muss.
Codierung ging momentan erstaunlich schnell (gestern abend 6 videos hochgeladen und hatten am selben Abend noch VP9)
Am meisten beeinflusst die Dateigröße die Codierzeit von Youtube. Klingt komisch, ist aber so ;D
Predict Median und Predict Left wägen nur zwischen Dateigröße und CPU Last ab.
Median: Größere Kompression = Kleinere Datei, größere CPU Last
Left: Kleinere Kompression = Größere Datei, kleinere CPU Last
Da die Effizienz aber auch situationsbedingt ist (an vielen Stellen kann Left sogar effizienter sein) ist es toller, wenn man alle kombiniert benutzen kann, immer den richtigen zur passenden Situation. Und genau da setzt MagicYUV an mit seiner Dynamic ;D
Jedoch kommt nichts an die Effizienz auch nur ansatzweise von Lagarith ran. Nur das merkt man dann deutlicher auf die Spiel-FPS wenn die CPU Lagarith in 2k aufwärts framegrößen codieren soll in wohlmöglich noch HFR.
Hallo,
so sieht ein Beispiel mit nativer Auflösung von 1920x1200@50 FPS aus.
Aufgenommen mit dem UTVideo422.
SSM:
- nativer Auflösung@50 FPS mit Spline 36
- YV16 mit Chroma (UV) angehakt
MeGUI:
Für 50 FPS sieht es meiner Meinung nach sehr "hakelig" aus, wie seht ihr das?
Für 50 FPS sieht es meiner Meinung nach sehr "hakelig" aus, wie seht ihr das?
Ja, finde ich auch - allerdings nicht diese Art von hakelig wie bei zu wenig FPS, sondern eher wie bei "Das Aufnahmeprogramm weiß nicht, welche von den zuvielen Frames es schreiben soll". Das hatte ich auch ganz lange und konnte es nur in den Griff bekommen, indem ich die Spiel-FPS auf exakt die Aufnahme-FPS begrenzt habe.
Ok, danke @Julien!
Ich hab auch das Gefühl, als wenn was mit den Frames nicht passen würde.
Mein anderes Video sieht um einiges flüssiger aus und dort hatte ich die Spiel FPS = Hooking FPS.
Das spart mir CPU und ich hab eh immer 60 FPS.
Dann werde ich es wohl so beibehalten.
Danke für die Bestätigung!
Ist das Spiel zufällig Unreal Engine 3?
Da musste in jedem Fall den engineinternen Framelimiter drin lassen und nutzen. Sonst haste nicht nur eventuelle ungünstig gecapturete frames, sondern auch gerne mal sehr hakelige Steuerung.
Ich weiß gar nicht auf welcher Engine es basiert, aber im Spiel selber kann ich nur VSync nutzen und das möchte ich nicht.
Der Limiter von RTSS hilft mir in dem Fall 
Ist das Spiel zufällig Unreal Engine 3?
Die Erfahrung durfte ich letztens machen. Ein UE3-Spiel, dass auch mit 100FPS noch am ruckeln war. Entweder VSync-Pflicht oder manuelle Begrenzung der FPS auf die Aufnahme-FPS über beispielsweise Dxtorys Synchronize Video FPS. Letztlich hat sich OBS Studio hier als bestes Aufnahmeprogramm rausgestellt, da es die geringsten FPS-Einbußen mit sich bringt. VSync über den Nvidia Treiber läuft interessanterweise besser als das Ingame-VSync samt FPS-Smoothing.
Direct3D9, insbesondere Unreal Engine 3 lassen sich halt ziemlich schäbig hooken.
Es war eine regelrechte Erlösung als die Capture Karte kam und ich rise of the triad 2013 nicht mehr hooken musste.
Das gab mir doppelte FPS Rate.
So, ich habe nochmal einen Test fertig gemacht, alles ist gleich geblieben, nur der Codec ist der UTVideo 422, die Frames sind auf 60 limitiert und es wird mit 60 fps gehooked.
Was mich nun wundert: wo kommen diese Mikroruckler her? Die sind leider schon in der Aufnahme, DXTory hat mir eine Geschwindigkeit von 170MB/sec quittiert.
Hat vielleicht jemand Erfahrung mit dem Spiel und dem Hooking?
Danke!
Nimmst du nun mit Dxtory oder MSI AB auf?
Sollte es Dxtory sein, würde ich Synchronize Video FPS, ausprobieren, so läuft das Spiel immer mit Aufnahme-FPS, wodurch es flüssiger wirken könnte.
Du kannst doch ganz einfach ausrechnen, ob deine Festplatte den Durchschnitt an Datenrate halten kann.
Videogröße in MB geteilt durch Länge in Sekunden = durchschnittliche Datenrate pro Sekunde.
Ach sorry, ich dachte, es wäre noch aus dem vorherigen Post ersichtlich...
Ich nehme mit dem MSI Afterburner auf.
Man könnte ansonsten auch OBS Studio probieren, das war für mich bei DirectX 9 ein Segen.
Den teste ich vielleicht morgen, da muss ich nur ein Tutorial finden für optimale Einstellungen
Du kannst doch ganz einfach ausrechnen, ob deine Festplatte den Durchschnitt an Datenrate halten kann.
Videogröße in MB geteilt durch Länge in Sekunden = durchschnittliche Datenrate pro Sekunde.
Das ist korrekt, habe ich auch schon getan.
In dem Fall, den ich oben gepostet habe (mit den Mikrorucklern), ist die durchschnittliche Datenrate bei 73MB/s.
Also nicht der Grund für diese Ruckler.
Können diese Ruckler entstehen, wenn die CPU mit dem encoden nicht hinterherkommt?
Sollte noch jemand einen Tipp haben, wäre ich sehr dankbar
//EDIT:
So, ich habe mich nochmal mit DXTory auseinandergesetzt und bin mit dem Ergebnis richtig zufrieden, er läuft definitiv besser als der MSI AB in diesem Fall.
Danke für die Tipps!
Weiß nicht, wie sich das auf Afterburner oder DxTory bezieht, aber zum. bei OBS habe ich z.B. den Fall, dass utvideo weder die Festplatte noch die CPU auslastet und dennoch ruckelt (Kodierung überladen) - kann das bei Denen der Fall sein? 
EDIT:
Zumindest tat es das immer auf meinem Laptop, bei einem Test eben lief es 
@CoRori
Nein, außer du hast zu wenig Threads festgelegt, was man bei der FFmpeg Variante (OBS Studio) von UtVideo nicht selbst bestimmen kann.
Dxtory würde sich in der neuesten Version außerdem via Bottleneck Warning beschweren, wenn die Kodierung nicht hinterher kommt.
Wegen der Bottleneck Funktion bin ich eigentlich zu DXTory und hatte bis dato nur die Trial Version.
Allerdings habe ich mit dem DXTory einfach nicht diese Mikroruckler, also muss er irgend etwas besser machen, weshalb ich nun diesen nutze.
//EDIT:
So schaut es nun aus.
Da das Spiel selber kein Motion Blur bietet, habe ich leichtes hinzugefügt (30).
Ohne vp9 find ich das Ergebnis schon ganz ordentlich.
Aufgenommen in nativer Auflösung (1920x1200) mit 60 FPS, Ingame FPS limitiert auf 70FPS.
Codec war der UTVideo 422.
SSM:
- native Auflösung behalten @ 60 fps
- Spline 36, ohne ResampleHQ
- Farbraum YUY2 (für Motion Blur)
MeGUI:
Habt ihr Verbesserungsvorschläge?
Wofür der motion blur?
Für persönlichen Geschmack oder willstes noch weicher kriegen, erhoffst dir bessere komprimierbarkeit oder wofür?
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!