Beiträge von Sagaras

    Ausser dass ich beim x.265 Encoder die CL Parameter "--numa-pools 24,24 --pmode --bframes 6" eingetragen habe, wurde sonst nichts in der Richtung verändert.

    Erkläre mir mal warum du das so eingetragen hast. ^^ Du musst dir ja dabei was gedacht haben ^^


    Bei Avisynth steht nur das Standard Zeug drin: "<input> <deinterlace> <crop> <resize> <denoise>"

    Genau eben diesen Skript. MeGUI wird auf deinem Rechner temporär ein AVISynth Skript erstellt haben. Genau dessen Inhalt wird gesucht. ^^
    Der ist relevant was mit deinem Video passiert.


    Und sofern du Audio auch bei Oneclick mit einfügst wird Audio unnötigerweise auch noch mal durchgejagt. Wobei ich nicht weiß wie DTS hier mit FFMS2 arbeitet. Hatte damit nämlich auch schon Probleme gehabt.

    Der Dateigrößenunterschied zwischen einem YUV420 und einem YUV444 Encode ist lächerlich gering.

    Wenn du möchtest, gebe ich der gerne ein oder zwei Videos wo das nicht der Fall ist und die Größe massiv unterschiedlich ist. Halt nicht nur ein paar MB, sondern da bewegt man sich dann schon im GB Bereich. Und das ist definitiv dann nicht 'lächerlich gering' ;D


    Encoding Talk beschäftigt sich mit Filmen wohlgemerkt. Filme sind meist allesamt im YV12 Farbraum. Und darauf baut auch Brother John auf.
    Sprich er hat gar kein echtes YUV 4:4:4, sondern bezieht sich immer auf Filme.


    Und dann... ist das auch klar: Ein YUV 4:2:0 -> YUV 4:4:4 ist das gleiche wie YUV 4:2:0
    Somit sind YUV 4:4:4 und YUV 4:2:0 identisch. Man hat dann halt den geringeren Farbraum in ein hören gesteckt ohne jeglichen Nutzen davon. Fazit: Die Dateigröße wird ähnlich, da der Inhalt sich schon gleicht. Und erreicht wird das dann durch die Kompression. Gleicher Informationsgehalt = gleiche Dateigröße. Egal in welchen Farbraum du es stecken tust ;D


    Wenn es total unkomplexes Material ist, dann ist ein YUV 4:4:4 sogar oftmals kleiner als ein YUV 4:2:0 Video.
    z.B. kann man das an Gameboy Spielen oder NES oder auch SNES nachweisen.


    bei einem komplexes Bild aber streust du weitaus mehr Feinheiten zu wo du das YUV 4:4:4 einfach nur aufblasen tust, während YUV 4:2:0 eindeutig kleiner ist.


    kannst es ja gerne selbst probieren:
    http://www.mediafire.com/file/…hfz1q/StressTest_Video.7z


    Das sind Stresstest Videos die mit AVISynth Skripten und Bildern erzeugt wurden.


    Test 1 ist ein Rauschtest mit unterschiedlichen Farben. Jeder Pixel hat eine unterschiedliche Farbe. Jeder Frame ist anders und das ganze läuft 5min. Alles RGB Quellen. 60 verschiedene Frames für Tests an 60 FPS Videos.
    Da kannste dich austoben ;D


    Und richtige Filme sind halt ein ganz anderes Gebiet als Spiele Videos. Spiele haben halt harte Kanten und sind oft wenn Vegetation oder sonstiges komplexes Zeug dargestellt werden muss recht weniger komprimierbar. Und da merkst du dann auch YV12 vs YV24. Weil dann bekommst du richtige gewaltige Unterschiede hin zwecks Dateigröße.


    YV12 ist gerade deswegen erfunden worden für Fernsehn und Co. weil man damit die Übertragungen nicht unnötig belastet damit. Dies gilt auch für DVDs, BluRays und Co. Das hat also schon sein Zweck.




    @Karmaalp
    Ich hab dir mal jetzt ein Video hochgeladen das den Unterschied zwischen einem hochgeladenem YV12 und einem hochgeladenem YV24 Video zeigt.


    Die Videos wurden in 2048x1152 hochgeladen und sind beide exakt gleich encodiert bis auf den Farbraum.
    Die Farbmatrix ist bei beiden identisch mit BT.709


    Hier nun der Vergleich: i420 vs i444
    http://screenshotcomparison.com/comparison/192352


    Hier noch mal die Videos:
    I420:


    I444:


    Der direkte Bildvergleich zeigt schon mal das bei einer niedrig eingestellten Auflösung von 720p schon Farbunterschiede auf.
    Erklärung: Beim Upload des I444 alias YUV 4:4:4 Farbraums sind mehr Infos erhalten geblieben, bei I420 alias YUV 4:2:0 nicht.

    Ich wirke meist den Farben entengen mit einer Farbkorrektur und fand die Ergebnisse immer recht gut.

    Farbkorrektur? Warum?
    Ist doch nur eine Frage des richtigen Umgang mit Farbbereich und Farbmatrix. Wenn du das richtig zu nutzen weißt, sehen die Videos auch so aus als wenn du sie gerade spielst.
    Da braucht man eigentlich nix entgegenwirken.


    Hast du zufällig ein Vergleichs Video der einzelnen zum Vergleich auf YouTube ?

    Leider nicht, weil das so ziemlich keinen bisher interessiert hat.


    Es gab zwars schon Vergleichs Videos, aber der der die gemacht hat ist nur von seinem Workflow ausgegangen. Und der war halt nicht sonderlich.

    Bei Methode 1 benutze ich SVRT (Power Director 14)
    und bei Nummer 2 Hardware-Codierung

    Kann ich leider noch nix mit anfangen.


    Ich kann dir aber definitiv schon sagen das wenn du beide Codecs gleicherweise Moderat einstellen würdest, beide Ergebnisse identisch wären.
    Was du aber definitiv nicht getan hast.


    Ein Vergleich funktioniert nur wenn du sie so genau wie möglich gleich moderat konfigurierst und da glaube ich nicht das du dies getan hast, da beide unterschiedliche Bitraten aufweisen tun.


    SVRT beschreibt nur ein intelligenten Algorithmus indem die eingelesenen Videos in deinem Projekt analysiert werden und beim Berechnen und Encodieren entschieden wird was berechnet werden muss und was sich nicht ändert. Kurz: Es sucht sich wie Wasser den geringsten und optimalsten Weg das Video so schnell wie möglich zu verarbeiten. Daher hast du dort auch den kürzesten Zeitverbrauch.


    Und dein Hardware Encoding... damit kann ich nix anfangen. Beschreib das mal genauer. Was für ein Hardware Encoding? CPU Encoder arbeiten auch mit Hardware ;D
    GPU Encoder auch.


    Ich befürchte das du selbst nicht so weißt was du da grad an Infos gibst? ^^
    Weil die sind immer noch ungenügend. Immerhin kann ich zwei Käsesorten kaufen. Nur der eine war größer und hat länger gehalten, weil vllt. ne teure Marke und der andere war kleiner und hat sich kürzer gehalten, weil es schon länger im Laden stand.


    Aber beide waren gut.
    Soll jetzt nur mal eine Metapher sein. Immerhin habe ich dir nicht vorher mitgeteilt ob beide gut oder schlecht waren ;D

    Ich fand es einfach merkwürdig, dass nur bei DTS dieses Problem auftritt.

    DTS wird meistens gerne in PCM WAV gewandelt um halt nachfolgende Probleme die sich im Zusammenhang mit dem Big Endian und dem decodieren des Codecs entstehen.


    Problem sind da z.B.:
    - Zeitverschiebungen, aufgrund das DTS falsch verarbeitet wird
    - Abbruch von Encoding, aufgrund das DTS für den jeweiligen Encoder nicht verstanden wird.


    Lösung:
    DTS in eine unkomprimierte Form zu bringen. Das heißt DTS -> PCM


    Und PCM lässt sich erheblich besser und leichter verarbeiten. Brauchst halt nur ein sehr guten DTS -> PCM Wandler. Und der ist bei FFmpeg recht gut eigentlich.


    Inwiefern falsch verarbeitet/encodiert? Ich füge das Video mit dem Oneclick Encoder von Megui in die Queue und starte, oder arbeite mit dem von Dir weiter oben beschriebenen Weg mit der Batchdatei.

    Diese Oneclick Variante ist nicht grad toll, wenn man es falsch nutzen sollte.


    Die Hauptsächliche Frage ist aber:
    Wie sieht denn dein Skript aus das du in MeGUI nutzt?
    Und:
    Wie genau gehst du beim Oneclick Encoder vor? Sprich: Schreib mal Stichpunktartig dein genauen Workflow auf.

    Da YouTube die Videos 4:2:0 ausgibt sollte man diese auch so rendern ?

    Kannst du machen. Deine Entscheidung.


    YUV 4:2:0 gibt YT aus, das ist korrekt. Aber was der YT Encoder bekommt, bestimmst du. Und da setzt der technische Hintergrund an.


    YUV 4:4:4 -> YUV 4:2:0 von YT ist besser als YUV 4:2:0 -> YUV 4:2:0
    Sofern man bei YT an die restlichen Auflösungen seines Videos denkt die gewiss skaliert werden müssen vom hochgeladenen Quellvideo.


    Aus technischer Sicht:
    auf Platz 1: A
    Platz 2: B
    Platz 3: C


    A ergibt die bessere Qualität, da YT ein viel sauberes Video bekommt und daraus besser jede andere Auflösung encodieren kann. Weil eine Farbunterabtastung von 4:4:4 ist optimal für Skalierer. Gerade auch bei den YT Skalierern.
    Fazit: Bessere Qualität auf allen Auflösungsstufen auf YT.


    B ist für den lokalen Bereich gut, sofern man lokal skalieren möchte. Effektiv und regelrecht ersichtlich profitieren Skalierer halt von höheren Farbunterabtastungen. Damit würdest du besser weg kommen, als wenn du den gleichen Werdegang mit C machen würdest.
    Fazit: Gute Qualität auf entsprechender hochgeladener Auflösung


    C ist nur dann richtig gut, wenn man nix skaliert. Sofern man skaliert zerlaufen sich die Farben, da ja an sich nur Interpolierte Farbzwischenräume da sind. Je mehr skaliert wird, desto unsauberer wird es.
    Fazit: Gute Qualität auf entsprechender hochgeladener Auflösung, sofern vorher nix skaliert wurde.



    Edit:
    Die Frage die du dir selbst beantworten solltest ist ob dir das reicht was du vorhast und ob du überhaupt noch ein Auge dafür hast.
    Ich habe dir lediglich den technischen logischen Aspekt geliefert. Und der trifft definitiv zu. Daher... deine Entscheidung was du tust.


    Ich kann dir höstens soviel sagen das viele A nicht bevorzugen aufgrund des großen Speicherplatzverbrauchs der Videos. Was halt enorm auch an Uploadzeit nagt.
    Kompromiss wäre B, aber die Masse hält nicht viel von Qualität, daher nehmen viele C
    Ist ja schließlich auch eine Frage was der Rechner kann und schafft.


    Und C ist immerhin auch noch gut, optisch gesehen.
    Jetzt rede ich von Optisch ;D Das ist halt mein Empfinden.


    Du wirst feststellen das satte Farben wie Rot, Grün oder gar Blau bei YUV 4:2:0 verlaufen auf YT. Massiv.
    Wenn du ein 4:4:4 Video mit 720p auf 1080p skalierst mit einem Punktskalierer und mit 4:4:4 auf YT hoch lädst, werden dir kaum Farben verlaufen aufgrund der Verdopplung der einzelnen Pixel in Breite und Höhe.


    Je mehr Detail also einfließt, desto komplexer wird das Bild.
    Wenn du ein 4:4:4 1080p Video hochladen tust, verhunst dir YT weit weniger als wenn du ein YUV 4:2:0 Video hoch lädst. Weil halt von jedem Pixel das neue YUV 4:2:0 Video auf YT generiert wird. Bei jeder Auflösungsstufe.


    Und wenn ich dich jetzt total Verwirrt haben sollte, machste es am besten wie gehabt ;D

    Dann hast du entweder falsch Audio verarbeitet oder encodiert oder falsch Video verarbeitet oder encodiert. Das ersehe ich grad nicht.


    DTS hat nix ungewöhnliches. Nur viele Codecs können damit nix anfangen. Im Grunde ist es Ratsam es erst in PCM WAV 16Bit little Endian umzuwandeln. Mit PCM WAV ist es dann für andere Codecs viel leichter und besser zu arbeiten.

    Wow, was hast du denn da gemacht? Sieht mir nach fixen Bitraten aus die du selbst angegeben hast. Das wäre recht Fail. Weil effizient wäre was anderes ^^


    ich habe neulich mal ein und dasselbe Video mit 2 verschiedenen Methoden gerendert

    Nenne doch mal deine Methoden, anstatt hier nur pauschale Angaben zu machen die an sich nix aussagen.



    würde gerne eure Meinung zum Verhältnis Nutzen bzw. Qualität/Zeitaufwand

    Das ersehen wir grad nicht und können daher keine Meinung äußern, weil anhand den pauschalen Angaben von dir weder sich die Qualität zeigt, noch deine Methoden und Einstellungen zwecks Zeitaufwand.



    Es ist einfach zu wenig Info um dir deine Frage konkret zu beantworten.


    Gibt aber gewiss Leute hier im Forum die schauen gerne in die Glaskugel um Hell zu sehen ;D

    Bei den 0-255 musste ich gerade an GIMP, Paint.net und die anderen konsorten denken. Dort ist die Basis also ebenfalls RGB. Durch das erstellen Transparenter png.Dateien oder einfügen von Filtern, wird mir nämlich auch ein Wertbereich von 0-255 vorgeschlagen. 0 ist hierbei der Transparente und 255 der volle Farbbereich.

    Du beschreibst hier den Alphakanal eines RGB Bildes. Das hat nix mit Begrenzung zu tun, sondern ob etwas Sichtbar ist oder nicht.
    0 = Unsichtbar
    128 = Transparent
    255 = Sichtbar


    Das betrifft nur den Alphakanal. Der Alphakanal besteht nur aus Schwarz-/Weiß- Abgleiche.


    Der Wertebereich 0 - 255 entspricht 1Byte bzw. 8Bit.


    Ein reiner RGB Farbkanal besteht dabei aus 3Byte pro Pixel
    Kommt der Alphakanal hinzu besteht er aus 4Byte pro Pixel. 3 für die Farbe und der 4te Byte ob dieser Pixel Unsichtbar, Transparent oder Sichtbar ist.


    Um dann jetzt noch ein letztes mal aufzuwickeln: Ich nehme also in YV12 auf. Ein Farbraum der begrenzt ist. Würde ich jetzt ohne mit dem Frameserver zu arbeiten direkt über den SSM und MeGUI rendern, hätte ich diesen Blasse Effekt nicht, weil Avysinth diesen Wert wieder streckt.

    Der SSM als auch MeGUI's x264 Encoder sind ohne Änderungen auf YV12 Begrenzt BT.709 eingestellt.


    Für weitere Farblehre, hier mal etwas wo du dir deine Antworten zu deinen Fragen selbst erlesen kannst: Farbräume (Tutorial) - erweiterte Erklärung und Zusammenhänge


    Moviestudio hingegen, streckt nichts und schickt diese Daten über den Frameserver und der daraus entstehenden Avi Datei an Avysinth weiter und Avysinth wird wegen der StudioRGB gesagt: Lass den Farbbereich auf TV.709. statt ihn wieder zu strecken. Also auf PC.709 zu stellen?

    Es gibt 2 Dinge die man wissen sollte:
    StudioRGB = Begrenzter Bereich 16 - 235
    ComputerRGB = Vollbereich 0 - 255


    Was du mit deinem Moviestudio nicht beeinflussen kannst wird mit großer Wahrscheinlichkeit die Farbmatrix sein. Und so wird z.B. aus einem BT.601 ein BT.709. Sprich dort werden die Farben beeinflusst.


    Die Farbmatrix gilt nur für YUV Farbräume. Für RGB ist sie irrelevant.


    Das heißt egal wie du aufnimmst, dein Video wird in Movie Studio immer in RGB gewandelt. Also einem Vollbereich. Wenn dein Video vorher ein Begrenzter Bereich war ist er somit nun Teil des Vollbereiches. Eine erneute Vollbereich zu Begrenzter Bereich Konvertierung würde das Bild an sich 2mal verblassen lassen. So die Theorie.


    Weiteres kannst du dem Farbraum Tutorial entnehmen.



    Was ich nur nicht ganz verstehe, wieso liest man dann überall, unteranderem auch hier in diesem Forum, dass der beste Encoder UTVideo ist und YV12 die beste Einstellung zum Aufnehmen? Kann es sein das unter brücksichtigung dieser Daten etwas 'Lüge' in diesem YV12 Mythos steckt?

    Ein Mythos ist es wenn man unerklärliche Sachen weder Nachweisen kann, noch es verstehen kann wie es funktioniert.
    Mit anderen Worten: Jeder der die Funktionsweise und den Aufbau von Bildern auf dem PC nicht versteht, für die ist es Magie xD


    Nein, Spaß beiseite. Wenn man weiß wieso und warum, dann ist es weder ein Mythos, noch ist es eine 'Lüge'. Technische Fakten können nicht lügen. Und gute Programmierarbeit die seit zig Jahren schon besteht gewiss kein Mythos ;D


    YV12 nehmen die meisten da es oft der geringste Farbraum ist der einem angeboten wird von den Softwares der Farbe beinhaltet.
    Zugleich wird für den YV12 Farbraum nur 12Bit verwendet, statt wie bei RGB volle 24Bit. Also spart man schon die Hälfte des Speicherplatzes.


    Warum wird da gespart?
    Weil YV12 oder besser YUV 4:2:0 eine sehr geringe Farbunterabtastung hat.
    4:4:4 wäre das der Y, U und V Kanal jeden Pixel darstellt.
    Bei 4:2:0 hat aber der Y Kanal volle Pixeldichte und U und V nur noch die die Hälfte. U und V haben als Ausgleich im Nativen Bereich Farblose Leerzeilen und Leerreihen drin.


    Die Leerzeilen und Leerreihen werden üblicherweise heutzutage Interpoliert. Das heißt sie werden rechnerisch aufgefüllt.


    Mehr dazu auch im Farbraum Tutorial.



    Es ist halt eine Frage ob man es verstehen möchte oder nicht. Für die, die es nicht verstehen möchten oder wollen, für die ist die ganze Videobearbeitung reine Magie mit vielen Unerklärlichen Sachen.
    Für die, die es verstehen was da passiert, für die ist das nur als wenn man in der Nase popelt xD

    Wenn du denkst ich meinte die CPU für das zocken dann muss ich dich enttäuschen und meinte die CPU Leistung für das rendern

    Spiele werden also nicht gerendert? Macht die GPU also ein päuschen? Ach nee... Bei dir wird das ja via der CPU gemacht, weil die GPU nur mit Ganzzahlen hantiert und für PI eine 3 nutzt. Ja... stimmt, bei dir ist das Rendering nur reines Raycasting. Ja, hast ja recht.
    Deine PDF sollte mir letztens die Augen öffnen xD



    Aber du als Hardware Experte kann ich nicht weiß machen das 99% der Hardware keine 4K in 60 FPS spielen können

    Sagte ja, momentan kann ein Durchschnittsrechner wie du ihn hast nix damit anfangen. Musst halt schon mehr investieren, wenn du das so willst. Die Hardware existiert und kann es. Der Preis dafür ist für den Durchschnittlichen Verdiener aber nicht erschwinglich.


    Oder du wartest bis alles billiger und besser ist und sich jeder sowas leisten kann.

    An meinem Gaming Rechner habe ich ein 12 Kerne CPU bzw. 6-12.
    Video a: 1080p = 30-40min gerendert
    Video b: 2160p = NUR 3 Stunden +

    Tja... wenn man Raycasting verwendet und nur mit Gleitkommazahlen alles berechnet... nicht? ^^


    Soll ich dir dein Blödsinn mal rausfischen aus dem Forum? ^^


    Ich denke du bist der letzte der mir weiß machen will das 4K kein Rechner macht.mit guten Settings und guter FPS.


    Weil bei dem was ich eben zitiert habe von dir gehst du wieder ganz Urplötzlich auf Video Rendering ein und versuchst es damit zu erklären.
    Das aber Spiele an sich rein 0 mit Video Rendering zu tun haben, sollte dir hoffe ich klar sein.


    Und wenn ich so auf den Thread zurückblicke wo du mir aus einer PDF die ausschließlich über Raycasting handelt und einen die Grundlagen des Rendering erklären sollte und du mir CPU und GPU erklärt hast... und hier jetzt genau das gleiche abziehst weil du die Zusammenhänge gar nicht zu begreifen scheinst zwischen Video Rendering was sich aus Neuberechnung und Encoding in einem Schnittprogramm zusammensetzt und einer reinen Spielszenerie das durch CPU und vorwiegend GPU sich ergibt.




    Hier an dem Bild siehst du das 4K Easy in den nächsten Jahren spielbar ist:

    Und du scheinst meine Beiträge nicht korrekt zu lesen wie mir scheint, denn:


    Es ist richtig das 4K noch auf dem Weg ist. Genauso wie es bei BluRays oder gar dem Encodec x264 gedauert hat das die Leute es akzeptieren, so lange dauert das eventuell auch bei 4K Sachen.
    BluRays haben am Anfang auch viele gesagt das sich das nicht durchsetzen wird und das es unnötig sei. Schau dich heute um, heute kann sich das keiner mehr vorstellen.
    Oder der x264 zwecks BluRays. Hat ja auch erst mal gedauert bis dieser zu einem Standard dafür wurde. Gute 4 Jahre
    Da haben auch viele erst behauptet das es Sinnlos ist.

    Du scheinst nämlich nicht zu verstehen das jeder Anfang schwer ist und das natürlich nicht nur Marketing hauptsächlich ist, sondern will man ja auch die Technik optimieren um später besseres daraus wieder zu entwickeln.


    Ihr lasst euch vom aktuellen Stand sehr viel belullen und glaubt natürlich jeden Mist den ihr im Netz lesen tut.


    Warum waren damals BluRays nicht so gefragt wie heute z.B. die 4K Filme im Laden?
    Richtig: A) der überwiegende Durchschnitt hat mit der Zeit BluRays akzeptieren gelernt und auch die Leistung der der Rechner hat sich entsprechend erhöht.
    B) Als die BluRay damals raus kam, war der Durchschnittsrechner noch mit DVDs bestückt. Das war Stand 2002 - 2006/7.


    Schau dir die Verkaufszahlen zwecks BluRay an.


    Die Durchschnittsrechner damals zu Anfängen der BluRay hatten nicht mal soviel Power das sie ein Film einer BluRay auf dem Rechner abspielen konnten.


    Sehr komisch das es heute ähnlich mit den 4K Filmen ist.



    Daher sagte ich auch das sowas Zeit brauch. Die Physische Speicherträger können mit 4K umgehen. Das ist kein Problem. Das Problem was aber mit der Zeit immer besser wird ist die Leistung.


    Und man müsste heutzutage schon gut 5 - 10 Tausend Eure für einen Top Rechner investieren um 4K60 mit guten Settings flüssig spielen zu können.


    Ihr geht aber nur von euren Durchschnittskamellen aus und seht das Drum herum erst gar nicht. Daher sagte ich auch... warte 4 - 6 Jahre und dann wirste sehen ob 4K flüssig geht oder nicht. Vllt. ist bis dahin sogar die PS5 raus. Die machen ja eh alle 3 - 4 Jahre ne neue Konsole... Dann hat sich das auch ;D

    Naja, dann müsste es deiner Meinung also laufen? ^^


    Weil schau dir die ganzen Settings an. An sich müsste es so wie alles eingestellt ist keine Probleme geben.


    Das einzige was mir jetzt noch einfallen würde ist das da irgendein Filter seitens ffdshow z.B. das Video falsch interpretiert.


    Weil an irgendwas muss es ja liegen. Und ich bin mir fast sicher das da irgendwas mit dem EVR nicht so stimmt.

    Problem ist ehr die Hardware die dafür benötigt wird. Allein bei Computer gibt es soweit ich weiß kein Rechner der dir 4K AAA Titel mit Ultra Settings mit Flüssigen 120 FPS abspielt oder geschweige 60FPS.

    Dann kann das ja nicht viel sein was du weißt ^^


    Es ist richtig das 4K noch auf dem Weg ist. Genauso wie es bei BluRays oder gar dem Encodec x264 gedauert hat das die Leute es akzeptieren, so lange dauert das eventuell auch bei 4K Sachen.
    BluRays haben am Anfang auch viele gesagt das sich das nicht durchsetzen wird und das es unnötig sei. Schau dich heute um, heute kann sich das keiner mehr vorstellen.
    Oder der x264 zwecks BluRays. Hat ja auch erst mal gedauert bis dieser zu einem Standard dafür wurde. Gute 4 Jahre ^^
    Da haben auch viele erst behauptet das es Sinnlos ist.



    Ob etwas Sinnlos ist oder nicht ergibt sich mit der Zeit. Weil der erste Anlauf mit neuen Sachen wird von Menschen aus gewöhnlichem Grund sehr Skeptisch meist betrachtet. Wenn es dann aber alltäglich ist und die Waren nachher erschwinglicher werden, dann wird das neue meist akzeptiert.


    Das ist reine Markttaktik und Menschverhaltensanalyse.


    Dieses TripleA kannste einfach mal weglassen, weil es ist egal wie teuer ein Spiel ist oder mit welchen kosten es entwickelt worden ist, ich glaube kaum das es der 4K Auflösung stört ;D Das können auch schlechter bewertete Games.



    Sieh dir die PS4 Pro an. Uncharted 4 läuft bereits schon mit 4K60.
    Selbst am PC gibt es Spiele die sowas supporten.


    Und es gibt auch Rechner die das Problemlos schaffen.



    Klar ist aber das es momentan nicht die Masse nutzt, weil das halt eine Preisfrage auch alles ist.



    Und für flüssige Aufnahmen von 4K Aufnahmen sind ja auch schon Raid0 Festplatten angebracht. Eine alleine würde das ohnehin nicht in Echtzeit stemmen können.



    Warum es darüber kaum bis gar nix im Netz zu lesen gibt von Usern ist die Tatsache einfach das viele es A) für unnötig halten B) gerade bei Let's Play Aufnahmen und Co. die Produktionszeiten enorm erhöhen und C) Der Preis für Hardware und Co. zur Zeit noch nicht für jeden erschwinglich ist.
    Man bedenke das nicht jeder ein Krösus ist ;D

    Was ich grad sehe in der Statusleiste wo die Fehlermeldung ist:
    Da steht ja YV12 EVR


    Ist aber YV12 EVR nicht NV12?


    Würde den Fehler dann erklären warum MagicYUV oder das Programm selbst sich über den Farbraum beschwert.
    Denn MagicYUV kann ja viele Farbräume, aber NV12 nicht.


    Ich bin mir fast sicher das YV12 EVR = NV12 ist.


    Müsste man mal probieren.


    z.B. wenn UTVideo oder Lagarith sich weigern, aber x264vfw es nimmt, dann wäre der Fall klar. Dann ist der Farbraum NV12.



    Oder.... in VirtualDub mal prüfen was er da als Farbraum angibt..

    @MuenSe


    Habe dir mal so ein Stress Test bzw. Extrem Test Files mal erzeugt.


    Die Anleitung dazu sind im jeweiligen Zip File enthalten: http://www.mediafire.com/file/…hfz1q/StressTest_Video.7z


    Enthalten sind:


    Test Files für die Youtube 16:9 Auflösungen 144, 240, 360, 480, 720, 1080, 1152, 1440, 1800 und 4K als Progessiv
    FPS Test Files für 15, 30, 41, 48 und 60 FPS


    Die Quelle sind sogenannte Rausch Bilder die als RGB 24Bit Vollbereich vorliegen. (Also so als würde man vom Rechner aufnehmen.)
    Test1 ist der allgemeine Rauschtest
    Test2 ist ein Rauschtest mit Flackertest um die GOP bei Compressionscodecs wie h264 auszutricksen,
    da dann jedes Bild mehr als 40% Unterschied hat und daher ein I Frame schreibt.


    Achtung: Test 2 kann zu Epilepsie führen, beim anschauen des fertigen Videos.



    Das sind hochkomplexe Framezustände. Die würde man bei einer Spielaufnahme niemals erreichen. Die sind jetzt nur für die Codec Tests gedacht.


    Brauchen tust du für das testen AVISynth und AVSPmod am besten. Beides wäre beim SagaraS Scriptmaker enthalten im Paket.


    Weil die Videogenerierung erfolgt über AVISynth und über AVSPmod kannst du direkt über VFW deine für Windows installierten Codecs verwenden oder direkt CLI Codecs nutzen. ^^

    Behalten ist ist einfacher als den Kram in Stereo zu bringen ^^


    Also... am besten gehst du bei diesem Video wie folgt vor:

    • Demuxen mit MKVExtractGUI
      Das Tool findeste im Internet und muss lediglich im MKVMerge Ordner rein. z.B. bei MeGUI unter Tools\mkvmerge\


      Das startest du und packst dein Video da rein. Dann extrahierst du NUR die Audio Spur die du haben willst und die Untertitel Datei.
      Die wirst du beide brauchen, da du gewiss kein Elbisch kannst ^^

    • DTS Audio in Vorbis umwandeln ohne Änderung der Kanäle
      Dazu nutzt du am besten FFmpeg. -> https://ffmpeg.zeranoe.com/builds/


      Wenn du FFmpeg hast, entpackst du die ZIP Datei.


      Danach erstellst du eine Batchdatei mit folgenden Inhalt:

      Code: DTS2OGV.BAT
      @echo off
      set _ffmpeg_="G:\Lets Play Aufnahmen\MeGUI\tools\ffmpeg\ffmpeg.exe"
      set _input_=%1
      for /f "useback tokens=*" %%a in ('%_input_%') do set _input_=%%~a
      %_ffmpeg_% -i "%_input_%" -c:a libvorbis -qscale:a 5 "%_input_:~0,-4%.ogv"


      Ändere in Zeile 2 der Batch Datei den Pfad zu deiner FFmpeg.exe Datei ab.
      Danach kannst du die DTS Datei einfach auf die Batch Datei ziehen und die DTS Files werden in OGV mit der Qualitätsstufe 5 encodiert.
      Die Qualitätsstufe kannst du in Zeile 5 auch ändern unter dem Parameter -qscale

    • Video neu Encoden mit H265
      Um das Video neu in H265 zu encoden würde an sich ebenfalls FFmpeg eignen.
      Das ist dir aber nun überlassen.


      Du kannst jetzt in MeGUI das Video neu encodieren via AVISynth und dem H265 Encoder. Was natürlich dauern kann.
      Oder du nutzt FFmpeg dazu.


      Mit ffmpeg geht es wie folgt:


      Code: MP4&MKV2MKV_h265.BAT
      @echo off
      set _ffmpeg_="G:\Lets Play Aufnahmen\MeGUI\tools\ffmpeg\ffmpeg.exe"
      set _input_=%1
      for /f "useback tokens=*" %%a in ('%_input_%') do set _input_=%%~a
      %_ffmpeg_% -i "%_input_%" -c:v libx265 -preset medium -crf 23 -an "%_input_:~0,-4%.mkv"

      Bedenke das es mit FFmpeg gewiss schneller geht, als über AVISynth und Co. ;D
      Zumal du auch keine Filter brauchst.

    • Mit mkvmerge wieder alles zusammen schmeißen
      Halt einfach alles zusammensetzen was du mit fabriziert hast.



    H265 + Vorbis + Subtitle in MKV zusamm in FFmpeg sieht so aus:
    (Das wäre ein Komplettpaket mit allen)

    Code: ALL2MKV_h265_vorbis.bat
    @echo off
    set _ffmpeg_="G:\Lets Play Aufnahmen\MeGUI\tools\ffmpeg\ffmpeg.exe"
    set _input_=%1
    for /f "useback tokens=*" %%a in ('%_input_%') do set _input_=%%~a
    %_ffmpeg_% -i "%_input_%" -c:v libx265 -preset medium -crf 23 -c:a libvorbis -qscale:a 5 -c:s copy -map 0:0 -map 0:1 -map 0:3 "%_input_:~0,-4%.mkv"

    mit -map kannst du die Streams selektieren die du haben willst und später im mkv Container wieder rein sollen.


    Und nicht vergessen immer jeweils die 2te Zeile abzuändern zu deinem FFmpeg.exe Pfad.