Beiträge von Sagaras

Zitat von Nobody768

Es wäre aber möglich, halbwegs anständig die Fehler von Shadowplay zu korrigieren

Wieso sollte der User die Unannehmlichkeiten von Shadowplay beseitigen?

Warum macht die Community von Shadowplay sich nicht mal Stark dafür das dieses Programm mehr kann?

Es ist kein großer Aufwand ein VFR/CFR Umschalter hinzuzufügen und es wäre kein Ding die Aufnahme in BT.709 laufen zu lassen und ihre Maxwell Karte kann gewiss Lossless aufnehmen, sollten se mal hinzufügen. Und wenn se dann noch ein MKV Container nutzen würden, würde auch PCM Audio damit aufgenommen werden können.

Dann müssten se nicht mal eine VFW Schnittstelle integrieren, obwohl das für die eigentlich auch ein einfaches wäre.

Nur NVIDIA will das anscheinend gar nicht und die Community scheint das womöglich auch so weit egal zu sein.

Zitat von Nobody768

Aber nicht jeder möchte die maximale Qualität, viele interessiert es nicht besonders, solange man das Video halt einigermaßen ansehen kann.

Und nicht jeder möchte so eine Grauenhafte Qualität.

An und für sich wäre jedem geholfen wenn sie die Punkte die ich angesprochen hatte mal berücksichtigen würden. Weil dann wäre jedem damit geholfen und man könnte das Programm auch mal jemandem empfehlen.

So aber ist es nix anderes als ne schlimmere Variante von Fraps, nur das es dank ihrer Hooking Methode performanter läuft.

Schade eigentlich für Shadowplay. Könnte mehr das Teil, wird aber von den Entwicklern nicht als wichtig empfunden oder gar als unnötig und der User hat halt das Nachsehen damit. Wirklich schade eigentlich.

Zitat von Mayesters

Erzeugt denn ein Overlay so viel RAM-Benutzung? Sind halt verschiedene GUI-Elemente, die mit einem anderen Design überlagert werden, dementsprechend ist es ein 1800p Bild.

Der Filter Overlay ist ohnehin etwas Anfällig was Multithreading angeht.

Und mit deinem 1800p Bild ist dem Speicher auch nicht grad geholfen.

Denn das Bild muss für ein Wasserzeichen das über das gesamte Video angezeigt wird dubliziert werden. Sprich es werden soviele Kopien erzeugt wie das Gesamt Video an Frames hat.

Und dann muss auch noch der Alphakanal entfernt werden und es muss auf das Video selbst überlagert werden.

Sprich, weil das Bild schon so groß ist, wird die Speichergrenze von 32Bit ganz schnell mal erreicht. Dazu noch dein Video und schon geht das ganz schnell mal. Da muss man dann entweder auf ein Thread limitieren lassen oder einen etwas langsameren MT Mode nutzen oder in Kombination mit MemoryMax.

Wenn auch eine sehr wagemutige und zeitraubende Option

Die Garantie das VFR zu CFR schon reicht, ist nicht gegeben. Was wäre jetzt wenn auf einmal die Tonspur versetzt noch ist. Sprich VFR + Versetzung der Tonspur um ein paar ms. Falsche Farbmatrix usw.

Das wäre für die meisten zu viel Aufwand. Und das die VFR Aufnahme ohne Umwandlung einer CFR entspricht ist halt noch wagemutiger. Und das machen halt viele diesen Schritt, einfach aus Unwissenheit oder durch pure Zeitersparnis. Weil halt für einige der Mehraufwand nicht in Frage kommt.

Diesen Aspekt sollte man mit einbeziehen. Und da hat dann @GelberDrache92 halt recht das man es dann gleich ordentlich aufnehmen sollte mit einer entsprechenden CFR.

Shadowplay nimmt ja nicht mal Verlustfrei auf, was andere Aufnahmeprogramme halt können. Sprich Shadowplay ist für diesen Punkt ganz schön weit hinten in der Kette der guten Aufnahmeprogramme. Shadowplay könnte Lossless aufnehmen, die Entwickler aber fügen dies nicht hinzu. Ergo: Schlecht.

Denn aus einem Verlustfreien Material kann ich mehr Dateigröße nach dem Bearbeiten und Encoding sparen und habe eine bessere Qualität, als das ich lossy aufnehme und habe nach dem Bearbeiten und Encoding eine größere Datei und eine schlechtere Qualität.

Das ist wie mit einem Fernsehsender.
Wenn der Sender rauscht, nimmst du die Fehler des Rauschens mit auf. Das wäre die Lossy Variante
Wenn der Sender nicht rauscht und du nimmst es auf, dann hast du die Lossless Variante.

Und jetzt sendeste das Video noch mal hinaus und bekommst, wenn du es auf gleichem Wege wieder empfängst das eine Signal noch mit mehr Rauschsignalen und das andere mit leichten Rauschsignalen.

Je mehr, desto schlimmer wird es.

So läuft das mit Codecs und dem Encodieren halt auch. Immer an die goldene Regel denken: "Aus Scheiße kann man bekanntlich kein Gold machen"

Und das fängt bei der Quelle halt schon an ob ich ein Lossy Codec verwende oder ein Lossless Codec. Weil darauf baut sich dann der Ganze Rest auf.

Shadowplay hat nur einen Vorteil, das es hinter der Engine sich einhaken tut und die frames abgreifen kann. Ansonsten ist alles andere totaler Schwachsinn den Shadowplay fabriziert mit den Videos.

Weil würde MSI Afterburner oder DxTory oder wahtever es genauso machen wie Shadowplay mit dem Hooking, dann wären diese im klaren Vorteil, da sie die Videos Lossless aufzeichnen könnten und hätten dennoch dieselbe Performance wie Shadowplay.

Diese Technik wird aber NVIDIA gewiss nicht rausrücken. Weil würden sie es rausrücken und es wäre eine rein Grafikkartenbezogene Technik, dann könnte man dies für Radeon Karten gewiss genauso nutzen.

Die GPU Encoder die Shadowplay verwendet, haben bezüglich der Performace so gut wie gar keine Wirkung.

Denn GPU Encoder kann man auch in Afterburner, OBS, etc. verwenden die auf gleiche Basis laufen wie der von Shadowplay. Und? Läuft Afterburner und OBS dann performanter wenn man diese nutzt? Nö xD

Die Performance trägt zum größten Teil das Hookingverfahren. Und genau hier hat Shadowplay einen Pluspunkt. Dies allein wiegt aber gewiss nicht das andere auf wie aufgenommen wird dort. Es sei denn das es dem User total egal ist ob es Asynchron ist, falsche Farbmatrix hat und überhaupt so alles. Audio wird ja schließlich auch total beschissen von Shadowplay aufgenommen.

Und es ist auch nur eine Audiospur soweit ich weiß aufnehmbar mit Shadowplay. Also Shadowplay an sich, außer dem Hookingverfahren, ist 10mal schlimmer als Fraps

Bei der Auflösung übersteigste vermutlich mit YV24 die 32Bit Grenze von AVISynth. Nutze mal entweder für Sourcen ein MT Mode von 4 oder Mode 3 + ein MemoryMay von 512MB

Grund ist, das er sich womöglich für das Wasserzeichen die Grenze 32Bit Speichers überschreitet.

Gut würde es laufen, wenn du MT komplett abschalten würdest.

Wäre zwars dann langsamer, aber gewiss würdest du die Fehlermeldung nicht bekommen.

Zitat von Mayesters

F:\Eigene Dateien\Eigene Videos\LoLProVod\1800p.png

Ich hoffe mal das das kein wirkliches 1800p Bild ist

Zitat von Mayesters

Sobald ich dann aber meine 4:4:4 Aufnahme in YV24 konvertiere (planar für die AVS Pipeline) klappt das Encoding nicht mehr, solange ich SetMTMode(3) drinhabe. (Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819) als Fehler).

Dann wird vermutlich vom Encoder mehr Speicher benötigt, als dein System ab kann.

Kann aber auch andere Ursachen haben. Die entsprechende Log von MeGUI mit diesem Fehler beim entsprechendem Skript wäre Hilfreich.

Zitat von De-M-oN

Hat Zeit und vor allem Qualität gekostet dann, wenn nicht lossless geschehen.

Lossless hatte ich eigentlich angesprochen. Sollte Voraussetzung sein dann bei sowas.

Immerhin hat er damit dann eine recht schnelle Bearbeitung und spätere Encodierung, statt das er das über den Frameserver macht.

Die Wahl lag ja bei ihm.

Aber hast recht, Lossy noch mal in ein AVC Stream via H264 zu kodieren bringt keine Pluspunkte für die Qualität des Videos. Daher Lossless immer. Zum einen schneller beim erstellen und zum zweiten schnellere Verarbeitung, da der Frameserver und AVISynth wegfallen.

SSM v6.1 nutzen

Wenn du es installiert hast mit samt Frameserver, kannst du unter Sonstiges auf den Button VFR -> CFR klicken. Und stellst es für dein Video genauso ein:

So, wenn du den Frameserver nutzen willst:

ODER

so, wenn du die AVS Datei mit FFmpeg oder VirtualDub oder was weiß ich es als Lossless Datei mit UTVideo, MagicYUV etc. encodieren lassen möchtest:

Zitat von Kayten

Rendern: Bild zusammenfügen

Rendern = Neuberechnung.

Da muss nicht unbedingt was zusammen oder hinzugefügt werden. Das Bild wird einfach via GPU oder CPU komplett neu berechnet. Das nennt man dann übersetzt "'Rendern"
Wenn man mit 3D Software arbeitet, ist der Begriff plausibler zu verstehen. Bei Schnittprogrammen werden damit die Frames gemeint die neu berechnet und erstellt werden aus der Quelle.

Zitat von Kayten

Kodieren: Bild verschlüsseln (Dateigröße verringern)

Kodieren / Encoding = Verschlüsseln (Nur Verschlüsseln)
Da Kompressionstechniken ebenfalls eine Verschlüsslung darstellen und die jeweiligen Verschlüsslungsverfahren (Cäsar Code, Enigma, YUV, MAGY, LAGS, h264 usw...) an sich auch, nennt man es einfach nur Verschlüsseln auf Deutsch. bzw. Kodieren und im Englischen halt Encoding.

Das Dekodieren / Decoding = Entschlüsseln (Nur Entschlüsseln)
Das machen dann meist Video Player wie VLC, ffdshow, DirectShow, FFmpeg, usw.

Ein Codec besteht daher entweder aus Encoder und/oder Decoder und ist halt das Kofferwort für beide.

Zitat von Tieger Games

Das heißt, wenn ich bei Vegas "rendern als..." anklicke, ist das eigentlich eine Kodierung als das fälschlicherweise angedachte Rendern?

Habe es grad @Kayten erklärt was was ist.

Wenn du auf "rendern als..." klickst, heißt das nix anderes als das dein Video komplett neu berechnet wird und ALS Datei xyz encodiert wird.

Sprich das was als "..." gemeint ist, wird von dir bestimmt und ist an sich nur der Encoder Vorgang.
Das Rendern bzw. das Neuberechnen der Frames vom Video macht dein Schnittprogramm von selbst.

Zur Aufklärung wo GPU und CPU Sinnvoll sind:
Die GPU ist für das Neuberechnen (Rendern) am besten geeignet. So wie jedes Grafikprogramm davon profitieren würde. Eine Neuberechnung via GPU ist das schnellste was man machen kann. Im Notfall kann man das auch über die CPU machen lassen, was dann natürlich erheblich langsamer dann ist.

Die CPU schlägt aber die GPU, wenn es sich um Encoding handelt. Sprich alles was du unter "Rendern als..." findest, sind Encoder. Und wenn du da ein CPU Encoder verwendest, sind diese meist am schnellsten noch gegenüber einem GPU Encoder.
Der Grund liegt darin wie Encoder arbeiten. Die lassen sich gaaaaanz schlecht parallelisieren.

Kayten hatte dir auch ein schönes Bild mit einem Dreieck gepostet. Qualität, Kompression, Speed.

Dabei gilt folgendes immer zu beachten:
Qualität = - Kompression + Speed
Qualität = + Kompression - Speed

Kompression = - Qualität + Speed
Kompression = + Qualität - Speed

Speed = + Qualität - Kompression
Speed = - Qualität + Kompression

Da du sicher Qualität haben willst kommen nur die ersten beiden Sachen in Frage.
Da du auch noch Zeit sparen willst, eigentlich nur noch das erste mit - Kompression + Speed

Das heißt im Klartext das deine Dateigröße relativ egal sein muss, denn um Speed rausholen zu können ohne dabei großartig an Qualität verlieren zu müssen, muss an Kompression gespart werden.

Massiv kann man dies schon mit jedem Lossless Codecs erreichen. Da hast du beim Encodiervorgang den kleinsten Zeitaufwand, wobei die Dateigröße erheblich anwächst.

Effizienter wird es dann mit x264, wo man dann die Kompression und Qualität etwas angleichen kann und es Optimal auszubalancieren. Dauert dann etwas, weil Kompression. Aber damit sollten definitiv bessere Ergebnisse rauskommen, als das du den Mainconcept Encoder der schon bei Vegas intern vorhanden ist benutzt. Weil Bitraten bei einem Video anzugeben, dessen Komplexität man nicht kennt ist wie ein heiteres Ratespiel und sollte definitiv vermieden werden, wer auf Qualität und Zeit aus ist.

Mit x264 hast du dann, wenn man es dann entsprechend eingestellt hat, eine recht kleine Datei entsprechend zur Qualität und zum Zeitverhältnis.

Zitat von De-M-oN

DirectShow vs laufendes Computersystem.

Was willst du denn jetzt mit DirectShow, wenn der Input schon als YV12 oder YUY2 anliegt? Kannst es dann auch natlos ohne irgendein Filter wie DirectShow mit den Codec als YV12 oder YUY2 speichern lassen. Und das wäre halt natives YV12 oder YUY2 von einem laufenden Computer.

Kannst das gerne mal bei einer PS2 Konsole oder Gamecube oder was auch immer ausprobieren.

Und das auch nur weil die Konsole das nur als Output kennt.

An sich wie auch bei einem Emulator wäre es natürlich auch ein RGB Signal. Aber gerade bei einer Konsole hast du halt extern ein YUV Signal anliegen und das kannst du halt am PC nativ auch so einlesen lassen ohne DirectShow. Das kannste gerne mit VirtualDub ausprobieren, wenn du möchtest

Und ne Konsole ist kein Computer, Hm? Hat weder ein Betriebssystem, noch sonstige Merkmale eines Computers?

Den Satz hab ich auch gar nicht angesprochen, sonder deinen ersten und deinen letzten.

Ja, aber weil du gesagt hast das das gesamte System in RGB32 läuft. Stimmt ja nicht immer ^^. Kann ja auch auf 8Bit 256 Farben stellen. RGB8 oder auf 16Bit mit RGB16. Und schon stimmt die Aussage ja nicht mehr

Und wenn du versuchst eine externe Quelle aufzuzeichnen wie Webcam oder Konsole, dann nimmt MagicYUV entsprechend ein YUV Signal auf, wenn es anliegen sollte und nicht RGB. Und das ist auch über Computer

Zitat von De-M-oN

Meist? Das gesamte System läuft in RGB32. Daran kann kein Spiel was dran rütteln

Ich habe auch Spiele gehabt, ältere Vorwiegend, die liefen dann mit 256 Farben oder mit RGB16 und nicht RGB32

Accepted colorspace auf All supported stellen. Das ist der Farbraum den er als Quelle bezieht. Wenn du nur YUV444 auswählst, kannst du nur solche Quellen auch beziehen lassen. Meist wird aber RGB32 genutzt für Spiele. Um aber alles akzeptieren zu können als Quelle sollte All supported ausgewählt sein.

Mode (conversion) <- Das ist der Teil den du suchst. Wenn du in YV24 aufnehmen willst, dann solltest du hier auf YUV 4:4:4 stellen. YUY2 wäre YUV 4:2:2 und YV12 wäre YUV 4:2:0

RGB32 kann man auch aufnehmen mit Compress as-is (no conversion), jedoch nur wenn als Quelle bei Accepted colorspace eine RGB Quelle anliegt. Steht die jedoch auf YUV 4:4:4, so kann das nicht gehen und er würde nur YUV 4:4:4 speichern wollen. Kann er bei dir aber nicht, da die Quelle wie gesagt falsch eingestellt ist.

Und bitte ein Haken bei Interpolate when downsampling anhaken. Und angehakt lassen. Damit werden Subsampling Probleme gelöst, indem die grauen Zwischenräume mit den angrenzenden Farben interpoliert werden um eine bessere Qualität der Farben zu erhalten.

Gib uns doch einfach mal ein Bild wie du es eingestellt hast.

Solltest dir mal Zeile 1 und Zeile 5 durchlesen und dann entsprechend die Zeilen darunter jeweils abändern zu deinen Plugins und Files.

PS: Die Analyse geht nur via FFMS2. Sprich FFmpeg. Und FFmpeg kann kein MagicYUV dekodieren. Wenn du also mit MagicYUV aufgenommen haben solltest, musst du es entsprechend in das richtige UTVideo Format transkodieren. UT Video kann FFmpeg.

h264 Formate sollte FFMS2 lesen können.

Zitat von Ripoli

Framerate

Nur das reicht.

Zitat von Ripoli

Feldreihenfolge

Da sollte nix stehen, bzw. aus sein. Feldreihenfolge sind erst wichtig, wenn Videos Interlaced sind. Vollbilder ohne Feldreihenfolgen nennt man Progressiv Bilder.

Zitat von Ripoli

Fernsehnorm

Irrelevant. Fernsehnorm ist für Youtuber unwichtig. Das ist erst interessant wenn man Filme für die USA, Europa, Asien und Co. machen will und die Videos DVD Bereit machen will.

NTSC limitiert die Höhe und haben niedriegere FPS Werte als PAL, dafür nutzt NTSC Material immer Vollbilder. PAL hingegen hat immer das größere Bild und höhere FPS Werte, dafür nutzt PAL meistens Interlaced Bilder.

Wie gesagt: Irrelevant für Youtuber und schon gar für Let's Player. Das Teil sollte auf PAL stehen. An sich ist es eine Preset Funktion.

Da sieht man auch wieder das Adobe für Let's Plays und Youtube nicht gedacht ist, sondern für Kameras, DVDs, BluRays etc. pp. Mehr wohl für Kameras.

PS: An deiner Stelle würde ich dir ja x264 als Encoder vorschlagen, als den h264 Mainconcept Encoder von Premiere. Die Effizienz und Qualität sprechen dann für sich. Und auch die Dateigrößen werden Wirtschaftlicher, als sich auf dieses heitere Ratespiel mit Bitraten zu verlassen.

Entweder macht Gronkh noch Filter drauf, oder hat ganz andere Aufnahmeprogramme und Einstellungen.

Die letzten 3 ähneln sich alle und da denke ich das da keine Effekte drauf sind, sondern sich höstens von den Settings der Aufnahme bzw. des Encodings vor dem Upload sich unterscheiden ein wenig.

Ich kann dir ja mal ein Script geben wo du dir das selbst austesten kannst mit deinen Aufnahmen. Am besten über den AVSPmod Editor prüfen.

Den AvsPmod Editor unter Video -> YUV->RGB bitte so einstellen: BT.709 und TV levels
Das entspricht dann der Youtube Player Ausgabe.

Und dann dieses Skript mal nutzen für die Video Tests:

# Plugins (Pfade bitte anpassen)
LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\ffms2.dll")
LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\ColorMatrix.dll")


# Videoaufnahme (Bitte Pfad + Videodatei angeben)
file = "G:\fs-uae_2015_12_13_14_25_11_993.avi"


FFIndex(file)
FFVideoSource(file, threads = 1)


PCvsTV([<"PCvsTV", 0, 2, 0>], matrix = [<"Matrix", 0, 2, 0>])
Tweak(sat =[<"Sättigung", 1.0, 5.0, 1.0>])


Function PCvsTV (clip clip0, int "mode", string "varprefix", bool "colorrange", bool "colorspace", int "matrix") {
    mode = Default(mode, 0)
    varprefix   = Default(varprefix, FFVAR_PREFIX)
    colorrange  = Default(colorrange,true)
    colorSpace  = default(colorspace,true)
    matrix = Default(matrix, 0)
    clip0.frameevaluate("""
        fftempstring = "" 
        varprefix = """" + varprefix + """"
    """)
    colorspace ? frameevaluate("""fftempstring = fftempstring + "(Source) Farbraum: " + FFColorSpace(eval(varprefix + "FFCOLOR_SPACE")) + "\n" """, after_frame=true) : nop() 
    colorrange ? frameevaluate("""fftempstring = fftempstring + "(Source) Farb Reichweite: " + FFColorRange(eval(varprefix + "FFCOLOR_RANGE")) + "\n" """, after_frame=true) : nop() 
    clip0 = (mode == 0) ? scriptclip("subtitle(fftempstring, lsp = 1)", after_frame=true) : Clip0
    clip0 = (mode == 1) ? Clip0.Levels(0, 1.0, 255, 16, 235, false).Subtitle("(Convert) PC -> TV (16-235 ->  0-255)") : Clip0
    clip0 = (mode == 2) ? Clip0.Levels(16, 1.0, 235, 0, 255, false).Subtitle("(Convert) TV -> PC ( 0-255 -> 16-235)") : Clip0
    y = (mode > 0) ? 18 : 36
    clip0 = (matrix == 1) ? clip0.ColorMatrix("Rec.601->Rec.709").Subtitle("(Convert) Farbmatrix: BT601 -> BT709", y= y) : clip0
    clip0 = (matrix == 2) ? clip0.ColorMatrix("Rec.709->Rec.601").Subtitle("(Convert) Farbmatrix: BT709 -> BT601", y= y) : clip0
    return clip0
}


function FFColorRange(int i) {
    i=(i<0||i>2) ? 0 : i
    return Select(i,"Unknown/Unspecified", "TV (16 - 235)", "PC ( 0 - 255)")
}


function FFColorSpace(int i) {
    i=(i<0||i>10) ? 2 : i
    return Select(i,"RGB","BT709 (ITU-R Rec.709)","Unspecified","Unspecified","FCC","BT470BG (ITU-R Rec.601)","SMPTE 170M (ITU-R Rec.601)","SMPTE 240M","YCoCg","BT2020 NCL","BT2020 NC")
}

Sieht dann so aus:
http://fs5.directupload.net/images/160322/kus5j63w.png

An der rechten Seite neben der Vorschauanzeige, kannst du dann ein Feld aufklappen und dann stehen da Slider mit den Namen PCvsTV, Matrix und Sättigung.

Das sind die Filter die du darüber verschieben und somit austesten kannst.

Ich kann das leider nicht austesten, da ich die Aufnahmen nicht habe die du machst.

Wenn in Klammern Source steht, dann sind das Werte des geladenen Quellvideos. Steht da Convert, sind das Konvertierungen und entsprechen nicht dem Original mehr. Sprich Source = Original.

Hast du vllt ein Vergleich da?

Zitat von Wajane

Also nehme die PS4 auch mit AmaRecTV auf und wenn ich PS4 Ausgabebereich RGB auf Voll stelle, wird alles nur dunkler.
Könnte sein das die Aufnahme Software nur limitiert TV range kann o0

Aufnahme:
TV -> TV = neutral
TV -> PC = mattes Bild (Tim Taylors Problem mit der HD60, der es auch alles auf HDMI schiebt)
PC -> TV = dunkles Bild (dein Problem grad)
PC -> PC = neutral

Alles was neutral ist entspricht haben keine Unterschiede.

Die Aufnahme hat gegenüber einem Player auch noch einen TV vs PC Range unterschied. Entspricht dem selben Muster wie bei der Aufnahme auch.

Ist also der Player falsch eingestellt, spielt er das Video jeweils auch falsch ab. Das kann bei VLC schnell dazu kommen als auch bei dem Chrome HTML-5 Player.

Youtube nutzt TV Range.

Wer Verlustbehaftet aufnimmt in YV12 oder YUY2, wird in den meisten Anwendungen wie AmaRecTV TV Range genutzt. Weil für YUV ist es üblich das TV Range genutzt wird. Das ist in vielen Programmen als auch Konverter Standard so.

Wenn man jedoch mit MagicYUV oder gar UTVideo aufzeichnet, würden diese Codecs die Range aufzeichnen die sie bekommen. Das heißt sie würden höstens vom Aufnahmeprogramm selbst die Limitierungen bekommen.

Wenn ich VirtualDub und meine PS4 via HDMI und Aufnahmekarte aufnehme, dann kann ich sogar PC Range aufnehmen. Einfach weil mir das Aufnahmeprogramm dies erlaubt.
Sprich HDMI überträgt es so wie es von der Konsole kommt. Und wenn du die PS4 auf PC range (sprich Vollbereich) umstellst, dann wird das auch via HDMI so übertragen. Weil HDMI kann beides und limitiert nix.

Das einzige was limitieren kann sind entweder die jeweiligen Aufnahmeprogramme und oder verwendete Codecs. Jedoch gibt es auch im YUV Bereich PC Range. Wäre ja schlimm wenn nicht. Aber ob dir das jeweilige Aufnahmeprogramm dies erlaubt ist natürlich eine zweite Frage.

VirtualDub erlaubt es halt, ob AmarecTV entsprechend auch eine Konfiguration dessen erlaubt weiß ich grad nicht.

Fest steht jedoch das und das war ja auch der Grund warum ich das geschrieben habe was du so schön von mir zitiert hast, das HDMI an sich nix limitiert in diesem Bezug. Einzig und alleine die Anwendungen und oder Aufnahmemethoden die genutzt werden machen dies. Und diese muss man entweder umstellen oder man kann auch Nachhaltig es ändern lassen.

Eine TV Range Aufnahme wäre aber auf jedenfall der korrekte Weg, denn Youtube nutzt ja ebenfalls TV Range und wäre somit neutral von der Darstellung.