Beiträge von Sagaras

  • OBS - Aufnahme laggt bei Medien-Quelle

    Das Problem ist... Videos brauchen Zeit zum Encoden. Du hingegen willst Live encodiert aufnehmen. Und genau damit ist der Encoder überlastet.
    Weil wenn der Encoder die Frames nicht schnell genug verarbeiten kann, und das ist bei 1440p60 schon allerhand, dann versuchen die meisten Encoder Frames zu überspringen. In deinem Falle sogar schon massiv.


    Das ist auch schon der ganze Spuck dahinter. Deine CPU für die x264 Encodierung, mit der du in OBS aufnimmst, ist eindeutig zu hoch. Und daher bekommst du halt diese Laggs.


    Entweder: x264 auf Ultrafast stellen und qb=0 eintragen für Lossless. Dann wird die CPU entlastet, weil x264 nicht mehr massiv encodieren muss.
    Oder du nimmst bei OBS Studio über FFMpeg mit UTVideo auf. Würde auch gehen. Auf jedenfall wirst du somit nicht nur bessere Qualität erzielen, sondern deine CPU wird es dir danken, das sie nicht mehr viel tun musst.


    Immerhin musst du bedenken, wenn du ein Video abspielen tust, was OBS aufzeichnen soll, muss dieses ebenfalls decodiert werden. Ist das dann noch ein x264 codiertes Video wird beim Decodieren sehr viel CPU Leistung benötigt.

  • Gibt es Erweiterungen für den Loilo Game Recorder ?

    Zitat von Kayten

    Ich bezweifle aber, dass auch nur eins davon wirklich gut bei dir läuft. Notebooks sind zum Aufnehmen generell nicht zu gebrauchen.

    Mach ich aber Hauptsächlich ^^


    Und wenn ich selbst auf meinen alten Lappi mit einem Core Duo und einer GeforceGS 8600 RGB Lossless Aufnahmen starten konnte in 720p30, sollte das ja nun machbar sein. ^^
    Alles eine Frage der Festplatte.


    Da durfte ich halt nicht zuviel erwarten.


    Jetzt habe ich auch wieder ein Lappi, kann aber 900p60 Aufnahmen in RGB Lossless gestallten ^^ Nutze dafür aber auch 3 von 8 Threads.


    Bei dem Core Duo zuvor war ich schon recht gut in der Grenze des Machbaren. ^^


    Sehe daher nicht wirklich was einen Tower in dieser Hinsicht besser macht.


    Ein Tower ist erweiterbar und schnell modifizierbar, ja. Aber die Technik ändert sich doch nicht wie es funktioniert.

  • Encoding-Talk

    Ja, ok. Aber bei VirtualDub kann ich 32Bit und 24Bit Audio erzwingen lassen mit TSearch. Man könnte also ein Tools bauen der dies bei der Laufzeit von VDub erzwingt. Wäre kein Problem.


    Bei Amarec weiß ich das nicht. Könnte mir aber vorstellen das dies auch gehen würde.

  • .flv Converter /gutes Aufnahmeprogramm

    Ein Schwarzes Bild bei der Aufnahme kann darauf hindeuten das kein Hooking stattgefunden hat und er die Frames nicht abgreifen konnte.


    Das passiert oftmals bei Emulatoren die falsch eingestellt sind, bei Zwischensequenzen die mit BIK oder SMK oder was weiß ich laufen und dafür einen anderen Renderer nutzen.


    Und F1 hätte ich jetzt nicht gerade als Aufnahmetaste verwendet. F1 ist üblicherweise immer eine Hilfe Taste, die in vielen Spielen und auch von Windows genutzt wird. Suche dir daher bitte mal eine andere Taste dafür. Wie z.B. die Bild auf oder Bild runter Taste oder irgendeine Taste auf dem Nummernblock der Tastatur. Ist Sicherer. ^^


    Vllt. hilft es ja noch wenn du uns sagen könntest um welches Spiel oder Programm es geht das du versuchst aufzunehmen.

  • Encoding-Talk

    Zitat von De-M-oN

    Hat das einen tieferen Sinn, warum ich weder bei AmarecTV noch bei Virtualdub die Audiogeräte nicht in mehr als 16bit aufnehmen kann? @Sagaras vllt eine Idee?

    Also bei VDub musste das doch nur umstellen. Geräteeinstellung werden in Programmeinstellung (VDub) konvertiert.


    Sprich: Gerät ist auf 48000Hz, 24Bit, Stereo eingestellt, dann wird das von VDub so erkannt und neu Resampelt auf die Einstellungen in VDub mit z.B. folgenden Einstellungen: 44100Hz, 16Bit, Stereo


    Und Vdub sollte dir das eigentlich auch so erlauben es umzustellen. Musste mal in die rechte untere Ecke in der Statusleiste schauen. Da sind die Angaben für Audio. Da klickste einfach mal drauf und stellst es dir ein.


    Bei AmarecTV wüsste ich jetzt nicht was da Sache wäre. Müsste ich sehen.

  • .flv Converter /gutes Aufnahmeprogramm

    Zitat von stefan_wayne

    Keine Sorge, hatte schon das UT Video aus dem Tutorial mir geholt, allerdings bin ich etwas verwirrt hatte schon häufig gelesen, dass x264 der beste Codec sei / der effizienteste.

    x264 ist der beste und effizienteste Verlustbehaftete Codec den es als Standard gibt. Jedoch ist er für lokale Aufnahmen nicht geeignet. Zum einen braucht er Unmengen an Ressourcen sofern man die Effizienz nutzen will und zum anderen kann er zwars auch Lossless aufnehmen, doch können viele Programme gar nix damit anfangen.


    Sehr effizient bei einer lokalen Aufnahme sind Lossless Codecs wie MagicYUV, UTVideo, FFV1 und ganz zum Schluss kommt Lagarith.
    Dann gibt es noch die weniger effizienten Lossless Codecs wie zmbv, zlib, MPNG, usw...


    Alle diese Lossless Codecs besitzen Kompressions Mechanismen mit denen die Informationen zusammengequetscht werden können (ZIP, RAR, 7zip oder ähnliches kann man sich darunter vorstellen). Hierbei geht keine Info verloren. Daher nennt man dies auch Compress Lossless.


    Dann gibt es noch Uncompress Lossless. Das heißt das die Informationen nicht komprimiert werden. Dazu zählen RAW Aufnahmen wie Windows es schon intern vorzuliegen hat.


    Halten wir also fest: Für Streaming und finalen lokalen Encode ist x264 am effizientesten.
    Für lokale Aufnahmen ist ein angebrachter Lossless Codec besser. So wie MagicYUV oder UTVideo.


    Zitat von stefan_wayne

    Andere Frage noch, ich habe mir an FFMPEG die Zähne ausgebissen.


    Ich hatte den import und den output hinbekommen. Aber da ich die Ausgabedatei nicht öffnen konnte muss ich zwangsläufig zwischendrin etwas falsch gemacht haben.

    Ummuxen von flv zu mp4
    ffmpeg.exe -i "C:\temp\video.flv" -c:v copy -c:a copy "C:\temp\video.mp4"


    Transcodieren von flv zu UTVideo & PCM (Lossless)
    ffmpeg.exe -i "C:\temp\video.flv" -c:v utvideo -c:a pcm_s16le "C:\temp\video.avi"


    Demuxen von flv in seine Bestandteile:
    ffmpeg.exe -i "C:\temp\video.flv" -c:v copy -map 0:0 "C:\temp\video.m4v" -c:a copy -map 0:1 "C:\temp\video.m4a"


    FFmpeg ist ein Commandozeilen Prozess der nur über die Command Console (CMD.exe) funktioniert.


    Zitat von stefan_wayne

    Gibt es irgendwo ein idiotensicheres Tutorial für einen Demuxer? Oder einen idiotensicheren Demuxer mit GUI der auch funktioniert?

    Für einen DAU gibt es nix was sicher wäre. ^^ Daher ist immer ein wenig Mitarbeit erforderlich.
    Als GUI würde ich die MP4Box GUI nicht empfehlen. Das Teil ist gewiss noch in der Urzeit stecken geblieben. Wenn du schon MP4Box nutzen möchtest, wären Programme wie MeGUI oder YAMB am idealsten. Und deren Mp4Box baut auf die CLI Versionen auf, die weitaus weiter sind ^^


    Zitat von stefan_wayne

    Im VLC Player kann ich das video gar nicht erst abspielen. Fehlermeldung:
    "Codec wird nicht unterstützt:
    VLC konnte das Format „ULH2“ (No description for this codec) nicht dekodieren"

    • aktuelle VLC Version installieren
    • Bei der UTVideo Setup (aktuelle Version: Download) alles installieren lassen.

    UTVideo kann ich dir versichern das VLC das abspielt. Vorausgesetzt die Aufnahme war ok und hatte keine Fehler zu folge.
    Besser wäre den Media Player Classic - Home Cinema zu verwenden (64Bit oder 32Bit / Download: https://mpc-hc.org/) und dazu auch noch ffdshow tryouts (Download: http://ffdshow-tryout.sourceforge.net/download.php (Bitte 32Bit Version nutzen))



    Zitat von stefan_wayne

    Habe gerade mit MSI afterburner eine Testaufnahme gemacht. Es ist alles haargenau so eingestellt, wie in dem Tutorial von Deamon.Wenn ich das video abspiele, dann gibt es Probleme über Probleme.

    Deine Einstellungen vom Afterburner vom Reiter Video mal posten (alle)
    Und die Einstellungen vom Riva Tuner Statistic Server (RTSS) mal posten (alle)


    Und dazu auch mal die Konfigurationseinstellungen des UTVideos mal posten bitte.


    Zitat von stefan_wayne

    Windows Media-Player kommen ein sehr ruckeliges Bild und meine Stimme, aber kein Spielsound.

    Wenn du Spur1 mit Mikrofon belegst und Spur2 mit Ingame Sound (Was man eigentlich in der Regel immer anders herum macht), dann ist es klar das nur die Stimme kommt.
    Entweder du hast Spur2 gar nicht angegeben welches Gerät er aufnehmen soll oder dein Abspielprogramm nutzt gerade Spur1.


    In der Regel trennt man Spur1 und Spur2 voneinander (Machen ja Filme mit unterschiedlichen Sprachen ja auch) und kann sie so besser im Nachhinein abstimmen wie z.B. mit Audacity. Dort kann man beide Spuren abstimmen und mischen lassen, sodass am Ende eine Spur entsteht mit Mikro. und Ingame Sound.


    Eigentlich ganz Easy wenn man das mal gemacht hat. ^^



    Zitat von stefan_wayne

    Beim RTSS kommt immer die Fehlermeldung: Cannot establish connection to the update server, falls das irgendwie im Zusammenhang steht.

    Das funktioniert schon Ewigkeiten nicht mehr. ^^


    Hier die aktuelle Version vom MSI Afterburner mit aktuellem RTSS: http://www.guru3d.com/files-ge…ner-beta-download,30.html
    Seite mit den Versionen: http://www.guru3d.com/files-de…burner-beta-download.html



    Zitat von stefan_wayne

    Edit: Am Spiel liegt es nicht. Anderes Spiel exakt die gleichen Probleme.

    Das Problem wird noch bei dir selbst sein vermute ich mal. Weil du vermutlich noch nicht richtig durch siehst ^^
    Sobald aber erst einmal alles da ist und eingestellt ist das am Ende nicht viel. ^^

  • Warum kann diese Datei nicht in Premiere geöffnet werden?

    Zitat von De-M-oN

    Kann man Frameserver mit Multithreading kombinieren? Habs bislang sicherheitshalber immer ohne gemacht. Aber vllt haste ja schonmal probiert gehabt.

    Kann man machen. Musste genauso auf die Sachen achten die du für das Encodieren über MeGUI nutzt.


    Das AVISynth Skript wird ja lediglich mit MT ausgeführt. Damit hat der avfs-Frameserver ja nix am Hut. Der avfs wird die Frames nur weiterleiten und nutzt soviel Threads wie er brauchen tut. Das Teil ist ja MT Fähig.

  • MagicYUV - Ein neuer Lossless Codec!

    Wenn man in MagicYUV die Log aktiviert, kann man es sogar nachlesen welchen Encoder er genutzt hat bei der Verwendung des 64Bit Dedizierten Encoder-Server-Dienst.


    Wenn der ausgewählte VFW Encoder keine entsprechende 64Bit Version hat, bzw. nicht installiert ist, so nimmt er aus Kompatibilitätsgründen halt die 32Bit Version des Encoders.

  • Gibts den AVS Cut Generator nicht mehr?

    Die Werte werden gewiss im Zwischenspeicher rumstehen und können dann halt auch geändert werden. Müsste man nur suchen. Wenn man es auf den Wert 0 erzwingen kann und der Encoder von TMPGenc das so auch akzeptiert ohne es irgendwie auf einen Standardwert wieder zu setzen, könnte es funktionieren. Müsste man mal ausprobieren. Und dann kann man dafür ein Tool schreiben das es macht.

  • MSI Afterburner - Kostenlose Alternative zu FRAPS und DxTory!

    Zitat von Spieluin

    Woran kann das liegen, dass Fallout 4 sich des Öfteren einfach schließt (man landet wieder auf dem Desktop), wenn der Afterburner versucht das Programm zu erkennen (Einblenden des Overlay) oder in dem Moment, wo es die Bilder abgreifen will (mit Beginn der Aufnahme)?
    Ist nur bei Fallout 4.

    Am Hooking.


    Afterburner greift mit einem bestimmten Code in die Anwendung des Spieles oder andere Software ein und kann somit bestimmte Informationen entweder auslesen oder abfangen und weiterleiten. Dieser Code Schnipsel wird als Hooking (Einhaken) bezeichnet.


    Der Afterburner und auch andere Aufnahmeprogramme könnten somit je nach Code den Abgriff der Bilder gewährleisten und jedes würde anderes arbeiten. Halt je nach dem wie dieser Abgriffcode programmiert wurde.


    In den meisten Fällen werden bei Aufnahmeprogramme die Ausgabe Renderer abgegriffen. Dazu gehören: DirectX, OpenGL, Glide, etc. pp.
    Im Falle von Shadowplay wird kein Renderer abgegriffen, sondern sogar noch vor dem Renderer die Bilder ausgelesen. Das geht aber nur, weil die NVIDIA Karten bereits die Shadowplay unterstützen ein Bild generieren können ohne die üblichen Renderer nutzen zu müssen. Daher ist Shadowplay bei Aufnahmen auch so performant.


    Warum nun aber das Hooking bei einigen Spielen abbrechen tut oder gar nicht erst startet, liegt oftmals am Quellcode des Spiels im Zusammenhang mit dem Ausgaberenderer. Wechselt z.B. ein Renderer im Spiel (oft zwischen InGame, Cutscenes oder Menü zu beobachten) kann die Aufnahme abbrechen, da sich der Renderer womöglich ändert.
    Ein Beispiel: Das Spiel nutzt für das Menü: DirectDraw, für die Cutscenes Overlay und für das InGame Direct3D. Das würde man jetzt bei dem Spiel Jedi Knight finden so.


    Ein anderer Abbruch der Aufnahme wäre durch eine Änderung der Auflösung des Spieles möglich. Hier wäre z.B. mal Star Wars Battlefront 2 genannt der mit dem Afterburner abbricht. Jedoch kann Fraps es aufnehmen.
    Dies liegt nun aber an der Programmierung der Hooking Methode.


    Auch liegt es oft an der Programmierung das ein Spiel oder Software sofort abstürzen tut, sobald ein Hooking Methode darauf zugreifen tut. Oft auch bei Cheat-Trainern zu beobachten die ebenfalls via Hooking arbeiten.


    Eine kleine falsche Adresse abgegriffen und die Anwendung wird geschlossen.



    Daher sollte man ja auch mehrere Aufnahmeprogramme als Alternative besitzen, da diese Hooking Verfahren bei jedem Aufnahmeprogramm abweichen in ihrer Programmierung.


    Und es kann auch sein das das Game dieses Problem verursacht, weil das Spiel gerne den Bildspeicher (Front- und Backbuffer) füllen möchte, aber das Aufnahmeprogramm es auslesen will. In diesem Falle nennt man es halt ein Schreib-Lese Zugriffs Problem.


    In der Regel wird der Backbuffer ausgelesen, da der Backbuffer bereits ein fertiges gerendertes Bild besitzt, während der Frontbuffer gerade dabei ist über den Backbuffer das nächste Bild zu zeichnen.


    Wird die Initialisierung zwischen Backbuffer und das Hooking des Aufnahmeprogrammes nicht richtig gemacht, kann das Spiel abstürzen. Eventuell ist sogar gerade der Zwischenspeicher extrem belastet oder das Spiel ist noch aktiv im Hintergrund, während man versucht das Spiel noch mal zu starten.


    Sowas ist allerdings recht selten. Man kann mit solchen Problemen sich an die Entwickler wenden oder man lebt damit oder man nutzt alternative Aufnahmeprogramme.


    DxTory, Afterburner, Fraps (Hat spezielle Hooking Tweaks bei einigen Games) oder auch OBS Studio währen die 4 Aufnahmeprogramme die man haben sollte um für Alternative zu sorgen.


    Die Hooking Merhoden scheinen in Angesicht der Anwendung immer gleich zu sein, sind aber schon von der Programmierung her völlig verschieden und verhalten sich dementsprechend auch unterschiedlich.

  • Encoding-Talk

    Zitat von Kayten

    Wenn die Ruckler nicht auch beim Spielen selbst spürbar sind, bleiben im Großen und Ganzen nur CPU, HDD und das Aufnahmeprogramm selbst übrig. HDD scheint recht ausgeschlossen worden zu sein, bei der CPU bin ich mir nicht sicher, da deine MagicYUV Einstellungen nicht einsehbar sind bisher und ob du andere Aufnahmeprogramme bereits getestet hast, weiß ich nicht.

    Es kann auch sein das das Hooking das MSI Afterburner nutzt nicht korrekt arbeitet mit dem Spiel. Das er zwars die Frames abgreifen kann, aber unregelmäßig das Hooking aufrecht erhält.


    Beobachten kann man dies eigentlich an der FPS Anzeige des Overlays das du während der Aufnahme siehst. Wenn die FPS zu sehr runter gehen, während du aufnimmst, oder auch ganz auf eine unterirdische FPS gehen, oder du andere unregelmäßige Sachen beobachtest, dann kann es sein das Frames Standbilder liefern. Auch wenn sie nur kurz sind. Wenn das unregelmäßig passiert, sieht das im fertigen Video aus als ob es laggen würde.


    Auch kann es sein das wenn kuriose Codec Packs installiert worden sind, diese dafür sorgen das die Decodierung fehlerhaft läuft.
    Sollte dies der Fall sein, ist es gut möglich das der Rechner eventuell neu aufgespielt werden muss, da sich Codec Packs nicht so ohne weiteres wieder entfernen lassen ohne Restschaden zu hinterlassen.


    Sollte ersteres eintreten (sollte auf jedenfall ausgetestet werden), dann sind entweder die Aufnahmeanforderungen zu hoch im Sinne von CPU oder HDD. Oder es liegt wie schon erwähnt an der Hooking Methode des Aufnahmeprogrammes. In diesem Falle sollte ein anderes Aufnahmeprogramm getestet werden. (Daher wird auch immer geraten sich nicht auf ein Aufnahmeprogramm sich zu versteifen, sondern immer mehrere im Petto zu haben als Alternative.)

  • Encoding-Talk

    @wlfnkls
    Könntest du uns die MSI Afterburner Aufnahme auf einem Hoster hochladen? Also die reine MagicYUV Aufnahme?


    @maux
    Könnte jetzt nur schätzen was es ist. Besser wäre es das Problem über TeamViewer und TeamSpeak zu suchen und zu lösen.

  • Encoding-Talk

    Ich wette mit dir das die Laggs bereits bei der Aufnahme so aufgezeichnet wurden.


    Glaube kaum das dies am Encoding jetzt liegt.


    Ich glaube eher das bei der Aufnahme die Frames nicht richtig abgegriffen wurden. Eventuell sollten wir bei der Aufnahme noch mal anfangen den Fehler zu finden.


    Da wäre zum einen das Programm wichtig zu nennen mit dem du aufnimmst + die Einstellungen dieses Programmes die zur Aufnahme des Videos dienen.