Beiträge von Sagaras

    OBS kann nur die Encoder x264, NVenc, QuickSync und AMD VCE verwenden für eine H264 Aufnahme. Die sind nativ verankert bei OBS.
    Aber OBS Studio kann über FFmpeg auch andere Encoder verwenden. Darunter auch UTVideo, Lagarith, ZMBV, MPNG, etc. pp.


    Ist aber etwas Suboptimal, da du dann nur eine Tonspur aufnehmen kannst. Das musste dann am besten mit einer 2ten Instanz lösen.


    Bei H264 Lossless, sofern du eines der H264 Encoder nutzen willst, kann es dann passieren das die Aufnahmen von deinem Schnittprogramm nicht erkannt werden.


    Wenn du über FFmpeg aufnehmen willst und UTVideo, Lagarith etc. nutzen willst, BITTE in einen AVI Container dann speichern lassen. Nicht in einen MKV oder MP4 Container. Sonst gibt es die nächsten Komplikationen.


    Und wenn du über einen H264 Encoder aufnehmen willst am besten in einen MP4 Container schreiben lassen. MKV können die wenigsten Schnittprogramme verstehen.
    Bei H264 Aufnahmen dann halt nicht Verlustfrei aufnehmen, sondern FAST Verlustfrei. Sprich den CRF auf 1 stellen. Lossless wäre QP=0


    Das musste dann manuell angeben in OBS.

    Naja, laut Mediainfo fehlt halt noch etwas an dieser Datei.


    554 GiB ist die Datei allgemein groß.


    Davon sind 255 GiB für Video Stream und 771MiB für Audio Stream. Da fehlt also noch einiges um auf die 554 GiB zu kommen.


    Der Fehler sitzt also nicht bei der Aufnahme, sondern am Header der Datei wo sich dann alle anderen Programme orientieren. Dein Repair Tool beweist es auch, weil die Dinger in der Regel die Streams die vorhanden sind analysieren und indexieren um somit dann den Header wieder zu säubern und neu zu schreiben.


    Sprich in dem Header deiner AVI Datei sitzt ein banaler Fehler. Und den schreibt nicht der Codec, sondern dein Aufnahmeprogramm.


    Ähnlicher Fall gab es mal vor einigen Jahren beim MSI Afterburner und dem Lagarith Codec. Jedes andere Aufnahmeprogramm hat im Header den richtigen Farbraum angegeben, nur der MSI AB nicht. Der hat da irgendein Quark an dieser Stelle im Header geschrieben.


    Ist bei deinem Video halt auch, nur das es halt die Streamgrößen betrifft. Die wird der nicht richtig angelegt haben. Vermutlich wird der mit 29.97 FPS gerechnet haben oder 30 FPS, weil das würde schon fast hinkommen.


    1h 16m = 4560s
    4560s * 60 FPS = 273600 Frames


    273600 Frames / 29.97 FPS = 9129s 1291ms
    9129s 1291ms = 2h 32m 9s 1291ms


    Kommt also schon fast hin. Danach hat er den Header verfasst dann. Während die Aufnahme mit 60 FPS lief.
    Sprich hier liegt ein Fehler seitens des Aufnahmeprogrammes vor.


    Kann auch sein das er mit UTVideo ein Problem hat. Versuche mal einen anderen Video Codec wie z.B. MagicYUV. Die Kostenlose Version sollte genügen.


    Wenn der Fehler wieder passiert solltest du dein Aufnahmeprogramm entweder Updaten oder dem Hersteller eine Fehlermeldung schicken. Oder du verwendest eine andere Software die mit deiner Elgato zusammen arbeitet. Sprich eine Drittsoftware. Sowas wie AmaRec oder Virtual Dub oder ähnliche Sachen.

    MeGUI's x264 Encoder kann alle Kerne nutzen.


    Die Frage die du dir aber stellen solltest ist wo dein Flaschenhals ist damit. Weil es reicht nicht nur das der Encoder alle Kerne nutzen kann, wenn die ganzen anderen Pipelines und Frameservers das regelrecht trichtern. Immerhin muss das duch den Frameserver in deiner Anwendung durch, durch AVISynth und wenn du den 64Bit x264 Encoder in MeGUI verwendest durch die Pipeline von "avs4x264mod".


    Das bremst natürlich aus. Und wenn das halt langsam noch geschieht, kannst du mit dem x264 noch zu viele Kerne erzwingen zu nutzen, er wird nicht mehr nutzen bzw. auch nicht schneller werden als das er die Frames abgreifen kann.


    Ist die Aufnahme dann noch eine H264 Aufnahme die mit NVenc oder x264 oder irgendein anderen H264 Encoder gemacht worden ist, kann das auch noch zusätzlich dauern, weil diese Dateien zwecks Video Filter und Co. erhöhte Dekodierungsdauer haben.



    Du brauchst also keinen neuen PC nur weil das länger dauert. Es ist halt das Prinzip das Ganze drumherum mal zu sehen was da passiert. Würdest du statt den Frameservern auf x264vfw umstellen mit deiner Schnittsoftware würdest du merken das das Enkodieren viel schneller voranschreitet. Weil du dann somit sämtliche Trichter die dazwischen waren ala Frameserver und Pipelines umgehst. Mit VFW hast du nur noch eine Pipeline und die sorgt dafür das das Video mit einem für Windows installierten Codec verarbeitet werden kann.


    Würdest du Vegas weglassen und nur mit MeGUI arbeiten, sieht das auch noch mal ganz anders aus, zweck der Verarbeitungs Geschwindigkeit. Weil wenn das Video was verarbeitet werden soll direkt über AVISynth reingeht, wird direkt von der Quelle die Datei gelesen, statt aus einer anderen Frameserver Quelle das zu entnehmen. Das beschleunigt den Prozess schon enorm.




    Aber mal zu deinem Ablauf den du gerade hast.


    Wenn der x264 Encoder von MeGUI ein Frame enkodieren möchte, fordert er das von der Pipeline avs4x264mod an. avs4x264mod bezieht seine Frames von AVISynth und AVISynth bezieht das von dem Frameserver den du in Vegas verwendest. Und Vegas muss die angeforderten Frames A) dekodieren, B) und verarbeiten.


    Sprich der x264 Encoder würde gerne schneller arbeiten, kann er aber nicht, solange die Frames nicht schnell genug ankommen.
    Und all das was vor dem Encoder abläuft, sprich das Rendering und das Durchschleusen der Frames ist dann halt dein Trichter.


    Da kannste noch so viele Kerne nutzen, es wird nicht schneller werden, wenn die anderen Dinge die vor dem Encoder sind nicht auch schneller werden. ;D

    Der FICV Codec den es halt bei Mirillis Action z.B. gibt ist ein Verlust Codec. !!! - Kein Verlustfreier- !!!


    FICV - Fast Intra Compression Video


    Intra - Schlüsselbilder / Keyframe


    Der Codec basiert wie MJPEG auch auf Verlust Kompression wo es nur vollwertige I-Frames gibt. Die Bilder / Qualität sind vom Codec abhängig. z.B. sind MJPEG Videos auch Verlust Videos, wo am Ende in der Aufnahme selbst schon Artefakte gibt. Jedoch kann man den MJPEG zwecks Qualität ja einstellen. Aber selbst eine 100% Qualitätsangabe heißt nicht das das Video Verlustfrei ist. Es existiert immer noch die JPEG spezifischen Kompressionen.
    Gleiche Herangehensweise macht der FICV auch.


    Eine zweite Verarbeitung kann das schon recht schnell ruinieren.


    Soll heißen... der FICV kann wie MJPEG halt auch bei unterschiedlichen komplexen Materialien der Frames eines Videos unterschiedlich reagieren. z.B. in Form von unzureichender Bitrate. Ist die Bitrate gecapt bei einer bestimmten Menge wird jedes noch so komplexe Video in Artefakte und Schlieren sich präsentieren.


    Was die Sache noch schlimmer machen kann ist das nochmalige Enkodieren dieser Videos. Und spätestens Youtube wird bei sehr komplexen Material dir einen Strich durch die Rechnung machen.



    @De-M-oN hatte ja schon oft gesagt in letzter Zeit das Youtube die Bitrate auf sämtlichen Stufen gesenkt hat. Das erhöht natürlich die Wahrscheinlichkeit das komplexe Frames eines Videos dann in Artefakte oder Schlieren sich zeigen.


    Und zwecks FICV hatten wir im Forum auch schon einen Test gemacht mit komplexen Material. FICV hat da leider verloren, weil es zu viele Schlieren und Artefakte bei der Aufnahme schon aufwies gegenüber einem Lossless Codec wie UTVideo / Fraps.
    Wenn einer den Thread noch mal finden sollte im Archiv, kann er diesen gerne hier auch noch mal verlinken. ^^

    Das wird nicht der min wert sein. Die Angaben sind eig. bei jedem Programm die max gop länge.

    Eigentlich der min. Wert ab wann das Video bei der dieser IDR Angabe refreshed werden soll.


    Das kann auch ein P- oder B- Frame sein in diesem Falle. Dafür ist diese Funktion halt.


    Die GOP kann trotzdem länger oder kürzer sein hier.


    Bei MeGUI kann man das auch machen, aber dort gibst du bewusst eine GOP Länge vor und wo sich dann min und max ein I-Frame als Refresh Punkt sich befinden soll.


    Bei IDR-Frames funktioniert das ein wenig anders. Ein IDR-Frame kann ein I-Frame sein, ein P- oder gar ein B-Frame was dann just diesem Moment refreshed wird. Und das gibst du bei OBS mit dieser Keyframe Angabe an sich an.

    Aber bringt das auch was, wenn man das Video nach dem aufnehmen noch schneidet, weil beim rendern ja auch oft eine Konstante Bitrate genutzt wird.

    Bei OBS oder einem Schnittprogramm?


    In der Regel wird nirgends eine konstante Bitrate verwendet. Viele Programme und Codecs möchten nicht Umsonst mit VBR lieber hantieren. VBR hat nix mit Schneiden zu tun.


    VBR musste dir so vorstellen:
    Wenn du 100 Frames z.B. hast wo nur Schwarz ist, ist es denn Effizient diese mit z.B. 15Mbit zu speichern oder würde dir ein Minimun von 50kbit/s reichen? Beides hat die gleiche Qualität.


    Die nächsten 100 Frames sind lauter kleiner bunte Pixel. Sehr schlecht zu komprimieren. Ist es Effizient mit 15Mbit aufzunehmen oder möchtest du nicht lieber eine saubere Qualität haben, weil du nicht weißt welche Bitrate notwendig ist?


    Und dann beginnt der Clou.
    100 Frames haben ca. 50kbit/s und 100 Frames ca. bis 40Mbit/s


    Die gehören aber zusammen und ergeben ein Video. Das ist dann VBR.
    Die Bilder, also Frames sind dabei immer noch Top.


    Anders bei CBR und ner fixen Bitrate.
    Bei CBR haste eine durchgehend gleichbleibende Bitrate von z.B. euren 15Mbit halt.
    Selbst die 100 Frames mit einer schwarzen Scene werden mit 15Mbit ausgestattet. Es entsteht hier zwars kein Verlust, aber man pump diese Frames unnötig mit Speicher zu.


    Bei den nächsten 100 bunten Pixel Frames reichen die 15Mbit nicht mehr aus. Resultat: Artefakte bzw. Schlieren.


    Ergebnis: Unsauber.



    Wie gesagt CBR und fixe Bitraten bei Streaming ist das ok und sogar ein muss. Weil nur so kann man das sehr konkret regulieren. Aber bei lokalen Aufnahmen für YT z.B. ist das Stuss. Gerade fixe Bitraten sind von Spiel zu Spiel ein Ratespiel.
    Weil du weißt ja selbst nicht welche Frames aus dem Spiel sind nun Komplex und brauchen massig Bitrate oder welche sind total Komplexarm. Wenn das z.B. nur ein Comic Game ist wie z.B. Monkey Island 3, dann wird die max. zu erreichende Bitrate recht niedrig sein noch. Aber bei Spielen mit zig Vegetation und und und wie z.B. Crysis 1 - 3 oder Arma oder Minecraft, wirst schnell mal über die 15Mbit kommen. Und dann gibt es Artefakte bzw. Schlieren.


    Und ganz böse ist es wenn das schon die Aufnahme selbst betrifft. Weil Lossy -> Lossy = Noch mehr Lossy.


    Bei Aufnahmen empfehlen wir ja auch oft das man im Spiel interne Motion Blur Effekte mit nutzen sollte oder gar wenn man die Videos noch skaliert im Nachhinein ein passenden Skalierer nimmt wie Spline36 z.B.


    Sinn dahinter ist A) das auf YT bei höherer Auflösung mehr Bitrate für das Video freigegeben wird. Mehr Bitrate = mehr Qualität, aufgrund das das Video ja jetzt etwas verschmierter gemacht wurde durch Motion Blur oder einer Skalierung. Ist aber dennoch scharf genug.


    Und B) Wenn das Video mit einer VBR hochgeladen wird, müsst ihr logischerweise weniger hochladen.


    In der Regel verwendet jedes Schnittprogramm bei einem Encoder Standardmäßig VBR. Jedenfalls wird das bevorzugt verwendet.
    Wenn du mal DVDs oder Live-Streaming betreiben willst, dann musst du halt vllt. etwas anders denken noch.


    Bei DVDs kommen z.B. Fragen wie: Kann der jeweilige Hardware Player die DVDs korrekt abspielen mit VBR oder muss es eine CBR sein.


    Und bitte nicht verwechselt das Ganze.
    VBR und CBR sind Bitratenflusssteuerungs Angaben
    VFR und CFR sind Frameratensteuerungs Angaben


    Mit VBR und CFR nimmt man in der Regel auf.


    Shadowplay nimmt z.B. in VBR und VFR auf.


    Fraps nimmt in VBR und CFR auf


    MSI Afterburner auch in VBR und CFR


    In OBS kann man es Einstellen ob CBR oder VBR und VFR oder CFR.


    Bei DxTory geht es wieder normal mit VBR und CFR.



    Bei VFR sei nur gesagt das das meist die Eigenschaft für ein Video ist wo Videos dank dieser variablen Framerate einfach asynchron werden können im Schnittprogramm.


    Das halt nicht durcheinander bringen. ^^

    Aber ich verstehe nicht, warum dann trotzdem meistens die Konstante Bitrate empfohlen wird, wenn man sich Tutorials für OBS Einstellungen ansieht oder durchliest.

    Die sind für Streaming interessant. Um einen gleichmäßigen Upload auf einem Streamportal zu gewährleisten. Weil wenn das Schwankt kommt das bei Zuschauern wie auf Twitch und Co. zu Qualitätsschwankungen. Äußert sich dann beim Zuschauer durch Stocken der Videos und Artefaktbildung. Einfach weil der Upload nicht regelmäßig verläuft.
    Dafür ist CBR dann interessant und auch eine fixe Bitrate. Damit man halt einen regulierten einheitlichen Upload auf ein Streamportal hinbekommt.


    Damit minimiert man auf einem Streamportal Standbilder und Qualitätsschwankungen. Davon profitiert dann der Zuschauer. Nicht der Uploader. ^^
    Für den Uploader selbst ist sowas halt ineffizient.


    Weil ein VBR Video das mit CRF z.B. aufgenommen wurde kleiner ist und schneller hochgeladen ist. Das funktioniert halt nur nicht bei Live-Streaming wie gesagt. Das ist noch mal ne ganz andere Schiene dann.

    Schon gar nicht mit so'ner kurzen GOP Länge von 1sek.

    Hat er das geschrieben? Dachte nur die Keyframes sind auf 1sek eingestellt.
    1sek ist ok. Das entspricht bei einem 60 FPS Video halt exakt 60 Frames. Damit stimmt der minimal Wert. Das wird ja mit dem Keyframe-Intervall bestimmt.
    Entweder die entsprechende Framezahl für 1sek angeben, falls Frameangaben verlangt werden wie bei MeGUI z.B.
    Oder die Zeit wie bei OBS dann halt. Dann ist 1sek halt richtig.



    Das andere was er sagt ist leider nicht nachvollziehbar. Sofern ich das so mache werden die Files unregelmäßig riesig durch den CBR Fluss. Und dank der fixen Bitrate habe ich generell vereinzelt erhöhte Artefaktbildung. Da ist mir halt VFR und ein CRF bzw. QP 1 oder 0 viel lieber. Die sind wenigstens Artefaktfrei.
    Bei seinem Video sehe ich mehr Artefakte als alles andere. Ein Teil wird schon durch YT kommen, aber so wie das aussieht kommt der andere Teil von der Aufnahme dann.


    Aber... sofern er damit zufrieden ist, soll es uns nicht weiter stören. Nur es ist halt falsch das CBR und fixe Bitraten besser sind. Sie ineffizient. Gerade bei sowas. Und erst recht bei solchen Ego-Shootern.

    Mal als Rechenaufgabe für Fixe Bitraten:


    Bitraten kann man nicht pauschal vorher sagen wie viel genug sind. Hinzu kommen auch noch einige Kompressionsalgorithmen für H264 hinzu die das Ganze noch etwas weiter reduzieren.


    Pauschal kann man aber eine Schätzung abgeben wie viel Bitrate maximal verbraucht werden könnte für eine Aufnahme.


    z.B. man nimmt in 1080p60 auf bei einem Seitenverhältnis von 16:9 und den Farbraum YV12. Wie viel Bitrate wird benötigt?


    geg:
    60 Frames in 1sek
    Auflösung: 1920x1080
    YV12 = 12bpp



    1920px * 1080px * 60 Frames * 12bpp = 1492992000 Bit


    Das entspricht die max. Dateigröße für 1sek Aufnahme, wenn 0 Verlust und 0 Kompressionen vorhanden sind. Sprich absoluter RAW Zustand.


    Das sind umgerechnet:


    1492992000 Bit / 8 (byte) / 1024 (kb) / 1024 (mb) = ~177,98 MB


    Das für eine Sekunde. Heißt also, da wir ja schon für eine Sekunde die Bitmenge haben das es genau 1492992 kbit/s im Durchschnitt brauch an Bitrate.


    Das heißt das diese 1492992 kbit/s der maximal zu erreichende Höstzustand bei dem Video wäre, wenn das Video A) total Komplex wäre, B) keine Kompressionen vorhanden sind.


    Mit Kompression wird es noch weit darunter liegen. Aber fixe 15Mbit sind weder gut, noch sind sie Schlecht. Fixe Bitraten kann man einfach nur nicht einschätzen. Bei einer Aufnahme kann es zuviel sein und verbraucht daher unnötig Speicher. Bei einer komplexen Aufnahme können die 15Mbit aber auch schon wieder zu wenig sein und es bilden sich Artefakte.


    Da das halt keiner einschätzen kann und es auch keiner will, sollte daher auch konstante Qualität umschalten bei Aufnahmen mit einer variablen Bitrate. Weil nur so wird die Aufnahme zwecks Qualität und Dateigröße optimal ausgenutzt.


    Umsonst sagen wir euch das nicht. ;D

    Rate Control CBR, Bitrate 15000

    VBR + CRF 18 - Sehr hohe Qualität


    ODER


    VBR + QP 0 - Verlustfrei


    ODER


    VBR + QP 1 - Fast Verlustfrei


    VBR sorgt dafür das du das du in Standphasen beim Filmen nicht so viel Speicherplatz verschwendest. Das wird halt besser ausgenutzt. Bei CBR wird massiv nur eine feste Bitrate durchgehend verwendet was suboptimal ist.


    VBR als auch CBR haben auch rein gar nix mit Artefakten am Hut. Weil die dienen nur zur Bitratenkontrolle.


    Die Bitrate stellt mit anderen Worten die Qualität dar. Je höher desto besser.
    Da aber kein Mensch weiß wie viel Bitrate ein Video benötigt ist es recht Unlogisch eine anzugeben. Weil A) hast du keine Ahnung wie viel Bitrate Optimal wären für dein Video und B) kannst du die Bitrate auch fälschlicherweise über den Maximalpunkt hinaus angeben. Oder halt auch zu wenig. Resultate sind dann entweder zu große Dateien, aufgrund das die Angabe zu groß war, oder zu klein. Und wenn es zu klein ist, wird das Belohnt mit Artefakten.


    Wenn man DVDs oder BluRays etc. pp. erstellt, dann muss man die Bitrate angeben, weil diese ein Maximum nur erlauben bei einer bestimmten Auflösung und FPS. Wenn noch Platz auf der DVD ist, wird meist sogar noch mehr Bitrate als nötig verwendet.


    Bei Aufnahmen aber eine fixe Bitrate anzugeben ist Suboptimal, weil wie gesagt kannst du das Video weder einschätzen wie viel es für die optimale Qualität benötigt oder stellst es zu hoch ein und verbratest dir wie schon bei VBR massig Speicherplatz. Und das ist ebenfalls Suboptimal.


    Bei CRF wird die Bitrate entsprechend einer gleichbleibenden Qualität der Frames ermittelt. Um das Perfekt hinzubekommen freut sich CRF natürlich über VBR.


    QP 0 ist der Verlustfreie Zustand für Bitraten. Das heißt das mit der max. mögliche Bitrate (die ist bei jeder Aufnahme unterschiedlich, daher Variable ;D) das Video ausstattet. Dazu hat man gleichzeitig auch noch Speicherplatz gespart oder vermehrt. Einfach aufgrund das die Aufnahme an diesen Frame Positionen mehr oder weniger Bitrate verwenden musste.



    Richtige Lossless Codecs verfahren übrigens genauso wie eben beschrieben. Fraps, MagicYUV, UTVideo, usw.
    Die Videos werden mit einer max. Bitrate aufgenommen. Die unterscheidet sich immer von Video zu Video. aufgrund das Frames halt unterschiedlich komprimiert werden konnten und somit unterschiedlich viel Platz weg nehmen. Weil das ganze Variable halt ist wird jeder Lossless Codec mit VBR betrieben. Egal wo.


    CBR wird eigentlich nur bei Streaming genutzt, genauso wie fixe Bitraten. Halt für Twitch und Co.



    Ich habe alles gemacht was du geschrieben hast, und trotzdem ist die CPU Auslastung bei 30% nur für OBS trotz I5 7600K

    Keine Ahnung was du alles getätigt hast und wie deine Einstellungen jetzt aussehen. Weil ich hatte dir ja mehrere Optionen genannt zum Aufnehmen. Daher weiß ich grad nicht was du alles getan hast. ^^

    Sagt mir aber bitte bescheid wenn ihr so bei 720p25 oder 720p15 angekommen seid. Damit man euch bewusst als Youtuber umgehen kann. ^^


    Für Handys reicht schon 480p als Auflösung. Sofern wir von 6 Zoll sprechen. Müssten nach Adam Riese 80dpi sein. Und das reicht an sich schon vollstens aus.
    Wenn ihr also meint das ihr eh nur Handy User habt, könnt ihr gerne bei 480p bleiben.

    OBS Übergibt 444 wenn man das in den Video settings einstellt.
    bei nv12 yuv420 und !! RGB !! wird 420 übergeben - warum bei RGB auch 420 gemacht wird ist mir ein Rätsel - vielleicht ein Bug, aber die OBS Entwickler haben da nicht so den Fokus drauf :).

    RGB wird dann zu 420 gemacht, wenn der jeweilige Codec den Farbraum nicht unterstützt.


    z.B. kann H264 kein RGB als Farbraum erkennen. H264 höster Farbraum ist YUV444 alias YV24.


    Um Komplikationen zu vermeiden geht OBS mit dem Farbraum auf Standard YV12 zurück und übergibt dies an den Encoder.


    Und jein zum ersten Satz aus dem Zitat von dir. OBS verfährt hinsichtlich NVenc zwecks Farbräume etwas anders.
    Du kannst zwars YV24 oder sonstwas auswählen, wird aber in der Regel wieder auf YV12 zurück reflektiert, sofern die Programmierer gedacht haben das NVenc nur mit NV12 arbeiten muss.


    Haben andere Aufnahmeprogramme auch schon drauf gehabt. OBS wäre damit dann kein Einzelfall.


    Dann hast du nämlich in deiner YV24 Aufnahme ein YV12 Bild Inhalt. Und das ist Ineffizient. Das verbraucht nämlich unnötig Speicherplatz und andere Ressource. Weil das hätte man dann auch gleich in YV12 speichern können, statt YV24.


    Sprich YV24 kannst du zwars einstellen, aber mit was gepiped wird zwischen dem Aufnahmeprogramm und den Encoder kannst du nicht beeinflussen direkt, wenn das vom Programmierer fest vordefiniert wurde für bestimmte Codecs. Das ist der Clou dahinter.

    Dann war ich die ganze Zeit auf einem falschen Weg! Ich wollte tatsächlich Intraframes. Da ich schneiden und neu rendern werde, verliere ich an der Stelle schon Qualität und dann durch YouTube ein zweites mal. Wenigstens die Aufnahme sollte so hochwertig wie möglich sein (sollte Rohmaterial eigentlich immer).

    Jein. Also wenn du mit H264 wirklich Lossless aufnimmst, dann sind das in der Tat Interframes. Sprich ab und an sind dann halt mal B-Frames mit drin. Aber generell werden Keyframes geschrieben.


    Wenn du die Qualität bei der Aufnahme jedoch Notgedrungen wegen deiner Schnittprogramme drosseln musst, damit er das Ganze in ein normales High Profil speichert, dann sind mehr Referenzframes vertreten.


    Die Keyframe Intervall Angabe ist dann auch von Bedeutung, wenn du den Lossless Modus nicht aktiv hast. Weil in jedem Keyframe Intervall ist min. 1 Keyframe vertreten. Ist er alle Sekunde bei einem 60 FPS Video, dann hast du pro Sekunde jeweils 1 Keyframe, sprich I-Frame. Der Rest der GOP besteht dann auch P- und B-Frames.



    Du scheinst ja auch in Punkto Schnittprogramme gut unterwegs zu sein zuvor habe ich immer ein wenig in Magix "rumgespielt" und mir gestern Abend noch eine Testversion von TMPEnc runtergeladen. Kann man sich dieses Programm für die Zukunft bedenkenlos kaufen? Welche Empfehlungen kannst du sonst noch aussprechen?

    TMPEnc ist schon ganz gut, wenn du z.B. mit deinen H264 Aufnahmematerial hantierst.


    Besser, schneller und Sorgenloser kommst du aber mit Aufnahme Codecs zurecht wie MagicYUV, UTVideo, Lagarith, Fraps, MPNG, usw.
    Weil das sind Verlustfreie Intraframe Speicherungen die in einen AVI Container gehen. Da hängt nicht gleich der ganze H264 Kompressions-Aufbau mit dran. Wie gesagt: H264 ist vor allem für Lossy gedacht. Verlustfrei ist nur ein Feature das es nebenbei kann.


    Und diese Verlustfreien Codecs wie eben genannt kann jedes Schnittprogramm mit umgehen, sofern der Codec installiert ist.


    FFmpeg kann damit auch umgehen, weshalb FFmpeg auch bei TMPenc genutzt wird. Also ist das schon ein sehr gutes Tool.


    Aber wenn du halt deine anderen Schnittprogramme dazu animieren willst mit hochwertigen Material umgehen zu können, musst du deinen Aufnahmecodec halt ändern. Statt NVenc oder x264 halt die genannten nutzen.
    x264 als Ausgabe Encoder im Schnittprogramm dann nutzen, um später den Bestmöglichen Gewinn für das Video raus zu holen. Und schon ist alles schick.


    Du kannst aber auch den SSM + MeGUI nutzen. Der kann via AVISynth und dem Plugin FFMS2 auch deine H264 Lossless Videos einlesen und verarbeiten. Aber ich denke das du mehr machen willst, als das was dir der SSM zur Verfügung stellt.


    Also als Fazit: Du musst entsprechend überlegen welchen Codec du nutzen willst und welcher in deinen Programmen supported wird.
    Weil es ist etwas Fail mit einem Codec aufzunehmen, von den man meint der ist Top, und hat aber hinterher mehr Arbeit das Ganze wieder gerade zu bügeln. Immerhin ist es auch eine Frage des Zeitaufwands, das man hätte woanders besser investieren können.



    Bis ich mir einen zweiten PC zusammengespart habe, werde ich also über NVEnc mit 99% in MP4 aufzeichnen und mit dem zweiten Rechner dann Gas geben und die CPU mit MagicYUV arbeiten lassen

    Alles hat seine Positiven, als auch Negativen Seiten.
    Aber ich würde niemals mit H264 aufnehmen wollen. Selbst wenn es über die GPU wie bei NVenc läuft.
    Einfach aus dem Grund schon nicht, weil H264 für Aufnahmen einfach nix taugt.


    Da gibt es definitiv besseres.


    Es ist halt der altbekannte Irrglaube das NVenc besser ist.
    Ja, es ist besser, weil er über die GPU aufnimmt.


    Und nein, das NVenc in OBS, Bandicam, und haste nicht gesehen ist nicht das gleiche Verhalten wie das NVenc wie bei Shadowplay.
    Shadowplay spielt ganz andere Taktiken für Aufnahmen aus. OBS, Bandicam und Co. nehmen immer noch regulär auf wie jedes Aufnahmeprogramm auch.
    Die meisten schnüren NVenc sogar noch indem sie als Input immer YV12 zusenden. Das heißt das man mit NVenc zwars in YV24 oder YV16 aufnehmen kann, aber eigentlich der Inhalt immernoch YV12 ist, weil vllt. bei der Programmierung zweifelhaft versucht wurde NV12 reinzudrücken.


    Das ist von den Aufnahmeprogrammen schon Fail.


    z.B. kann Mirillis Action nur YV12 Speicherungen machen. Egal was man für ein Farbraum auswählt. Es wird immer in YV12 an den Encoder weiter gegeben.
    Sprich wenn man YV24 oder YV16 aufnehmen will, dann greift das Aufnahmeprogramm das RGB32 Bild ab, wandelt es in YV12 um und schickt es dem Encoder, und der Encoder hat als Befehl erhalten das er es in YV24 aufnehmen soll z.B..
    Letzeres wäre dann halt Sinnfrei und man ist dafür selbst verantwortlich auch noch. ^^ Weil man hat mehr Speicherplatz verschwendet als das Video gebraucht hätte. Weil es war ohnehin vom Aufnahmeprogramm ein YV12 Video. ^^


    OBS macht das z.B. mit NVenc.


    Wie Bandicam da verfährt weiß ich grad nicht.



    Und NVenc hat noch ein kleines Manko. Bei NVenc ist die Grafikkarte entscheidend. Letztens war auch ein User hier im Forum der hat eine NVIDIA GTX660 gehabt. Sprich NVenc Erste Generation. Die kann kein Lossless. Und er wollte in Lossless aufnehmen. Ging nicht. Ging einfach nicht. ^^ Erst ab der zweiten Generation geht das Tadellos.


    Für hohe Auflösungen, FPS und Lossless muss schon die dritte oder gar vierte Generation von NVIDIA Grafikkarten die NVenc unterstützen herhalten um halt die Bestmögliche Performance zu erzielen.


    Das heißt im Klartext das es bei diesem GPU Encoder noch nicht mal eine klare Konfiguration gibt was bei einem gut läuft. Der eine kommt mit Einstellung XYZ klar, bei dem anderen schmiert es ab, ruckelt oder nimmt gar nicht erst auf.


    Das kann dir bei MagicYUV oder UTVideo schon gar nicht passieren.
    Die laufen auf CPU Basis und sind daher recht zuverlässig. Da kannste auch eine Uralte Geforce 2MX oder eine Radeon verbaut haben. Solange du genug CPU hast, kannst du Problemlos mit so einem Codec auf jedem Rechner was aufnehmen.


    Darum nutze ich sie Bevorzugt am liebsten. Sie sind einfach zuverlässiger und sind überall anwendbar.


    Das nur mal dazu ^^

    Unsere NVEnc lossless Files können von keiner Schnittsoftware gelesen werden. Entweder kommt beim Importieren eine Fehlermeldung, dass das Videoformat nicht verstanden wird oder es wird importiert (TMPEnc) und spielt bei der Wiedergabe direkt in der Software nur den Ton. Im Videofeld steht dann "kein Video enthalten".


    Gibt es da bekannte Probleme oder Settings, die gesetzt werden MÜSSEN?

    Das Problem ist bekannt.
    Die Handelsüblichen Schnittprogramme wie z.B. Premiere, Vegas, Magix und Co. können H264 Material was Lossless kodiert wurde nicht einlesen, aufgrund des nicht unterstützten High444 Profiles.


    Selbst beim High422 stellen sich viele bekannte Schnittprogramme recht dämlich an diese Videos dann fachgerecht zu laden.
    Diese Programme sind nur für Videos mit Low Profiles gedacht. Sprich Baseline, Extended, Main und High und eventuell auch noch High10.
    High422 und High444 werden dann nicht supportet.
    Mehr dazu siehe: https://de.wikipedia.org/wiki/H.264#Profile


    Das High444 Profile baut weiter auf dem High422 Profile auf und ist z.B. Voraussetzung für:

    • Lossless
    • 4:4:4 Farbraum wie z.B. YV24
    • 9 bis 12Bit Farbtiefe
    • Exakte Rasterfarbenumwandlung

    Das High422 Profile kann...

    • zusätzlich zum High10 Profile ein Video mit dem Farbraum 4:2:2 speichern. z.B. YUY2 oder YV16

    Ein höheres Profil einer H264 Datei kann alle die darunter befindlichen Profil-Features verarbeiten.


    Dinge wie ASO, FMO, RS oder Daten Partitionierung sind für Aufnahmen, Youtube oder sonstiges recht uninteressant. Das sind Features aus alten Steinzeittagen. Wird noch nicht mal mehr für BluRays verwendet mehr. Also merken Baseline und Extended als auch Main Profile braucht ihr erst gar nicht mit hantieren. Die sind Out to Date.
    Erst ab einem High Profile aufwärts kann man mit Videos bzw. in Videos einige interessante Features nutzen.


    Freeware Programme wie z.B. FFmpeg, SSM + MeGUI über FFMS2 oder L-Smash, XMedia Recode, oder z.B. auch TMPgenc sind in der Lage recht kostengünstig diese High422 oder High444 Profile von H264 zu lesen und zu verarbeiten.


    teure Schnittprogramme legen mehr Wert auf andere Dinge, als die Unterstützung mehrerer Video Codecs und dessen Profile.
    Einfach aus dem Grund, weil sie von Vornherein sagen das Farbtiefen von 9 - 12 Bit irrelevant sind und 8Bit Tiefe ausreicht. Auch eine Lossless Speicherung mit einem für Lossy ausgerichteten Codec ist recht Sinnfrei. Weil dafür gibt es bessere Codecs wie z.B. MagicYUV oder UTVideo die darauf besser spezialisiert sind.


    Wenn ein H264 Codec wie z.B. x264 oder NVenc ein Video in Lossless speichern tuen sie dies mitunter all ihrer Kompressionsverfahren. Bedeutet das die Decodierung oftmals Rechenintensiver sind als wenn man ein regulären Lossless Codec nutzt. Dazu kommt noch das H264 Lossless in Interframes speichert, während Codecs wie MagicYUV oder UTVideo in Intraframes speichert.
    Sprich letzteres speichert nur in Keyframes, also vollwertige Bilder, während Interframes hin und wieder ein Referenzbild noch dazwischen speichern.


    Technisch gesehen ist es also nicht zu 100% Lossless was H264 Codecs unter Lossless verstehen. Wohlgemerkt: Technisch.


    Außerdem bieten H264 Aufnahmen für die User oftmals die meisten Seelensorgen bei den Aufnahmen.




    Zur Frage aber:
    Wenn du den Quantizer von NVenc auf 1 stellen könntest, also Qualität so 99%, dann ist es FAST Lossless und es wird in einem entsprechenden High Profile gespeichert. Ob nun High oder High10 sei mal dahingestellt. Aber deine Schnittsoftware wird das Video dann entsprechend verarbeiten können. Nimmst also Lossy auf und gut ist.


    Dazu kommt noch: Einen Keyframeintervall von 1
    Was ist diese 1 nun? Eine Frameangabe oder eine Zeitangabe?


    Bei einem 60 FPS Video sollte der Keyframe-Intervall 60 Frames min. betragen. Sollte es sich über eine Frameangabe handeln.


    Ist es eine Zeitangabe, dann ist die 1 korrekt.
    Denn in 1 Sek bei einem 60 FPS Video beträgt der Keyframeintervall die gleiche Menge wie die FPS Angabe. Nämlich 60 Frames.


    Kann ich so aus dem Bild nicht mal ableiten was es für eine Angabe nun ist.




    Und BITTE.... Ein H264 Video NIEMALS in ein AVI Container schreiben. Sonst streiken erst recht viele Programme bei der richtigen Einlesung der Dateien.
    Statt PCM bei Audio, kann man auch gleich AAC nutzen bei 320kbit/s. Den Unterschied hört kein Mensch mehr.


    Es sei denn User XYZ hat Ultraschallohren und seine Sinne sind so hoch das er einzelne Samples hört das diese Verlust haben. <- Das war jetzt Ironisch gemeint. ^^


    Also:
    H264 Video + AAC Audio. Alles entsprechend konfigurieren wie beschrieben und dann sollte das auch jedes Programm laden können.
    Müsst aber dafür halt ein Tüpfelchen Verlust hinnehmen. Weil ja halt diese bekannten hochwertigen Schnittprogramme wie gesagt zu blöd sind mit den Codec Profilen von H264 entsprechend korrekt zu verfahren und lieber verweigern diese zu akzeptieren.


    Also H264 mit NVenc mit einer 99% Qualität (kein Lossless), damit das in ein High Profile kommt, Audio in AAC mit 320kbit/s aufnehmen am besten (Ist auch Lossy, aber kein akustischer hörbarer Unterschied zu PCM) und das ganze bitte in MP4 speichern und nicht in AVI. Denn MP4 ist für H264 halt geeignet. AVI nicht.


    PS:
    Auch wenn es zwischen den Farbräumen NV12 und YV12 keinen Technischen und Optischen Verlust gibt, so ist dennoch der Aufbau ein anderer. Das heißt das es durchaus sein kann das Programme mit dem NV12 Farbraum nicht klar kommen, aber mit dem YV12 Farbraum. In diesem Falle macht dann die Software Probleme bei der Verarbeitung von NV12. Sowas gibt es dann halt auch zu beachten.


    Für den aller äußersten Notfall kann man das H264 Video mit samt zugehörigen Audio Spuren in ein Verlustfreies Material umwandeln.
    z.B. mit FFmpeg das Ganze in UTVideo + PCM Sound in AVI. Das verstehen alle Schnittprogramme zu verarbeiten dann.


    Aber dann kann man auch gleich in MagicYUV oder UTVideo aufnehmen und spart sich diesen Vorgang. ^^
    Letzters hat mehr Gewinn.


    Aber das muss jeder für sich dann entscheiden mit was er zufrieden ist und ob er mit den Problemen lieber kämpfen will.


    Zugleich das H264 auch gern mal bei Unachtsamkeit bei der Konfiguration des Codecs in VFR speichert. Oftmals sind die User dann angepisst das ihre Videos asynchron sind. Dann hilft meist nur noch ein VFR -> CFR Wandler.
    Inwieweit neue Schnittprogramme da sind ist auch noch fragwürdig.
    Man kann Glück haben mit VFR, man kann aber auch Pech haben. Das ist dann wie ein Lotterie Spiel ;D

    Ok. FFmpeg hat die FPS nicht automatisch erkannt.


    Kein Ding. Dann musste das bei FFmpeg beim Ummuxen halt erzwingen.


    ffmpeg.exe -r 60/1 "-i "A:\Aufnahme\2017-07-01 21-28-17.mkv" -c:v copy -c:a copy "A:\Aufnahme\2017-07-01 21-28-17.AVI"


    Beachte das -r vor der Input Quelle steht und somit das Video erzwingt den Input als 60 FPS Video zu erkennen.


    Wenn du das Getan hast und das Video erzeugt hast, überprüfe bitte ob das Video A) 60 FPS hat und B) ob das vom Abspielen her auch OK ist alles.



    Die hohe FPS Rate ging aus der MKV hervor. Die MKV arbeitet im Gegensatz zum AVI Container mit Zeitstempel. Sprich der Aufbau ist ein wenig anders. Geht das durcheinander hast du den Salat. ^^
    Das ist z.B. ein Merkmal warum UTVideo nicht in ein MKV Container gehört. Viele Programme kommen damit nicht mehr richtig klar das richtig wieder zu entflechten.


    Edit:
    Beobachte bitte mal bei FFmpeg selbst, mit welchen Meldungen er die Streams einlesen tut. Steht in einer Zeile alles zusammen mit Auflösung, Farbraum, FPS, usw. Sollte mit 0,0 oder 0,1 gekennzeichnet sein. Audio müsste dann eine Nummer Höher sein mit 0,1 oder 0,2. Da sollte dann was mit PCM drin stehen.


    Im Verzwicktesten Fall, wenn das wirklich nicht so will, kannste es noch mal Reencodieren wie folgt:
    ffmpeg.exe "-i "A:\Aufnahme\2017-07-01 21-28-17.mkv" -c:v utvideo -c:a pcm_s16le "A:\Aufnahme\2017-07-01 21-28-17.AVI"


    Dann reencodiert er dir das noch mal.

    Ich muss mich entschuldigen. Ich hätte zuerst nach der Mediainfo fragen sollen. Eigentlich ist das immer das A und O das man die zuerst braucht, damit wir hier generell wissen mit was du für Videos da hantierst. Dann hätte man das sicherlich gestern schon gelöst gehabt. ^^

    Für Streaming ist CBR nicht verkehrt, aber für Normale Aufnahmen sollte VBR genommen werden.


    Und wer führt schon Aufnahmen auf die Windows Partition / Laufwerk durch? So blöd möchte ich mal sein ^^ Da ist doch der Rest an Luft für die Aufnahme verpufft.


    Größtes Manko aber: es wird Bitraten Abhängig aufgenommen.
    Ist also kein Wunder warum in gewissen Zeitintervallen euch die CPU hoch schnallt. Das muss besser reguliert werden. Immerhin wird der Encoder hier gerade gezwungen 40Mbit auf Kompressionsbasis zu verwursten und ihr wundert euch dann warum die CPU ne hohe Auslastung hat? Fail. ^^ Einfach nur Fail xD


    Gebt in der x264 Option mal folgendes ein "-CRF 23"


    Das ist der Parameter für den Modus Konstante Qualität der mittels einem Faktor angegeben wird (Constant Rate Factor).
    23 ist ein Standardwert.
    Es wird danach die eingetragene Bitrate komplett ignoriert.


    Für Verlustfreie Aufnahme würde man "-QP 0" eingeben oder wenn ihr es noch editieren wollt und ne schlechte Schnittsoftware habt, dann gebt dort ein "-QP 1"
    Dann nimmt er mit einen Quantizer von 1 auf.


    Wenn die Bitrate auf VBR läuft, wird sie variieren was eurer Aufnahme zugute kommt.


    Weil für ein Standbild 40Mbit zu verschleudern bei CBR ist kompletter Schwachsinn.


    Die CRF Angabe oder auch QP Angabe wird das weitaus besser regeln mit der Bitrate, als das ihr die manuell selbst definieren könnt. Weil Bitratenangaben sind wirklich nur interessant für Leute die Streamen wollen, damit sie einen Durchschnitt von Geschwindigkeit und Qualität haben zu ihrer max. erlaubten Bitrate für ihre Streamportale.


    Und das Profil veryfast kann man so lassen, kann man aber auch auf Ultrafast stellen, damit die CPU gar nicht mehr großartig was zu tun bekommt. ;D


    Rat mal befolgen und schon wird das was werden.



    Noch besser sind Aufnahmen ohne x264. Weil x264 verbraucht für Aufnahmen am meisten CPU. Besser wäre z.B. auf einen GPU Encoder umzustellen wie z.B. VCE oder NVenc


    Oder man nimmt keine komplizierten Codecs und bedient sich an regulären Lossless Codecs wie UTVideo oder MagicYUV die weitaus schneller sind via CPU und diese kaum in Anspruch nehmen, da die kompletten Kompressionstechniken von H264 wegfallen würden. Was bleibt sind reguläre allgemein schnelle Kompressionstechniken.
    Programme dafür sind z.B. MSI Afterburner, DXTory, Fraps.
    Aber auch OBS kann via FFmpeg auf UTVideo zugreifen. Allerdings mit einigen Nachteilen gegenüber den anderen Programmen. z.B. ist dann nur noch eine Audiospur erlaubt. oder die Leistung fehlt, weil es über FFmpeg geht und das nicht richtig konfiguriert werden kann mittels OBS.


    Sind jetzt nur einige Ansätze zur Lösung und Optimierung.


    Ich denke bereits darüber nach auf Fraps zu wechseln und die 33 Euro zu berappen, allerdings weiß ich nicht, ob es damit wirklich besser geht...

    Tus nicht. Fraps wird seit Jahren nicht mehr gepflegt. Auch das es diverse kleinere Bugs noch mit sich führt.


    Bevor du so verzweifelt bist, probiere das kostenlose MSI Afterburner aus mit einem entsprechenden Lossless Codec wie MagicYUV oder UTVideo ODER du kaufst dir DXTory, das du ebenfalls mit unterschiedlichen Codecs füttern kannst und dazu auch noch 8 Audiokänäle glaube ich simultan während der Aufnahme mit aufnehmen lassen kannst. DxTory kostet ca. 30 € und hat halt mehr zu bieten als Fraps.
    Fraps kann halt nicht viel. Da ist selbst MSI Afterburner was kostenlos ist diesem überlegen.


    Fraps kaufen sich eigentlich nur Ahnungslose ;D Darum habe ich auch mal bessere Alternativen als das alte Tool vorgestellt. ^^ Nur so zur Orientierung.

    Mit der AVI gehst du wie gewohnt vor. Also MT wieder an, und ganz normal die AVI wieder in den SSM ziehen.


    Sprich so wie du im allerersten Post vorgegangen bist ohne irgendeine Änderung die wir so Mühselig durchgegangen sind.


    Weil die AVI wird im SSM mittels AVISource geladen.
    Die MKV wurde zuvor mit FFMS2 geladen. Und gerade weil in dieser MKV ein UTVideo drin gesteckt hat, hat dir auch das Skript an sich schon die Probleme bereitet.


    Da du jetzt aber das in AVI umgemuxt hast, sollte es jetzt keine Probleme mehr geben, wenn du den SSM ganz regulär wieder verwendest.


    Eine AVI wird nicht mittels FFMS2 oder L-Smash eingelesen. Und das ist auch gut so. ^^

    Du musst dich schon in der CMD im entsprechenden Verzeichnis befinden, damit das funktioniert. Siehe das Bild oben was ich dazu gepostet habe.


    In der CMD kannst du dich folgendermaßen durch dir Pfade und Laufwerke dich bewegen:
    C: - Auf Laufwerk C:\ wechseln. Einfach [Laufwerkbuchstabe]: eingeben
    CD Ordnername - Springe in den Ordner mit den Namen "Ordnername" rein
    CD .. - Springe aus den aktuellen Ordnernamen raus. Sprich eine Ebene zurück.
    DIR - Lässt dir den Inhalt im aktuellen befindlichen Ordner anzeigen.


    Damit navigierst du dich in den Unterpfad von MeGUI und in die Unterverzeichnisse Tools\ffmpeg\