Welcher Codec?

Jup, MagicYUV ist von denen der beste Codec. Eine gute Alternative wäre noch UT Video, der entlastet die CPU noch mal einen kleinen Tick.

Ja, die sollten soweit passen.

Ups, übersehen. Siehe unten.

Sind nicht in Ordnung. Interpolate when downsampling muss aktiv sein, sonst ist jede zweite Zeile und Spalte farblos bei YUV420.

MPEG 2 ist selbstverständlich nicht lossless, im Gegenteil

Zitat von NiCeOnE

Rendere mit Vegas 13 in Sony AVC/MVC | AVC, 1920/1080, Cabac,
60 FPS, 25.999.360 Bitrate in MP4

das solltest du in jedem Fall anders machen. Und Ark in nur 1920x1080? Ich möchte nicht wissen, wie stark die Blockpampe dann auf Youtube ist. Da schauert ja schon der Gedanke daran bereits
Erstrecht bei solch schwer komprimierbaren Spielen sollte man in jedem Fall Youtube nicht bloß 1080 geben. Das kann einfach nicht gut gehen.
Auch trau ich dem extrem ineffizienten Encoder von Vegas keine saubere Qualität bei Ark mit 26mbit zu.

Zitat von NiCeOnE

Habe evtl vor auf 4k hoch zu Rendern bei Vegas meinste das würde was helfen?

Jup, damit würdest du auf jeden Fall mehr Bitrate bekommen.

Ich finde den MagicVUY-Thread leider nicht mehr, ist es normal das MagicVUY die Farben "verhunzt" wenn man eine VY12-Quelle mittels "As-Is" damit komprimiert? Ich hab mal ein Testmuster verglichen und deutliche Farbabweichungen festgestellt (mit aktueller MagicVUY Version)...

Besonder auffällig bei "reinem" Grün, Quelldatei hat an der Stelle ein (mehr oder weniger sauberes) RGB: 42,254,1, die MagicVUY-Version zeigt dort aber RGB: 27,219,0 was deutlich unterhalb des Originals liegt, zum Vergleich liefert Lagarith dort RGB: 42,254,0

Beide Codecs wurden direkt mit VY2-Material per "Fast Recompress" aus VirtualDub gefüttert, hatten also beide die selbe Quelle, trotzdem hat MagicVUY es (egal welche Settings) jedesmal nicht hinbekommen dort 1:1 wieder das auszugeben was man reinpackt.

Zum vergleich: Schiebe ich per VirtualDub und "Full Processing Mode" ein von VY12 nach RGB888 konvertiertes "Signal" an MagicVUY so kommt dort im Anschluß bei YUV422 auch wieder die korrekte Farbe RGB: 42,254,1 raus...

Ist der Input-Pin von MagicVUY was YV12 angeht "defekt" oder warum schafft der Codec es nicht 1:1 das abzuspeichern was ich reingebe? Im "As-Is"-Modus sollte er doch keinerlei interne Farbraum-Konvertierungen vornehmen oder?

TLDR:
Fast Recompress, Input = VY12 - Quelle: 42,254,1 (RGB), MagicVUY: 27,219,0 (RGB), Lagarith: 42,254,0 (RGB)
Full Processing Mode, Input = RGB888 - Quelle: 42,254,1 (RGB), MagicVUY: 42,254,1 (RGB)

Ich glaube du verhaust viel bei deinen Vergleichen. Würde dir das gerne über TS erklären oder TeamViewer auch gern noch mal zeigen.

Weil das was du da halt irgendwelche kuriosen Test machst.

Zitat von Sagaras

Weil das was du da halt irgendwelche kuriosen Test machst.

Ich nehme das selbe Input-File (ein AVS-Script) mit Farbkästen, jage es durch VirtualDub und bei VY12 (was das AVS-Script ausgibt) kommt eben danach nicht das raus, was ich reinschicke, bei RGB888 und bei Lagarith schon... was ist daran "kurios"?

Ich erwarte das ein Codec bei VirtualDub das abspeichert was ich ihm reingebe, nicht wie aktuell irgendwelche verfälschten Farben solange ich ihm nicht RGB füttere... das ist für mich eindeutig ein Bug, "Lossless" soll ja 1:1 abspeichern was ich reingebe (abzüglich Rundungsfehler) aber nicht direkt die Farben um 32 Werte zu niedrig berechnen...

Wenn ich nur unter "Labor-Bedingungen" 1:1 das rausbekomme was ich reinschicke, dann nützt mir MagicVUY nichts...

Weil du das mit der Farbmatrix vermutlich noch gar nicht verstanden hast.

Lagarith nutzt nur BT.601 für seine YUV Farbräume
MagicYUV als auch UTVideo können BT.601 als auch BT,.709 nutzen für ihre YUV Farbräume.

Und diese beeinflussen die Farben schon.

EDIT:
Kannst dich auch gerne noch mal hier durcharbeiten: Farbräume (Tutorial) - erweiterte Erklärung und Zusammenhänge

Zitat von Sagaras

MagicYUV als auch UTVideo können BT.601 als auch BT,.709 nutzen für ihre YUV Farbräume.

Zitat MagicVUY: "Color matrix to use when doing YUV <-> RGB conversion." - "NOTE: This option is not relevant when [..] compressing and decompressing only in YUV color space."

Komisch... arbeite ich in RGB (und demzufolge wird ja laut Hinweis-Text eben die Farbmatrix benutzt) sind die Farben nahezu 1:1 identisch (Option steht auf Rec.709), arbeite ich aber ausschließlich in YUV sind die Farben plötzlich falsch?

Also YUV "as-is" abgespeichert verursacht falsche Farben, RGB "converted" nach YUV behält die korrekten Farben?

Ist die Beschreibung irreführend? Sollte MagicYUV nicht einfach nur 1:1 das was ich reingebe "komprimieren" anstatt irgendwelche Farbräume umzurechnen?

// EDiT: Weiterer Test, stelle ich den (ja angeblich bei YUV nicht beachteten Farbraum) von 709 auf 601 um, schon kommt hinten das raus, was ich vorne reinstecke... WARUM steht dann aber dort "This option ist NOT RELEVANT" wenn sie ja DOCH relevant ist bei simpler YUV-Bearbeitung?

// EDiT2: Zudem fällt mir schon wieder auf das ROT um einen halben Pixel nach oben "springt", bei Lagarith ist das beim direkten Vergleich nicht der Fall, Grün und Blau sind 1:1 am selben Fleck, nur Rot "springt" eben 1/2 Pixel hoch...

Zitat von TbMzockt

Komisch... arbeite ich in RGB (und demzufolge wird ja laut Hinweis-Text eben die Farbmatrix benutzt) sind die Farben nahezu 1:1 identisch (Option steht auf Rec.709), arbeite ich aber ausschließlich in YUV sind die Farben plötzlich falsch?

RGB besitzt keine Farbmatrix. Und hat auch keinen TV Bereich an sich. Die Farben gehen immer von 0 - 255.

Jedoch kannst du RGB begrenzen lassen. Sprich ihm ein TV Bereich verpassen, sprich verblassen lassen. 16 -235. Aber wenn das passiert hast du immer noch ein RGB 0 - 255 Farbraum. Obwohl sich nun das eine RGB vom anderem unterscheidet.
Bei dir als Adobe User sollte es als Studio RGB (16 - 235) als auch Computer RGB (0 - 255) bekannt sein.

Ein YUV Farbraum errechnet seine Farbe aus RGB und Farb-Koeffizienten. Sprich der Farb-Matrix.
Diese Matrix bewegt sich in anderen Farbbereichen als RGB selbst.

Jede Matrix hat somit eine andere Farbdarstellung des Bildes.

Um einen YUV Farbraum wieder in RGB zu wandeln muss die Farbmatrix wieder entfernt werden, weil RGB nun mal keine hat.

Wie gesagt, würde es dir ja gerne mal über TS bzw. auch über TeamViewer erklären und zeigen, damit du halt auch siehst das da zwischen den Codecs die du getestet hast keine Abweichungen existieren, wenn du die richtigen Sachverhalte vergleichen tust miteinander.

Zitat von Sagaras

Ein YUV Farbraum errechnet seine Farbe aus RGB und Farb-Koeffizienten. Sprich der Farb-Matrix.
Diese Matrix bewegt sich in anderen Farbbereichen als RGB selbst.

Jede Matrix hat somit eine andere Farbdarstellung des Bildes.

Um einen YUV Farbraum wieder in RGB zu wandeln muss die Farbmatrix wieder entfernt werden, weil RGB nun mal keine hat.

Die Beschreibung dieser Farbmatrix-Option ist irreführend, da ich ein YUV-Input habe wird ja laut dem Tooltip keinerlei Farbmatrix verwendet (was dort eingestellt ist sollte demnach keinerlei Auswirkungen haben, weswegen ich diese Option beim Testen auch ignoriert habe), trotzdem ist diese Option ja relevant da man dort eben scheinbar auch ohne RGB<->YUV-Konvertierung einstellt in welcher Farbmatrix das Original gespeichert wurde damit eine beim kodieren nicht relevante spätere Umwandlung in RGB korrekt erfolgt...

Korrekt müsste diese Option also bezeichnet werden mit "bei RGB<->YUV Konvertierung benutzte Farbmatrix, relevant beim späteren dekodieren um wieder den dem Original entsprechenden Farbraum zu erhalten auch wenn beim speichern keinerlei Farbraumkonvertierung erfolgt"

Zitat von TbMzockt

YUV-Input habe wird ja laut dem Tooltip keinerlei Farbmatrix verwendet (was dort eingestellt ist sollte demnach keinerlei Auswirkungen haben

YUV hat immer eine Farbmatrix. IMMER.

Zitat von Sagaras

YUV hat immer eine Farbmatrix. IMMER.

Nur sollte darauf auch im Tooltip hingewiesen werden anstatt die Option als "not relevant" hinzustellen, was sie ja definitiv nicht ist... für jemanden der sich damit intensiv beschäftigt (wie dem Coder von MagicYUV) vllt. nicht wichtig, aber jemandem der das Thema nicht in jedem winzigen Detail kennt sollte ja eigtl. der ToolTip erklären WAS man da einstellt und WOZU es dient...

Ich zitiere mal:
"This option is not relevant when compressing RGB Inputs is-as, OR when COMPRESSING AND DECOMPRESSING only in YUV color space"

Bedeutet:
Für RGB ist sie nicht relevant, ja. Steht auch so da eigentlich in dem Tool-Tip
Für YUV ist sie nur dann uninteressant wenn du ein YUV Material durch den Encoder als Input jagen tust.
Weil ein YUV Farbraum bereits eine Farbmatrix besitzt.

Sprich würdest du ein Lagarith Video mit BT.601 da durchjagen und MagicYUV steht auf BT.709, würdest du wieder das BT.601 Video erhalten.

Lädst du es aber ein YUV Video in ein Bearbeitungsprogramm wie Adobe, oder was weiß ich, hast du ein RGB Output anzuliegen und dann trifft diese Tool-Tip Notiz nicht mehr zu.

Bei VirtualDub hast du gewiss als Ausgabe auf RGB zu stehen. Ergo wirkt das Teil, weil dein Video auf einen RGB Output an dem Encoder Input anliegt.

Nein Sagaras, wenn dann musst du das Zitieren
"Color matrix to use when doing YUV <-> RGB conversion."

Es ging aber erst mal dadrum ab wann es nicht relevant ist. Bei YUV zu RGB oder RGB zu YUV ist die Farbmatrix natürlich relevant.

Ein YUV Farbraum mit der Matrix BT.709 in einem Programm in RGB umzuwandeln was BT.601 verwendet, braucht sich der Anwender nicht wundern das da falsche Farben bei raus kommen. Somit kann man auch RGB verfälschen.