Beiträge von Sagaras

Beim AB ist es eigentlich so das er wie folgt in jeweilige Formationen aufnimmt:

• Delay am Anfang fehlt
  Wenn das Eintritt, dann ist die Audiospur kürzer und Audio zu Video obendrein noch Asynchron.
  

  
  

  Dies passiert beim AB nicht im Normalfall und wird oftmals durch mehrmalige hintereinanderfolgende Aufnahmen ausgelöst. z.B. durch das mehrmalige drücken der Aufnahmetaste.
  

• Delay am Ende fehlt (Standard)
  Wenn das Eintritt, dann ist die Audiospur exakt Synchron zur Videospur. Es fehlt ledeglich ein paar ms am Ende der Audiospur. Sprich Audiospur ist kürzer als Video.
• HPET (High Precision Event timer) nicht aktiv
  Wenn dies Eintritt, dann wird die Audiospur aufgrund des deaktivierten HPET nicht nur kürzer, sondern auch Asynchron.
  Dies sollte unbedingt in BIOS / Windows aktiviert werden.
  

  
  

  Testen kann man das mit den WinTimerTester

  
  

  Die QueryPerformanceFrequenz sollte bei 14.3+ MHz sein. Ist sie deutlich darunter ist HPET nicht aktiv.

  
  

  Ein Takt Timer ist sehr wichtig bei Aufnahmen

  
  

  Unter Windows lässt sich das mittels CMD (Commandline) wie folgt aktivieren:
  bcdedit /set useplatformclock true

  
  

  Windows neustarten und dann sollten Aufnahmen besser laufen was Audio angeht. Vorausgesetzt es [lexicon]lag[/lexicon] am HPET.

  
  

  Wichtig ist das es sowohl im BIOS als auch unter Windows aktiviert ist.
  

@Strohi
- [AB] Verwenden des dedizierten [lexicon]Encoder[/lexicon]-Server anhaken
- [RT] On Screen Display coordinate space auf Framebuffer stellen

Den gesamten Rechner dauerhaft als Admin betreiben (Win7):

• Starte die CMD.EXE als Administrator
• Aktiviere mit folgender Eingabe deinen Benutzeraccount für dein Rechner als Administrator:
  net user administrator activate:yes
  

  
  

  -PC Neustart-
  

• Deaktivieren kannst du das Ganze wieder mit:
  net user administrator activate:no
  

  
  

  -PC Neustart-
  

Das musste ich bei meinen Kumpel auch machen, da dieses komische Win7 ihn nicht als Admin erkannt hat. Er hat quasi alles als neutraler Nutzer nur nutzen können.
Als Test sollte dienen: Über die CMD.EXE im Verzeichnis C:\ eine Datei zu erstellen mittels:
echo Dies ist ein Test > test.txt

In der Regel hat der Admin dafür nur das Recht, einen normalen User würde der Zugriff verweigert.

Und wenn MSI dann immer noch nicht will... mal probieren zu deinstallieren und neu zu installieren.

Entsprechend mit [lexicon]Gothic[/lexicon] dann auch mal so verfahren.

Wenn es dann noch nicht geht, überprüfen was [lexicon]Gothic[/lexicon] für einen Output hat in Form von Ausgabe Renderer und Sound-Output.

Fall1.
Ein Spiel was in Vollbild gespielt wird nutzt eine Anwendungsauflösung die aber auch Zeitgleich Dektopauflösung entspricht. In diesem Falle ist Anwendungsauflösung = Desktopauflösung.

Leider habe ich kein Win8.1 wo ichs hätte selbst testen können und werde es auch beim besten Willen nicht kaufen dieses [lexicon]OS[/lexicon]. Weil dieses [lexicon]OS[/lexicon] noch immer mehr Kinderkrankheiten hat, als es Nutzen bringt.

Zitat von Kayten

Habe noch etwas ausprobiert damit die Desktopaufnahme beim AB weitergeführt wird, wenn sich die [lexicon]Auflösung[/lexicon] ändert.
Von Erfolg war es jedoch nicht gekrönt. Und es ist dafür auch egal, ob ich Triple Buffering nutze oder nicht.
Da sonst keine weiteren Vorschläge kamen, geh ich mal davon aus, dass das Problem nicht auf einfache Art und Weise lösbar ist?

Voraussetungen sind immer folgende Sachverhalte:

Desktopauflösung ändert sich:
Im Falle einer Desktopaufnahme muss im [lexicon]Afterburner[/lexicon] die Bildgröße auf Vollbild gestellt sein und im Riva Tuner die Level Detection auf none stehen.

In diesem Falle trennt der AB die Aufnahme erst wenn sich die Desktopauflösung ändert.

Anwendungsauflösung ändert sich:
Im Falle einer Anwendungsaufnahme muss im AB ebenfalls die Bildgröße auf Vollbild gestellt werden und im Riva Tuner muss Level Detection aktiviert sein.

In diesem Falle trennt der AB die Aufnahme nur dann, wenn sich die Anwendungsauflösung ändert. Und auch nur dann wenn das danachfolgende auch aufnehmbar ist.

Sprich Sachen wie:
Menü mit Direct3D -> Bildwechsel mit DirectDraw (Meist sehr kurzer schwarzer Bildschirm) -> Spiel mit Direct3D (Aufnahme endet nach dem Menü)

Menü in OpenGL -> Bildwechsel in Direct3D -> Spiel in Direct3D (Aufnahme würde geteilt werden, sofern Menü und Spiel andere Auflösungen haben)

Der AB hört in der Regel nur dann auf aufzunehmen, wenn irgendwas nicht gehookt werden kann.

Bei Desktopaufnahmen sollte alles funktionieren wie es sollte.

Das macht auch [lexicon]Fraps[/lexicon] so und auch [lexicon]DXTory[/lexicon].

Daher weist alles was dem nicht so entspricht auf eine nicht korrekte Arbeitsweise der Aufnahmeanwendung hin. Eventuell nicht 100% Kompatibel mit dem [lexicon]OS[/lexicon] oder es wird in einen nicht geeigneten Modus ausgeführt (Benutzer, statt Administrator) oder es fehlen neuste Dot Net Treiber. Oder aber auch das ein [lexicon]Virenscanner[/lexicon] den Fortlaufenden Process stört beim erstellen einer neuen Datei.

Gibt viele Gründe. Einige sind Plausibel, andere vllt Merkwürdig. Eventuell hilft auch ein frisches aufsetzen des [lexicon]OS[/lexicon], wenn dies noch nicht probiert wurde.

Zitat von Decane

1. Ist es irgendwie möglich, dass die h264 Datei automatisch den gleichen Namen bekommt wie die AVI Datei z.b. wenn ich beim Export in dem [lexicon]Magix[/lexicon] Fenster die AVI Datei benenne, dass ich dann hinterher weiß was zu wem gehört wenn ich mal mehrere Videos im Stapelverarbeitungsmodus rendere?

Nein, die AVI Datei benennst du in deiner [lexicon]NLE[/lexicon], die H264 Videodatei bennst du im [lexicon]x264[/lexicon] Konfigurationsfenster unter File.
Damit soll Sichergegangen werden das AVI und das H264 File nicht über VFW zusammengebunden werden. Somit liegt am Ende ledeglich die Audiodatei in der AVI, wärend das H264 File bereits fertig im richtigen [lexicon]Container[/lexicon] wie [lexicon]MKV[/lexicon] oder [lexicon]MP4[/lexicon] liegt.

Wer eine H264 Datei in eine AVI Datei reinstopfen will, kann das gerne machen. Über nachfolgende Probleme oder Defekte innerhalb des Videos durch einen Hack zwischen AVI und H264 übernehme ich und gewiss auch kein anderer die Haftung.

Zitat von Decane

2. Immer wenn [lexicon]Magix[/lexicon] fertig exportiert hat startet die AVI Datei im Windows Media Player - wie krieg ich das aus ^^?

Dafür gibt es in [lexicon]Magix[/lexicon] gewiss eine Option das das automatische Abspielen des fertigen Videos verhindern kann.

Bestimmt eine Option wie: "Fertiges Video nach dem [lexicon]rendern[/lexicon] abspielen." oder so ähnlich.

Zitat von GrandFiredust

--fps 30.000

Das Ding ist völlig Pumpe wie du es schreibst. Kannst auch nur 30 hinschreiben. Das ist nur von mir so ein Tick das ich das immer sehr genau angebe mit den 3 zusätzlichen Nullen. Bei NTSC von 24 FPS geb ich ja auch 23.976 an.

Ob da nun also 2 Nullen stehen oder 1 Null nach dem Komma ist völlig Belanglos. Kannst halt auch das Komma weg lassen.

Wichtig war nur dieses hier:

Zitat von GrandFiredust

--partitions all

Commandozeilen Parameterangaben immer exakt so schreiben wie sie in der Hilfe auch stehen. Erfordert bei einigen Usern halt Lese und Schreibkenntnisse in Form von Abschreiben XD

Zitat von Vrall

Darum würde ich gern ein möglichst scharfes Bild liefern, aber gleichzeitig keine 5 Stunden für ein Video brauchen.

Zitat von Vrall

Wie aussagekräftig sind eigentlich projected filesize + time remaining? Das hüpft bei mir immer wieder herum, sodass ich nicht weiß was am Ende für eine Größe rauskommt.

Das wiederspricht sich mit dem ersten Satz im ersten Zitat. Du willst ein Scharfes Bild, willst aber die [lexicon]Bitrate[/lexicon] manuell bestimmen um auf Dateigröße XY zu kommen. Die [lexicon]Bitrate[/lexicon] ist das Qualitätsangabe kann man sagen. Zu wenig und das Video wird zu Matsch oder bekommt massig Blöcke.

Du sagst du hast im Spiel kleine Schriften.

Optimal wäre es dann gewesen mit RGB oder YV24 aufzunehmen, da dort in der Aufnahme die Farben nicht verlaufen. Danach hätte man auch die Skalierung optimal für sowas nutzen können. Weil dann haste in Nachskalierungen in größeren Auflösungen bessere schärfere Schriftzüge und mit einem [lexicon]CRF[/lexicon] zwischen 18 bis 25 später für YT wenn du das Video hochladen tust keine verschmierte Schriften.

Encoding würde nicht lange dauern + Dateigröße könnte besser komprimiert werden, da es von einer RGB Quelle kommt.

Bei YV12 Aufnahmen ist z.B. die Farbqualität um 50% geringer. Daher zerlaufen Pixelbreite Schriften gerne bei solchen Videos. Schlecht ist wenn sie schon so aufgenommen wurden.

Bei YV12 hast du schon eine unreine Quelle und somit auch schon Defizite drin, die wie ein Rauschen wirken.

Zitat von Vrall

Na gut. Aber eine Begrüdung wäre schon nett, da ich aus einem simplen Nein nichts lernen kann.

Danke für die Antwort jedenfalls.

Doppelte Framerate ist nicht gleich doppelte Dateigröße. Das ist Quatsch. Das stimmt nur bei Unkomprimierten Videos.
Aber alle Codecs die ihr nutzt, sei es zum Aufnehmen oder zum späteren [lexicon]Encodieren[/lexicon] wie mit [lexicon]x264[/lexicon] z.B. sind alle Kompressionsverfahren.

Bedeutet im Klartext mit dem Beipspiel 30 FPS vs 60 FPS:
Bei 30 FPS ist jeder [lexicon]Frame[/lexicon] genau 1/30 sek lang.
Bei 60 FPS genau 1/60 sek.

Komprimiert werden kann alles was z.B. identisch ist. Auch wenn sich Farbpixel zum nächsten [lexicon]Frame[/lexicon] gleichen, kann gespart werden.

Bedeutet das du bei einem Video gewiss Frames hast die über längere Zeiten von 1/60 oder 1/30 hinaus gehen. Und diese Bilder sind dann identisch. Da wo nix passiert großartig.

Daher wird bei der doppelten Menge an Frames bei Spiele die sowieso nur 120 FPS schaffen ungefähr 20% die Aufnahmedatei größer werden.

Man kann es nicht genau abschätzen. Es ist jedenfalls die Hälfte von der Hälfte was es anwachsen tut oft.

Bei Unkomprimierten Codecs würde sich das exakt um 50% steigern, aber gewiss nicht bei komprimierten Codecs.

Zitat von Vrall

Tweak? Keine Ahnung. Dann nehm ichs raus.

Tweak ist nur da, wenn du z.B. das Bild sättigen willst oder Helligkeit anpassen etc. Sprich mit den Farben etwas rumspielen willst. Wenn du es Original wie möglich haben willst, sollte es raus.

Zitat von Vrall

Wird dadurch die Datei nicht größer wenn ich auf einmal in 2048 resize?

Er meinte eigentlich das du deine Videos statt 1920x1080 lieber in 2048x1152 [lexicon]hochskalieren[/lexicon] sollst. Sprich 1080p zu 1152p im Verhältnis 16:9.
Das ist ein Sprung von 72p aufwärts.

Damit erreichst du das Youtube später dir mehr [lexicon]Bitrate[/lexicon] für das Video gibt und es damit dann auf Youtube qualitativ besser aussieht.
Die Dateigröße steigt bei so einen geringen Auflösungsanstieg nur gering an. Diese 72p mehr ist doch ein Witz. Die kannste ruhig nutzen um mehr Quali auf YT zu bekommen.

Zitat von Vrall

Und wie gesagt ist mir der Encodespeed unwichtiger als die Dateigröße.

Wenn du auf bestimmte Dateigrößen aus bist, dann darfste bei Qualität nicht viel erwarten.
Der [lexicon]CRF[/lexicon] Encode ist ein 1pass Encode der auf gleichbleibende Qualität der Frames basiert und mittels eines Faktors bestimmt werden kann.

Da aber jeder [lexicon]Frame[/lexicon] in einem Video unterschielich Komplex aufgebaut ist, ist kein [lexicon]Frame[/lexicon] immer gleich groß, sondern variiert. Somit lässt sich bei [lexicon]CRF[/lexicon] keine Fixe Dateigröße nennen bei Faktor x. Sprich, keiner wird es Vorhersagen können. Höstens vermuten oder gut Schätzen.

Bei einem 2pass Encode wo man via Bitraten encodiert kann man die Bitratenangaben nutzen um auf eine bestimmte Dateigröße zu kommen. Dies kann man dann auch ausrechnen für das jeweilige Video.

Ein 10Bit Encode spart auch wieder Dateigröße und kann zudem auch [lexicon]Banding[/lexicon] vermeiden im Video.

Wenn dich mehr solch theoretischer Kram interessiert, brauchste nur fragen. Werden dir gewiss einige was zu sagen können, da sie sich auch mit dieser Materie beschäftigen und nicht nur spielen ;D

Jup. Bei Aufnahmeprogrammen halt nie eine bestimmte Skalierung nutzen. Das ist das übelste was es gibt und das sieht man dann entsprechend auch.

Zudem sollte man mit der Aufnahme die man dann später hat, nur [lexicon]Hochskalieren[/lexicon] und niemals runter. Weil dadurch entfallen dann auch Pixel die das Bild deformieren können. z.B. das ein I Punkt dann mal fehlt oder sowas.

Immer [lexicon]Hochskalieren[/lexicon] lassen oder die [lexicon]Auflösung[/lexicon] der Aufnahme belassen. Das ist das beste was man machen kann dann.

Genau. Aufnahmeprogramme niemals skalieren lassen. Das geht später nach hinten los, weil Point Resize.

Und ein Clear Type Font mittels YV12 ist genausowenig Ratsam. Wegen der Farbrasterung von YV12. Die ist ja da halbiert.

Hier mal ein Bild was mit Clear Type gemeint ist:

Oben siehst du den Clear Type Font und unten den Standard Font.
Und Civilisation nutzt seit Teil 3 eigentlich nur Clear Type.

Standard Font könnte man aber besser komprimieren + sehen im Nachhinein auch besser aus.

Das ist der Clear Type Effekt (Font) in Kombination mit einer YV12 Aufnahme ODER
Eine Aufnahme die nicht richtig proportional dem Original skaliert wurde. Oder beides

Ich weiß das seit Civ 3 Clear Type genutzt wird für die Spiele. Das ist sehr eklig eigentlich.

Weil Clear Type nutzt ein geringen Anteil an Farben die dir bei YV12 in der geringen Rasterung der Schriftgröße im Spiel fehlen. Daher werden diese Farben verschmiert. Effekt wäre das solche Schriften recht deformiert aussehen.

Kleine Schriften in satten Farben wie Rot, Grün oder Blau würden bei YV12 Aufnahmen verschmieren, da die Farbenqualität nur die Hälfte beträgt bei einem YUV 4:2:0.

Die Rasterung der UV Anteile sind jeweils immer Horizontal und Vertikal immer zwischen den Luma (Y) Anteil. Luma alleine wiederum wäre nur ein reines Graubild.

Darum zerlaufen Farben bei YV12 Horizontal und Vertikal. Besonders bei Pixelgroßen Schriften sehr zu sehen.
Bei YV24 würde dies nicht passieren. Dort würde die Farbqualität 100% betragen. Chromaanteil = Lumaanteil. Dort würde alles Top aussehen.

Lösung wäre bei Videos mit zerlaufender Schrift das Bild doppelt so groß zu skalieren. Damit werden die Pixelgroßen Schriften größer und der Zerlaufeffekt würde Minimiert werden.

Noch bessere Resultate wäre eine reine RGB Aufnahme der Spiele. Das könnte man dann so verarbeiten das selbst die YV12 Konvertierung später keine Verschmierungen aufweisen würden.

Ich hatte mal diesen Effekt mal Bildlich in einen anderen Thread gezeigt:
SagaraS Scriptmaker (GUI)

Etwas weiter unten im Post siehst du die Bilder. Die Schrift war jeweils ein paar Pixel breit. Aber du siehst die Verschmierung halt schon extrem

Zitat von Kayten

Das Spiel ist allgemein einfach ziemlich zickig, zumindest bei mir und akzeptiert bisher nur den Fenstermodus zusammen mit [lexicon]Dxtory[/lexicon] als problemfreie Aufnahmemethode, was aber höchstwahrscheinlich nicht auf mangelnde [lexicon]HDD[/lexicon] Leistung zurückzuführen ist, trotz RGB Aufnahme. Keines der Spiele, welches ich bisher aufgenommen habe, hat diesbezüglich Probleme gemacht. Entweder hatten die Spiele eine geringere [lexicon]Auflösung[/lexicon], das Bildmaterial war nicht sonderlich komplex oder es gab immer nur wenige Änderungen. Einzige Ausnahmen sind da die Testaufnahmen zu DX:HR gewesen, deren [lexicon]Bitrate[/lexicon] deutlicher höher liegt als bei allen anderen bisher getätigten Aufnahmen. Die Barracuda scheint aber auch damit bis jetzt kein Problem zu haben. "Alle Aufnahmen in RGB" klingt in dem Fall also dramatischer, als es eigentlich ist.

Schon mal wärend der Aufnahme die Spiel FPS im Auge behaltet? Wenn die zu stark runtergedrückt wird, liegt das an der Darstellung.

Ich weiß z.B. das bei mir der [lexicon]SNES[/lexicon] Emulator ZNES mit der Double Buffering Einstellung zwars Aufnehmbar ist, aber total lahmarschig. Wenn ich es ausschalte geht die Performance wieder hoch.
Double und Triple Buffering laufen jeweils nur in Vollbild von der [lexicon]Grafikkarte[/lexicon]. Könnte ein Grund z.B. sein.

Bedenke das Spiele im "Windowed Mode" anders laufen als im Vollbild. Jeweilige Grafikunterstützung die der Vollbildmodus erlaubt gibt es bei dem "Windowed Mode" nicht.

Zitat von Kayten

Spricht auch grundsätzlich nichts gegen, [lexicon]Dxtory[/lexicon] würde in dem Fall schließlich funktionieren, nur wenn sowas scheinbar willkürlich eintritt ist die jeweilige Aufnahme dann im Eimer, da es beim Testen nicht aufgefallen ist. Falls es nur manchmal auftritt, kann es wahrscheinlich komplett vermieden werden, wenn bekannt ist wodurch es verursacht wird. Ist immerhin nur ein einziges mal bei einem anderem Spiel passiert.

Nix ist zu 100% sicher und Aufnahmeprogramme sowieso nicht. Aufnahmeprogramme würde ich immer in Auge behalten und wenn das Aufnahmeprogramm für das jeweilige Spiel spinnt, dann für dieses Spiel mal mit einem anderen Aufnahmeprogramm probieren, bevor man sich zu Tode sucht an den Einstellungen und es am Ende doch nix wird.

Weil neue Einstellungen die nur auf ein paar bekannte Spiele funktionieren sind Sonderfälle und sollten dann auch so behandelt werden das man sich die Zeit gibt die Einstellungen effizient auszutesten. Man will ja schließlich nicht wie du sagst mitten in einer mühseligen Aufnahme das die Arbeit umsonst war

Daher würde ich eher zu einem anderen Aufnahmeprogramm erst mal raten. Weil AB hookt sich definitiv immer gleich in ein Spielcode ein. Genauso wie es [lexicon]Fraps[/lexicon] und auch [lexicon]DXTory[/lexicon] auf ihre Art und Weise machen.

Zitat von Kayten

Dürfte ziemlich ätzend sein das herauszufinden. Gibt es da etwas bekanntes wo man ansetzen könnte? Multi-Monitor Betrieb, Anschlussart, Skalierungsart bei geringeren Auflösungen?
Wäre mir doch ein großes Anliegen, dass das funktioniert.

Fangen wir doch mal damit an indem du uns deine komplette Grafikkarteneinstellungen postest und sämtliche AB Einstellungen in Sinne von Videoaufnahme und Riva Tuner.
Und vllt das Betriebssystem mit Samt SP mal nennen.

Wär auf jedenfall schon mal ein Anfang für eine gemeinsame Suche des Problems. Vllt. sieht ja einer dann das Problem.

Zitat von Kayten

Beim Wechsel der [lexicon]Auflösung[/lexicon] bei einer Desktopaufnahme wird die aktuelle Aufnahme abgebrochen und keine neue angefangen.

Bei einem Split des Videos bei einer Desktopaufnahme in AB, muss die gesamte Desktopauflösung sich ändern, damit dies funktioniert. Ändert diese sich nicht, ist der Effekt hinfällig.

Desktopaufnahme heißt beim AB das im RivaTuner "Detection Level" auf None steht.

Jedoch... (und das sollte mitbedacht werden) ist entscheident wie der Wechsel stattfindet.

Das kann durchaus sein das es ein Grafikkartenproblem ist, wo eine Einstellung stört. Welche und ob es tatsächlich so ist, müsste man probieren.

Zitat von Kayten

Bei manchen Spielen (deutlich aufgefallen bei [lexicon]Deus Ex: Human Revolution[/lexicon]) "flackert" das aufgenommene Material zwischen Frames von unterschiedlichen Zeitpunkten hin und her.

Der AB ist kein Allrounder der alles aufnehmen kann. Ein Let's Player sollte daher immer einige Alternativen besitzen.

Den Fall das das Bild "flackert" hängt damit zusamm wie sich in das Spiel eingehookt wird.

Viele Programme wie [lexicon]Fraps[/lexicon], [lexicon]OBS[/lexicon], [lexicon]DXTory[/lexicon] haben neben dem AB ganz andere Hooking Verfahren mit denen sie sich in den Spielcode einhaken tun.

z.B. kann [lexicon]Fraps[/lexicon] sich in 256 Farben Anwendungen hooken wie es bei Diablo 2 der Fall ist. AB hingegen kann das Spiel auf den Tot nicht ab und nimmt es nur mit absolut krassen "Flackern" auf.

Wie und was die Aufnahmeprogramme supporten muss man selbst probieren und austesten. Viele Spiele lassen sich auch "verarschen", indem man Sie nachträglich DXfähig macht wie z.B. mit [lexicon]DXwnd[/lexicon] oder mit Mods den Spielen eine Darstellung bieten die nun aufnehmbar ist (wie z.B. das Hinzufügen eines Double Bufferings oder einer Nachträglichen Direct3D oder OpenGL Grafik) oder für das Spiel gibt es Emulatoren oder Sourceport Anwendungen die diese Sachen dann mitliefern.

Gibt es weder das eine, noch das andere, behilft man sich damit das Spiel in den "Windowed Mode" zu bekommen bzw. kann man versuchen ob auch Vollbild das Spiel mit einer Desktopaufnahme ohne Hooking aufzunehmen ist. (Sollte erst als letztes Mittel dienen, da Hooking viel performanter ist.)
Nimmt man die Spiele in "Desktop Mode" auf, kann es sehr schnell geschehen und vorkommen das Spiele übelste [lexicon]Laggs[/lexicon] bekommen.

In deinem Fall würde ich daher einfach mal ein anderes Aufnahmeprogramm probieren.

Zitat von Kayten

Sobald die Aufnahme beginnt entstehen Störgeräusche in Spielsound und Stimme, betrifft bisher nur The Binding of Isaac: Rebirth.

Geräteprobleme kann es durchaus geben. Vor allem dann wenn es sich um USB Mikros noch handelt, da USB Geräte immer von Treibern abhängig sind. Das kann durchaus schon ein Grund sein.

Ein anderer Grund wäre das es beim Einhooken in die Spielsoftware Abgreifprobleme gibt, sobald sich das Aufnahmeprogramm in den Spielcode einhaken tut.

Das Reinhooken in den Spielcode kann bei einigen Games (je nach Grafikdarstellung) negativ sich auf die gesamte Aufnahme auswirken.
Das Ganze wirkt wie ein Addon zum Spiel. Sprich das Aufnahmeprogramm läuft fest verbunden mit dem Spiel mit. Verbunden sind sie über die Frames.

Will man Aufnehmen drückt man die FPS des Spieles also etwas runter. Resultierend aus der nun langsameren Spiel FPS (Und sei sie noch so minimal) kann es sein das der Spielsound nicht fließend mitkommt und sich mit Spielgrafik synchronisiert. Ergebnis ist dann ein Knistern und Knacksen des Spielsounds in der Aufnahme und wärend des Spielens.

Abhilfe schafft da eine performantere Aufnahmegeschwindigkeit, denn das Abgreifen des Bildes in den Buffer braucht ja nicht viel. Das Speichern jedoch mehr. Dauert das Speichern der Frames durch den [lexicon]Encoder[/lexicon] des Aufnahmecodecs zu lange, unterbricht er die Anwendung, bis er den [lexicon]Frame[/lexicon] geschrieben hat. Das zeugt dann meist das Spiele langsamer laufen als Sonst und man merkt es eigentlich schon das wärend der Aufnahme die FPS runtergedrückt werden.

Zitat von Kayten

Alle Aufnahmen waren bisher in RGB.

Das wird dann auch dein Problem beim letzteren Punkt sein. Da wird wohl deine [lexicon]Festplatte[/lexicon] mit dem Schreiben nicht hinterherkommen. RGB Aufnahmen sollte man in Maßen machen. Eine Standard USB2.0 Verbindung zu einer [lexicon]HDD[/lexicon] die rund 50MB/s schreiben kann, kann man eine [lexicon]Auflösung[/lexicon] von max. 720p bei 4:3 mit 25 FPS machen. Danach würde die [lexicon]HDD[/lexicon] förmlich in die Knie gehen und mit ihr die Spiele.

Bei rasanten Games wie Autorennen etc. müsste die [lexicon]Auflösung[/lexicon] sogar noch weiter runter gedreht werden auf 480p bei gleicher genannter [lexicon]HDD[/lexicon] und Verbindung.

Ein Raid0 aus zwei sehr Leistungsstarken Festplatten können höhere RGB Aufnahmen stemmen.

Um nicht soviel der [lexicon]Festplatte[/lexicon] zuzumuten nimmt man für Gewöhnlich in YUV420 bzw. in YV12 auf. Das ist der Standard und sollte auch Festplattenmäßig nicht so eine krasse Nutzung darlegen wie RGB.

Man stufft eigentlich wie folgt ein:
RGB32 - 4:4:4 - Spielgrafik
Die höhste Qualität die an einem normalen Haushalts PC erreicht werden kann. Eine Aufnahme in diesen Farbraum ist absolut rein und entspricht 1:1 dem Game. Leider würde dementsprechend auch sehr viel Speicherplatz fressen und die Schreibgeschwindigkeit und die Übertragungsgeschwindigkeit zur [lexicon]HDD[/lexicon] sollten ausreichend sein.
Gleiches mit RGB24 - 4:4:4
RGB24 entspricht ebenfalls der Spielgrafik indirekt. Es fehlt ledeglich der [lexicon]Alphakanal[/lexicon] mit denen die Spiele operieren. Ansonsten das gleiche wie RGB32.

YV24 (YUV444) - 4:4:4 - Sehr hohe Videoqualität der Farben. Entspricht 100%
YUY2, YV16 (YUY422) - 4:2:2 - Hohe Videoqualität der Farben. Entspricht ~66,6%
YV12 (YUV420) - 4:2:0 - Mittlere Videoqualität der Farben. Entspricht 50%
YUV411 - 4:1:1 - niedriege Videoqualität der Farben. Entspricht ~33,3%
GREY, Y8 (YUV400) - 4:0:0 - sehr niedriege Videoqualität. Entspricht 0%

Das sind Farbqualitätsangaben. Jeder YUV Farbraum würde den Helligkeitsanteil (Luma/Y) immer Konkret und perfekt darstellen können (Siehe GREY, Y8 = Graubild ohne Farbe). So ein Bild würde natürlich kaum Speicher benötigen und die [lexicon]Festplatte[/lexicon] wäre dann sehr entlastet.
Gibt man noch den Farbanteil hinzu (Chroma/UV), so ist das Farbspektrum was gespeichert werden muss und auch die Rasteranordnung selbst bei solchen Planars wieder höher, so dichter das Verhältnis zueinander ist.
Bedeutet das du bei YV24 4:4:4 mehr Speicher benötigst, als Beispielsweise YV12 4:2:0

Ich kann dir auch die Bitanzahl die pro Pixel benötigt werden mal nennen:
RGB = 4:4:4 = 24Bpp + 8bpp = 32bpp (RGB32, RGBA)
RGB = 4:4:4 = 24Bpp (RGB24)
YUV = 4:4:4 = 24Bpp + 8bpp = 32bpp (AYUV)
YUV = 4:4:4 = 24Bpp (YV24)
YUV = 4:2:2 = 16Bpp (YUY2, UYUY)
YUV = 4:2:0 = 16Bpp (IMC1, IMC3)
YUV = 4:2:0 = 12Bpp (IMC2, IMC4, YV12, NV12)
YUV = 4:1:1 = 12Bpp
YUV = 4:0:0 = 8Bpp

Wenn man von der Kompression eines Encoders absieht kann man folgendes für unkomprimierten Vorgang errechnen:

RGB32:
1920px × 1080px * 25 FPS * 32Bpp (RGB32) = 1658880000Bit/s = 1,66 GBit/s

YV12:
1920px × 1080px * 25 FPS * 12Bpp (YV12) = 622080000Bit/s = 622,08 MBit/s

Lass noch die Kompression ihre Wirkung tun und man ist so zwischen 50 bis 100MBit/s die man an Übertragungsrate zur [lexicon]HDD[/lexicon] und Schreibgeschwindigkeit der [lexicon]HDD[/lexicon] benötigt.

Bei RGB wäre es halt einiges mehr. RGb lässt sich zwars hervorragend komprimieren, aber nur wenn es A) Frames sind die hintereinander total Ähnlich sind und B) wenn sie nicht soviel Detail haben.

Eine undetailierte aufgenommene RGB Aufnahme wo mehre Bilder auch von der Zeit her regelrecht stehen bleiben kann man gut und gerne von ein paar mehreren GB in KB runterkomprimieren lassen. Kommt auf die Frames halt an.

modernere Spiele sind meist Komplexer und würden sich halt auch nicht dermaßen komprimieren lassen.

Die Install bitte abändern. Ich möchte nicht das sich das Programm auf C:\ installiert. Ich möchte meine Programme z.B. alle auf D:\ haben.

Zitat von Strohi

Das letzte Update zeigt immerhin schon einen anderen Fehler.
Die DLL gibt es definitiv. Ist da sicher die richtige [lexicon]Avisynth[/lexicon]-Version mitgeliefert oder was passt da nicht?
Das Skript wurde gerade mit der neusten Version des [lexicon]SSM[/lexicon] erstellt.
Tritt der Fehler bei dir auch auf?

Ein Skript von MeGUIs [lexicon]AVS Script Creator[/lexicon] läuft problemlos.

Weil er [lexicon]AVISynth[/lexicon] 64Bit und 32Bit da nutzt. Und die 64Bit Version von [lexicon]AVISynth[/lexicon] kann nix mit einem 32Bit Plugin wie SplineResize anfangen. Daher der Fehler.

Ich hätte vorgeschlagen einen Schalter wenn dann schon einzubauen der dann auf das 64Bit [lexicon]AVISynth[/lexicon] greift. Ansonsten sollte Standardmäßig immer die 32Bit Version genutzt werden, da es dafür auch die Masse an Plugins gibt.

Zitat von Strohi

Die avi hat aber zwei Audiostreams. Im Skript wird aber keiner hinzugefügt / genannt, ja.

[lexicon]AVISynth[/lexicon] nimmt immer den ersten Audiostream den er findet. Mehr kann AVISource nicht. Erst das neue [lexicon]AVISynth[/lexicon] könnte es, wenn man noch eine Funktion dazu schreibt. Ist aber unnötig.

Für Gewöhnlich wird bei [lexicon]AVISynth[/lexicon] Skripten immer Video und Audio separiert vorher.
Was meint ihr was [lexicon]MeGUI[/lexicon] macht? Was meint ihr was AutoGK macht? Jedes Programm was [lexicon]AVISynth[/lexicon] verwendet zerlegt Video und Audiostream voneinander. Weil das halt unüblich ist das beide Sachen in einem Skript durchlaufen.

Sind sie getrennt kann man Audio extra behandeln und sich bei Video nur auf das Video konzentrieren.

Die Zusammenführung geschieht so oder so wieder beim [lexicon]muxen[/lexicon].

[lexicon]x264[/lexicon] kann ja auch nur das Videomaterial des Skriptes lesen. Und die Audioencoder wie [lexicon]FLAC[/lexicon] können via einer Pipeline nur den Audioteil eines [lexicon]AVISynth[/lexicon] Skriptes lesen. Daher ist es performanter Video und Audio zu trennen. Das macht der [lexicon]SSM[/lexicon] ja auch schon.

Zitat von Ao Kurisu

Ich kann [lexicon]AviSynth[/lexicon] schon der Installer-Routine hinzufügen. Dazu wüsste ich aber gerne, welche Registry-Einträge gesetzt werden, damit das Setup auch die Installation überprüfen kann.

Windows Registry Editor Version 5.00


[HKEY_CLASSES_ROOT\CLSID\{E6D6B700-124D-11D4-86F3-DB80AFD98778}]
@="AviSynth"


[HKEY_CLASSES_ROOT\CLSID\{E6D6B700-124D-11D4-86F3-DB80AFD98778}\InProcServer32]
@="%INSTALLDIR%\AviSynth.dll"
"ThreadingModel"="Apartment"


[HKEY_CLASSES_ROOT\Media Type\Extensions\.avs]
@=""
"Source Filter"="{D3588AB0-0781-11CE-B03A-0020AF0BA770}"


[HKEY_CLASSES_ROOT\.avs]
@="avsfile"


[HKEY_CLASSES_ROOT\avsfile]
@="AviSynth Script"


[HKEY_CLASSES_ROOT\avsfile\DefaultIcon]
@="%INSTALLDIR%\AviSynth.dll,0"


[HKEY_CLASSES_ROOT\.avsi]
@="avs_auto_file"


[HKEY_CLASSES_ROOT\avs_auto_file]
@="AviSynth Autoload Script"


[HKEY_CLASSES_ROOT\avs_auto_file\DefaultIcon]
@="%INSTALLDIR%\AviSynth.dll,0"


[HKEY_CLASSES_ROOT\AVIFile\Extensions\AVS]
@="{E6D6B700-124D-11D4-86F3-DB80AFD98778}"


[HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth]
@="%INSTALLDIR%"
"plugindir2_5"="%INSTALLDIR%\plugins"

Einige Sachen müssen dann noch RegServer aktiviert werden. Siehe Registry Eintrag. Sonst erkennt das [lexicon]OS[/lexicon] es nicht.

[lexicon]AVISynth[/lexicon]+ brauchst du noch nicht verwenden. Ist noch nicht das Wahre das Ganze.

Mach es so das [lexicon]AVISynth[/lexicon] und danch die MT Version installiert werden.

Zuerst muss das normale rauf und dann die entsprechende MT Version dazu.

AVISynth 2.6 RC - 2015-01-14 - Build: 150114

Dazugehörige MT Version
AVISynth 2.6 MT by SET - 2015.02.20

Installier [lexicon]SSM[/lexicon] und wähle da [lexicon]AVISynth[/lexicon] aus. Dann installiert er das zusammen mit der MT Version ins richtige System Verzeichnis von Windows.

Zitat von Ao Kurisu

Hast du ein 64-Bit Betriebssystem? In dem Fall wird nämlich auch ein 64-Bit [lexicon]Avisynth[/lexicon] verwendet.

Aufm 64Bit [lexicon]OS[/lexicon] sollte ebenfalls das 32Bit [lexicon]AVISynth[/lexicon] verwendet werden, da es die meisten Plugins für 32Bit gibt.

Zitat von Ao Kurisu

Unterstüzt das [lexicon]Spline[/lexicon]-Plugin 64-Bit?

Nein

Ich hatte zusammen mit GelberDrache auch erst mit [lexicon]AVISynth[/lexicon]+ 64Bit und einer normalen [lexicon]AVISynth[/lexicon] 64Bit Version probiert ob die Plugins die beim [lexicon]SSM[/lexicon] beiliegen soweit funktioniern. Über die Hälfte der Plugins konnten wir vergessen. Auch viele Programme konnten mit den Skripten nix anfangen. [lexicon]VirtualDub[/lexicon] 64Bit war eines der wenigen die mit den Skripten dann was anfangen konnten.

Ich glaube das selbst die Pipeline avs4x264mod bei [lexicon]MeGUI[/lexicon] ein Problem mit [lexicon]AVISynth[/lexicon] 64Bit hat. Also [lexicon]MeGUI[/lexicon] konnte es da nicht mal verarbeiten mehr.

Also ich sag mal... 64Bit [lexicon]AVISynth[/lexicon] sollte man vermeiden, weil es zum einen zu wenig Plugins dafür gibt und zum anderen wenige Programme die damit was anfangen können.

Der [lexicon]SSM[/lexicon] nutzt ja die 32Bit Version nicht aus Spaß ;D Zumal die MT Version nur für die 32Bit Version gibt.