Welcher Codec?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Welcher Codec?

    Anzeige
    Hay Ho Leute,

    Ich weiß das Thema wurde bestimmt schon 1000x besprochen aber ich habe keinen Thread gefunden der alle Codecs gegenüber stellt und dabei
    erwähnt welcher der "Beste" ist.

    Bis jetzt habe ich Lagartih, Matrox (MPEG-2 I frame HD) & MagicYUV benutzt.
    Nun wollte ich Fragen welcher dieser Codecs am empfehlenswerten ist und ebenfalls welcher für Youtube den besten
    "Farbraum" hat, da mir (vielleicht auch nur eingebildet) die Farben nach dem Rendern mit Vegas 13 bei Lagarith ziemlich
    dunkel vorkamen, aufgenommen wurde ARK Survival. (Rendere mit Vegas 13 in Sony AVC/MVC | AVC, 1920/1080, Cabac,
    60 FPS, 25.999.360 Bitrate in MP4)

    An den Render Settings sollte es aber nicht liegen. Habe auch versucht die Farben etwas aufzubessern durch eine minimale Farbkorrektur
    (1,2 Sättigung) und durch "Levels" (Computer RGB to Studio RGB), da diese Settings von "Jackfrags" empfohlen wurden und seine Videos immer eine sehr gute Qualität haben. An meinen PC ebenfalls nicht, da ich Problemlos mit jedem dieser Codecs mit 60 FPS+ Aufnehmen kann ohne dabei viele FPS zu verlieren meistens ca 4-5.

    Und nur um Sicherzugehen Lagarith und MagicYUV sind lossless Matrox hingegen nicht oder?

    Hier meine Settings der jeweiligen Codecs

    Lagarith
    Matrox
    Magic

    Hoffe ihr könnt mir welchen, es ist total anstrengend 1000x den Codec zu wechseln aufzunehmen zu rendern usw
    und im Internet empfiehlt jeder einen anderen Codec.

    freundliche Grüße,
    NiCeOnE
  • MPEG 2 ist selbstverständlich nicht lossless, im Gegenteil ^^


    NiCeOnE schrieb:

    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 :S
    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.
    Aktuelle Projekte/Videos




    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7
  • Kayten schrieb:

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


    De-M-oN schrieb:

    MPEG 2 ist selbstverständlich nicht lossless, im Gegenteil ^^


    NiCeOnE schrieb:

    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 :S 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.
    Habe evtl vor auf 4k hoch zu Rendern bei Vegas meinste das würde was helfen?
  • 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)
    ——YouTube————————————————————————————————————————————
    — Endlos-Projekte: Minecraft (SinglePlayer), Craft The World, Banished, Besiege, Sims4
    — ..Abgeschlossen: Leisure Suit Larry 6+7, Dishonored, Surface 2+3, Mirrors Edge, uvm
    — . Kurz- Projekte: The Tower, Fighting Is Magic, Euro Truck Simulator 2, uvm
    — ......Retro-Ecke: Day Of The Tentacle, Flight Of The Amazon Queen, NFS: HP2, uvm
    ————————————————————————————————————————————TbMzockt.de—
  • Sagaras schrieb:

    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...
    ——YouTube————————————————————————————————————————————
    — Endlos-Projekte: Minecraft (SinglePlayer), Craft The World, Banished, Besiege, Sims4
    — ..Abgeschlossen: Leisure Suit Larry 6+7, Dishonored, Surface 2+3, Mirrors Edge, uvm
    — . Kurz- Projekte: The Tower, Fighting Is Magic, Euro Truck Simulator 2, uvm
    — ......Retro-Ecke: Day Of The Tentacle, Flight Of The Amazon Queen, NFS: HP2, uvm
    ————————————————————————————————————————————TbMzockt.de—
  • 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
  • Sagaras schrieb:

    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...
    ——YouTube————————————————————————————————————————————
    — Endlos-Projekte: Minecraft (SinglePlayer), Craft The World, Banished, Besiege, Sims4
    — ..Abgeschlossen: Leisure Suit Larry 6+7, Dishonored, Surface 2+3, Mirrors Edge, uvm
    — . Kurz- Projekte: The Tower, Fighting Is Magic, Euro Truck Simulator 2, uvm
    — ......Retro-Ecke: Day Of The Tentacle, Flight Of The Amazon Queen, NFS: HP2, uvm
    ————————————————————————————————————————————TbMzockt.de—

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von TbMzockt ()

  • TbMzockt schrieb:

    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.
  • Sagaras schrieb:

    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"
    ——YouTube————————————————————————————————————————————
    — Endlos-Projekte: Minecraft (SinglePlayer), Craft The World, Banished, Besiege, Sims4
    — ..Abgeschlossen: Leisure Suit Larry 6+7, Dishonored, Surface 2+3, Mirrors Edge, uvm
    — . Kurz- Projekte: The Tower, Fighting Is Magic, Euro Truck Simulator 2, uvm
    — ......Retro-Ecke: Day Of The Tentacle, Flight Of The Amazon Queen, NFS: HP2, uvm
    ————————————————————————————————————————————TbMzockt.de—
  • Sagaras schrieb:

    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...
    ——YouTube————————————————————————————————————————————
    — Endlos-Projekte: Minecraft (SinglePlayer), Craft The World, Banished, Besiege, Sims4
    — ..Abgeschlossen: Leisure Suit Larry 6+7, Dishonored, Surface 2+3, Mirrors Edge, uvm
    — . Kurz- Projekte: The Tower, Fighting Is Magic, Euro Truck Simulator 2, uvm
    — ......Retro-Ecke: Day Of The Tentacle, Flight Of The Amazon Queen, NFS: HP2, uvm
    ————————————————————————————————————————————TbMzockt.de—
  • 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.
  • 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.