MeGUI Endprodukt verblasstere Farben

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

  • MeGUI Endprodukt verblasstere Farben

    Anzeige
    Heya!

    Nach etwas googeln vermute ich mal, dass es an dem avs Script liegt aber ich frage hier einfach mal nach. Das Endprodukt hat wesentlich blassere Farben als das Rohmaterial. Hier das script:

    Spoiler anzeigen

    Quellcode

    1. ### SagaraS Scriptmaker - Version 5.5 ###
    2. ### Lade Plugins und setze die globalen Variablen ###
    3. Global breite = 1920
    4. Global hoehe = 1080
    5. Global AR = 0
    6. ### Lade Videoquellen ###
    7. AVIload("B:\Viedo\1.avi", 0, 0, 0, -0, -0, "Auto", "Auto", 0, 0)
    8. ### Filter Verarbeitungszone ###
    9. ### Funktion für Video-Laderoutine ###
    10. Function AVIload (String file, int loading, int cl, int co, int cr, int cu, string pixtype, string afps, int fpsn, int fpsd) {
    11. (loading == 1) ? FFIndex(file) : nop()
    12. clip0 = (loading == 3) ? LWLibavVideoSource(file) : (loading == 2) ? Import(file).KillAudio() : (loading == 1) ? FFVideoSource(file, threads=1) : (pixtype == "Auto") ? AVISource(file, false).KillAudio() : AVISource(file, false, pixel_type=pixtype).KillAudio()
    13. rate1 = (afps == "Auto") ? (Round(Float(clip0.framerate * 1000)) / 1000) / 2 : nop()
    14. rate2 = (afps == "Auto") ? Round(clip0.framerate) / 2 : nop()
    15. rate = (afps == "Auto") ? (rate1 == rate2) ? 1 : 1001 : (afps == "Igno.") ? clip0.frameratedenominator : fpsd
    16. ratefaktor = (afps == "Auto") ? (rate == 1001) ? 1000 : 1 : nop()
    17. clip1 = (afps == "Auto") ? (rate == 1001) ? clip0.AssumeFPS(Round(clip0.Framerate) * 1000, rate) : clip0.AssumeFPS(round(clip0.framerate), rate) : (afps == "Igno.") ? clip0.AssumeFPS(clip0.frameratenumerator, rate) : clip0.AssumeFPS(fpsn, rate)
    18. clip1 = (clip1.IsRGB32() == True) ? clip1.ConvertToRGB24() : clip1
    19. clip1 = (cl != 0) ? clip1.Crop(cl, co, cr, cu) : (co != 0) ? clip1.Crop(cl, co, cr, cu) : (cr != 0) ? clip1.Crop(cl, co, cr, cu) : (cu != 0) ? clip1.Crop(cl, co, cr, cu) : clip1
    20. clip1 = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? ((float(Clip1.height * breite) / clip1.width) / 2 == round((float(Clip1.height * breite) / clip1.width) / 2)) ? ((float(Clip1.width * hoehe) / clip1.height) / 2 == round((float(Clip1.width * hoehe) / clip1.height) / 2)) ? clip1 : clip1.ConvertToRGB24(matrix = "Rec709") : clip1.ConvertToRGB24(matrix = "Rec709") : clip1
    21. clip1 = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? (((clip1.width * hoehe) / clip1.height > breite) ? Clip1.Spline64Resize(breite, ceil(float(Clip1.height * breite) / clip1.width)) : Clip1.Spline64Resize(ceil(float(clip1.width * hoehe) / clip1.height), hoehe)) : clip1.Spline64Resize(breite, hoehe).ConvertToYV12(matrix = "Rec709", ChromaResample = "Spline64")
    22. back = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? (afps == "Auto") ? (0 == 1) ? ImageReader("", 0, clip1.framecount - 1, clip1.framerate).ChangeFPS(round(clip1.framerate) * ratefaktor, rate).Spline64Resize(breite, hoehe).ConvertToYV12(matrix = "Rec709", ChromaResample = "Spline64") : BlankClip(clip1.framecount, breite, hoehe, "YV12", round(Clip1.framerate) * ratefaktor, rate).KillAudio() : (0 == 1) ? ImageReader("", 0, clip1.framecount - 1, clip1.framerate).ChangeFPS(clip1.frameratenumerator, clip1.frameratedenominator).Spline64Resize(breite, hoehe).ConvertToYV12(matrix = "Rec709", ChromaResample = "Spline64") : BlankClip(clip1.framecount, breite, hoehe, "YV12", clip1.frameratenumerator, clip1.frameratedenominator).KillAudio() : clip1
    23. Return (clip1.width == breite && clip1.height == hoehe) ? clip1.ConvertToYV12(matrix = "Rec709", ChromaResample = "Spline64") : (AR == 1) ? Overlay(back, clip1, (back.width - clip1.width) / 2, (back.height - clip1.height) / 2) : clip1
    24. }
    Alles anzeigen


    Die einstellungen für den x264 sind folgende:

    Quellcode

    1. program --preset slow --crf 18.0 --bframes 5 --partitions all --output "output" "input"


    Wobei die crf sonst auf 21 stehen. War jetzt nur zum ausprobieren ob es daran liegt.

    Des weiteren wird das Video als .mkv ausgegeben und im VLC Mediaplayer abgespielt. Aber auch fertige Videos auf YouTube sind etwas blasser.

    Grundsätzlich wäre es zwar etwas für SagaraS Thread, da ich aber glaube, dass es recht unabhängig vom Scriptmaker ist, da ja jeder die selben befehle verwendet habe ich mich dazu entschlossen einen eigenen thread zu eröffnen.

    Edit: Ich habe mir das ganze nun noch einmal mit dem MPC-HC player angesehen und dort sieht es auch recht grauenvoll aus.

    Hier mal ein paar screens zum vergleich: >>KLICK<<

    Der Unterschied ist auf den Screens zwar nicht so groß, da auch die Originaldatei nicht die optimale Qualität hat aber gerade bei "stechenderen" Farben wie Grün sieht es im MPC-HC doch sehr schrill und schon fast blendend aus.

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

  • Der VLC Player und auch Chrome spielen die Videos in Fullrange Bereich (PC-Bereich) (0 - 255)
    Der MPC-HC jedoch stellt sich auf das Video ein sofern EVR genutzt wird als Video-Renderer.
    Sprich der nutzt je nach Video den Beschränkten Bereich (TV-Bereich) (16 - 235) und den Fullrange Bereich.

    Deine encodierten Videos liegen als TV Bereich Material vor. Selbst die Aufnahmen an sich werden oftmals schon als TV Bereich gespeichert.

    Es sei denn man nimmt direkt PC-Bereich.

    Du kannst den PC-Bereich ruhig verwenden beim aufnehmen und encodieren, jedoch werden alle Firefox User oder auch andere Internetuser wie die die eine PS3 etc. nutzen ein sehr dunkles Bild erhalten, da die meisten auf TV-Bereich arbeiten. Was auch logisch ist. Jeder Film der zu erhalten ist, ist in TV-Bereich codiert.

    Fazit: Belass es auf TV-Bereich und verwende nicht solche Player wie VLC oder wie es Chrome nutzt auf YT.

    VLC (Standard eingestellt) und auch Chrome haben Standardmäßig einen PC-Bereich Player wo dann dein codiertes TV-Bereich Video abgespielt wird. Resultat ist das das Video blasser aussieht.
  • Ich vermute, ich verstehe die Problematik. Ich habe das Video nun auf YouTube hochgeladen und dort wird es mir ähnlich blass wie in der VLC Preview angezeigt. Sowohl in Chrome wie auch Firefox und Opera. Sowohl auf meinem PC, Laptop wie auch Smartphone. Des Weiteren wird die Schrift die man auf dem Desktop sieht in kleineren Auflösungen bzw. Bildschirmen als 1920x1080 sehr unklar definiert und sie wirkt teils etwas verzerrt.

    Es fällt mir gerade mehr als schwierig das ganze zu reproduzieren, da ich doch schon etwas länger nicht mehr in dem Bereich tätig war und eigentlich gewohnt bin, dass das Standard Script von Sagaras in Kombination mit den Standard Einstellungen des x264 die gewünschte Qualität hervorruft.

    Screencapture mache ich mit OBS wobei da wie schon erwähnt das Rohmaterial auch nicht die super Qualität hat aber DXTory kann soweit ich weiß den Desktop ja nicht aufnehmen. Anyways finde ich es sehr merkwürdig, dass das Endprodukt anders aussieht. Das Einzige was dazwischen liegt wäre Sony Vegas und selbst in der Preview dort sieht es noch super aus.
  • OBS kann auch PC Range. Je nach dem was der macht.

    Aber OBS nimmt eh nur Lossy auf.

    Vegas kann natürlich ebenso schuld sein. Würde schon mit falschen Projekteinstellungen losgehen. Vegas konvertiert dein Video erstmal eh zu RGB32. Daher sollte bei Vegas via Frameserver sogar RGB32 oder RGB24 gewählt werden statt YUY2, da halt Vegas grundsätzlich immer als RGB konvertiert. Und das konvertieren nimmt natürlich auch wieder qualität. Daher wäres besser Vegas wegzulassen.

    Verlustfreie Desktopaufnahme ist mit Afterburner möglich.
    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
  • Anzeige
    Paar Randinfos für den TE:
    Youtubes HD Videos nutzen eine Farbmatrix von BT.709
    Daher sollten alle Videos am besten schon in BT.709 aufgenommen, in der NLE verarbeitet und auch beim Encodieren in diese Farbmatrix geschehen.

    Sollte mit BT.601 aufgenommen worden sein, sollte man eine Konvertierung in Betracht ziehen.
    Dieser kleiner Unterschied bei den Farbmatrizen kann man hier ersehen:
    forum.doom9.org/showthread.php?p=1623418#post1623418

    Dann ist es Üblich Videos im TV-Bereich zu Handhaben.
    1. werden Videos dadurch kleiner, da eingegrenzter Farbbereich
    2. Viele Endgeräte die mit YT zusammenarbeiten laufen mit einem TV-Bereich Player.

    Fazit: Chrome stellt die Videos so oder so zu hell dar, da Chrome hier z.B. einen PC-Bereich Player nutzt.

    Bei Firefox kann dies eventuell auch geschehen sofern der H264 Player statt der Flash Player genommen wird. Der H264 Player wird mal wieder von Google angeboten in diesem Fall (Als ob die das irgendwie nicht ganz raffen das die Masse von Videos TV-Bereich Videos sind. Aber so ist Google nun mal. Siehe Chrome.)


    PC-Bereich = 0 - 255
    TV-Bereich = 16 - 235

    BluRays, DVDs sowie anderswo was mit Videos zu tun hat arbeiten meist alle mit einen TV-Bereich.
    Als Beispiel: Wenn ich mit meinen Handy auf Youtube gehe und mir ein TV-Bereich Video anschaue, dann sind die Farben korrekt.
    Jedoch wenn ich mir ein PC-Bereich kodiertes Video anschaue sind die Farben arg dunkel und entsprechen nicht mehr den originalen Farben. In diesem Falle würde es in Chrome aber korrekt aussehen.

    Jetzt bist du aber gefragt: Willst du in PC-Bereich umwandeln bzw. kodieren lassen oder es in TV-Bereich belassen?

    Bedenke das viele Firefox User, sowie PS3, PS4 und auch Handy und Tablet User die PC-Bereich kodierten Videos erheblich Verdunkelt dargestellt bekommen würden.
    Damit würde dir unter Umständen eine Erhebliche Anhängerschaft an Zuschauern durch die Lappen gehen.

    Mein Rat: Belasse es auf TV-Bereich und nutze (da x264 es eh so kodiert) die BT.709 Farbmatrix. Am besten schon bei der Aufnahme.

    Auch in deiner NLE wäre das wichtig irgendwo anzugeben.

    Alternativ kann man die Farbmatrix auch konvertieren lassen mit dem SSM. Dafür gibt es unter dem Bereich Farbe die Funktion "ColorMatrix".
    Aktivieren und den Mode auf "Rec.601 -> Rec.709" stellen dann.
  • Sagaras schrieb:

    Fazit: Chrome stellt die Videos so oder so zu hell dar, da Chrome hier z.B. einen PC-Bereich Player nutzt.


    Gibts aber eine Lösung für:

    forum.doom9.org/showpost.php?p=1702401&postcount=180

    Sprich in die Nvidia Systemsteuerung und dann zu Video-Farbeinstellungen anpassen, dort auf Nvidia Settings stellen und dann bei tab erweitert auf pc range einstellen. Dann spielt Chrome korrekt ab und sogar der VLC kriegts dann auf die Reihe.
    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
  • @De-M-oN
    Warum sollte ich der Grafikkarte extra sagen das diese es korrekt darstellen soll, wenn es der Player allgemein nicht hinbekommt? ;D

    Da steht das es vom Player die Einstellungen nehmen soll. Also ist das Fazit das die Player nicht korrekt arbeiten wie sie sollen. Warum sollte der MPC-HC denn das sonst korrekt machen oder Firefox ohne das man an der Grafikkarte was umstellen muss?

    Ich meine... klar, ist ne Lösung das dort umzustellen, aber eigentlich sollte dies nicht von Nöten sein. Vor allem man das immer wieder umstellen müsste. Weil... wenn ich das Ding umstelle, spielen einige Spiele (Darunter auch Bink Player) meine GameVideos in PC-Range ab und die eigentlich hätten TV sein müssen. Resultat ist das die Videos arg zu dunkel werden.
    Theoretisch müsst ich das an der Grafikkarte jedesmal dann umstellen für den Kram. Wäre mir persönlich zu blöd irgendwo ^^ Soll doch VLC ihren Player korrekt einstellen und auch Chrome das korrekt lösen, anstatt das der User an der Grafikkarte erst umstellen muss.

    Edit:
    Außerdem sollteste ja auch so langsam wissen das es in diesem Falle keine 100%tige Lösung für gibt. Gerade was das mit den Internet Explorern angeht. Und ich denke mal auch sofern du die Grafikkarte für Player die Range änderst, kannste 100% davon ausgehen das andere Player darauf ebenfalls wieder betroffen sind. Ein TV-Bereich Player mit PC-Bereich darzustellen von der Grafikkarte ist dann wirklich arg dunkel dann ^^ Das kann bei Games dann wieder auftreten die Bink Videos nutzen oder Smacker oder was weiß ich. LucasArts Games haben auch Zwischensequenzen die dann Arg zu dunkel werden.

    Ist wirklich wie ich dann gesagt habe das man diese Einstellung in der Grafikkarten Konfi immer wieder hin und her switchen müsste. Und das wäre auf Dauer keine so schöne Lösung. Vor allem da die User eh zu Faul sind oft.

    Zum anderen: Stell dir vor das Video wird im Spiel zu dunkel dargestellt und der User regt sich dann auf wenn das Video auf einmal etwas heller ist nach der Aufnahme. Sollte dann zu denken geben glaub ich ;D

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Sagaras ()

  • Naja wenn du es in Grafikkarte festlegst haste in der Hinsicht keine Probleme mehr. Und bei Software wo es so oder so geht, haste ebenso weiterhin keine Probleme, also von daher doch eine win-win geschichte.

    Hastes getestet schon mit dem Player? Also hab den Player jetzt nicht, aber meine Spiele und MPC-HC laufen unverändert.
    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
  • De-M-oN schrieb:

    Sprich in die Nvidia Systemsteuerung und dann zu Video-Farbeinstellungen anpassen, dort auf Nvidia Settings stellen und dann bei tab erweitert auf pc range einstellen. Dann spielt Chrome korrekt ab und sogar der VLC kriegts dann auf die Reihe.
    Ich danke dir :D perfekt :D Endlich keine ausgewaschenen Videos mehr :D
  • Um noch einmal auf das ganze zurück zu kommen. Da ich nur an eine 16k Leitung heran komme ist natürlich die Dateigröße des Endprodukts entscheident. Wie @De-M-oN schon anmerkte, konvertiert Vegas sowieso immer zu RGB32. Wenn ich meinen Workflow nun anpassen will habe ich unterschiedlichste Schritte in denen die Aufnahme anders kodiert werden könnte.

    Grundsätzlich hätte ich gern ein Endprodukt welches in 1080p 60fps ist und möglichst nicht in irgend etwas anderes konvertiert sondern einfach möglichst konvertiert mit guter qualität wird.

    Aktuell habe ich folgende wohl mehr als stupide settings:

    Quellcode

    1. Dxtory:
    2. Codec: Lagarith Lossless Codec
    3. Use Multithreaing
    4. Mode: YUY2
    5. Sony Vegas Frame Server:
    6. Format: YUY2
    7. @'Sagaras' Script Maker:
    8. Farbraum: YV12 Konvertierung der Videos
    9. avs5x264mod YUY2/YV16 Fix
    10. MeGUI:
    11. x264 program --preset slow --crf 21.0 --bframes 5 --partitions all --output "output" "input"
    12. File format: MKV
    Alles anzeigen


    Ich gehe mal davon aus, dass ich mit diesen Settings ein "besseres" Ergebnis erreichen werde:

    Quellcode

    1. Dxtory:
    2. Codec: Lagarith Lossless Codec
    3. Use Multithreaing
    4. Mode: RGB oder RGBA (?)
    5. Sony Vegas Frame Server:
    6. Format: RGB24(?)
    7. @'Sagaras' Script Maker:
    8. Farbraum: Versuchen ohne Konvertierung als RGB 24 auszugeben. (ist es "normal", dass es hier kein RGB 32 gibt?)
    9. MeGUI:x264 program --preset slow --crf 21.0 --bframes 5 --partitions all --output "output" "input"
    10. File format: MKV
    Alles anzeigen


    letzteres habe ich soweit glaube ich schon ausprobiert, bekam dann aber beim einfügen des scripts in MeGui die "Fehlermeldung", dass die Datei nicht in YV12 umgewandelt wird und, dass ich jenes dann manuell machen müsste, wenn ich es nicht hinzugefügt haben möchte.

    Letztendlich weiß ich aber noch nicht so recht wie ich nun bestimme ob das Video im Endeffekt den TV bzw. PC Farbraum unterstützt.
  • Um ein Video für YT zu encodieren braucht es kein Alphakanal. Ist also etwas daneben.
    Aufnahmen von Spielen brauchen auch kein Alphakanal. Ist also dort auch etwas daneben.

    Sprich RGB32 oder auch RGBA genannt fällt für beide Sachen totall flach. Den Alphakanal, sprich die letzten 8Bit werden für Transparenzfarben genuzt. Wie gesagt ist das für die Aufnahme und für YT irrelevant.

    RGB24 jedoch oder aber auch YV24 sind Farbräume die gestochen Scharf sind. Wenn du dich an die beiden hälst ist das schon mal sehr gut.
    RGB24 nach RGB32 und zurück zu konvertieren = 0 Qualitätsverlust.
    YV24 nach RGB24/RGB32 oder zurück = 0 Qualitätsverlust

    xCiiD schrieb:

    letzteres habe ich soweit glaube ich schon ausprobiert, bekam dann aber beim einfügen des scripts in MeGui die "Fehlermeldung", dass die Datei nicht in YV12 umgewandelt wird und, dass ich jenes dann manuell machen müsste, wenn ich es nicht hinzugefügt haben möchte.

    Du musst das dem x264 Encoder auch sagen das er eine RGB Matrix nutzen soll.

    Im SSM musst du dem Video sagen das er es in YV24 konvertieren soll, weil in MeGUI der avs4x264mod nur YV24, YV16 und YV12 unterstützt als Pipeline. Sprich das Skript wird für den 64Bit x264 Encoder erst an die Pipeline avs4x264mod durchgeschickt, damit der 64Bit Encoder das Skript verarbeiten kann. Weil das Skript läuft nun mal auf 32Bit und der Encoder auf 64Bit.

    Beim 32Bit x264 Encoder wird der avs4x264mod nicht benötigt und braucht daher keine spezielle Farbkonvertierung.

    Nur der 64Bit Encoder nutzt die Pipeline. Und da musst du das Video halt in die folgende Farbräume konvertieren:
    YV24 = YUV444 = Farbunterabtastung 4:4:4
    YV16 = YUV422 = Farbunterabtastung 4:2:2 (YUY2 ist auch ein YuV422) (Daher der FIX im SSM. Der bewirkt das YUY2 Aufnahmen in YV16 konvertiert werden, damit die Pipeline das korrekt an den Encoder schickt.)
    YV12 = YUV420 = Farbunterabtastung 4:2:0

    Dem x264 Encoder musst du dann noch angeben als Parameter:
    --output-csp "RGB"
    YUV444 (YV24) mit RGB Matrix

    --output-csp "i444"
    YUV444 (YV24)

    --output-csp "i422"
    YUV422 (YUY2)

    --output-csp "i420"
    Ist Standard für YUV420 (YV12)

    Dann wird das Video in diesen Output auch konvertiert korrekt.

    Beachte aber bitte jeden Schritt. Wenn du was falsch machst, siehst du das in der Log des Encodiervorganges.
    Wenn du dir nach dem Encodings nicht sicher bist ob es geklappt hat, einfach mal die komplette Log des jeweiligen Encodes posten. ^^

    xCiiD schrieb:

    Letztendlich weiß ich aber noch nicht so recht wie ich nun bestimme ob das Video im Endeffekt den TV bzw. PC Farbraum unterstützt.

    MagicYUV kann sowohl PC als auch TV Range aufnehmen. Lagarith nimmt glaub ich nur TV Range.
  • Sagaras schrieb:

    Lagarith nimmt glaub ich nur TV Range.


    Der machts das übliche. RGB = PC Range, YUV = TV Range.

    Jedoch alles in 601. Daher würd ich auf MagicYUV umsteigen. Ist eh performanter.

    MagicYUV - Ein neuer Lossless Codec!
    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
  • Holy moly..

    Wenn ich das soweit richtig verstanden habe, kann ich in dxtory MagicYUV in YUV 4:4:4 (YV24), rec709 color matrix aufnehmen was dann RGB24 entspricht. Somit wähle ich in Sony vegas dann bei dem Framserver RGB 24 was mich im endeffekt direkt zum SSM bringt. Dort sagtest du ja, dass RGB24 <-> YV24 0 Qualitätsverlust ist somit kann ich es auf YV24 Konvertierung der Videos belassen da es von MeGUI gefordert wird. Dann haben wir im Grunde YV24 Originaldatei -> RGB24 Vegas Frameserver.avi -> YV24 MeGUI endprodukt.mkv

    Somit kann ich den avs4x264mod fix deaktivieren und bei der Farbmatrix kann ich dann auch deinem Rat nachkommen und es bei TV.709 belassen, da die Originaldatei noch in jener sein sollte, wenn vegas daran nichts geändert hat.

    Sofern ich dir folgen konnte bleibt lediglich die Frage ob ich nun:

    --output-csp "RGB" oder --output-csp "i444" in MeGUI unter x264 config -> Misc -> Custom Command Line eintrage. Tendenziell würde ich jetzt sagen, RGB, da die sony vegas datei ja als RGB 24 ausgegbeen wurde. Oder ob ich das komplett so belasse und unter Misc-> V.U.I die range auf TV und die Color Matrix auf bt709 stelle sofern jenes, dem 709 aus TV.709 entspricht. (ist nur eine vermutung)

    Ich hoffe ich wirke nicht total inkompetent, ich versuche das wirklich zu verstehen >.<.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von xCiiD ()

  • Sagaras schrieb:

    Soviele Rundungsfehler kannste gar nicht sehen. Um die zu sehen müssteste das Ding gut 1000 mal hin und her konvertiert haben. Macht aber gewiss keine Sau auf der ganzen weiten Welt ;D


    Rundungsfehler sind Rundungsfehler...
    Auch wenn es gering ist. etwas geht verloren, also nicht 0 Qualitätsverlust ;)

    Wenn du mit Vegas arbeitest, nehme direkt in RGB 24 auf.
    Jetzt ist die frage was für Youtube bessere ist...
    RGB 24 oder YV24... was das nicht so das es bei RGB 24 eine andere Colormatrix dann gab?
  • GelberDrache92 schrieb:

    Rundungsfehler sind Rundungsfehler...
    Auch wenn es gering ist. etwas geht verloren, also nicht 0 Qualitätsverlust


    Quatsch. Den Rundungsfehler musste mir erst mal zeigen. Am besten am Framebild selbst wo sie auftauchen ;D
    Bei zig Konvertierungen kann das eventuell irgendwann sich mal zeigen, aber so ist da 0 Qualitätsverlust. Und ihr konvertiert die Teile nicht mal 2 mal. xD

    xCiiD schrieb:

    Somit kann ich den avs4x264mod fix deaktivieren

    Warum? Lass doch das Ding an, stört dich das denn? Der ist doch eh nur aktiv wenn es sich um ein YUY2 Video handeln sollte. Ansonsten ist das Ding aus. Auch wenn du es im SSM aktiviert hast. Betrifft wie gesagt nur YUY2 Quellen die dann zu YV16 konvertiert werden. Sprich von einem YUV422 zum anderen YUV422 Format. (@De-M-oN Auch hier entstehen Rundungsfehler bei wenn du das konvertieren tust. Ändert aber am Bild nix. Höstens beim 1000 Konvertierungsversuch xD Weil das halt so geringfügig dann ist, das es totaler Schachsinn ist es erwähnt zu werden.)

    xCiiD schrieb:

    Sofern ich dir folgen konnte bleibt lediglich die Frage ob ich nun:

    --output-csp "RGB" oder --output-csp "i444" unter x264 -> Misc -> Custom Command Line eintrage. Tendenziell würde ich jetzt sagen, RGB, da die sony vegas datei ja als RGB 24 ausgegbeen wurde. Oder ob ich das komplett so belasse un unter Misc-> V.U.I die range auf TV udn die Color Matrix auf bt709 stelle sofern jenes, dem 709 aus TV.709 entspricht. (ist nur eine vermutung)

    Dein Video haste mit YUV444 aufgenommen dann und bringst es nun in RGB32 in deiner NLE, dann schickst du es als RGB24 via Frameserver raus und musst es Zwangsweise wenn du x264 nimmst in ein YUV Farbformat konvertieren.

    Rein Theoretisch müsstest du RGB Matix nutzen, da deine NLE sowie der Frameserver RGB nutzen. Aber dein Video wird und muss in YV24 umkonvertiert werden, damit es durch die Pipeline laufen kann für den 64Bit Encoder. Das heißt das du reintheoretisch gleich nur in i444 encodieren kannst.
  • *sabber* äääähh.. ._.

    *kopfkratz*

    Darf ich nun davon ausgehen, dass es jacke wie hose ist ob ich nun in RGB oder YV24 aufnehme wenn es in vegas eh umgewandelt wird?

    Also bisher hab eich MagicYUV YV24 -> Frameserver RGB 24 -> SSM YV24 -> MeGUI dann wohl auch YV24. Sowohl in MagicYUV wie auch SSM steht die color matric auf Rec.709. Nur beim x264 von MeGUI steht noch nichts in der Custom Variable bzw. ist die colormatrix und die range nicht ausgewählt.

    Letztendlich wäre letzteres, sofern der rest passt die letzte offene Frage.
  • xCiiD schrieb:

    Darf ich nun davon ausgehen, dass es jacke wie hose ist ob ich nun in RGB oder YV24 aufnehme wenn es in vegas eh umgewandelt wird?

    Jap. Darfst dich bei deiner NLE bedanken ^^

    xCiiD schrieb:

    Also bisher hab eich MagicYUV YV24 -> Frameserver RGB 24 -> SSM YV24 -> MeGUI dann wohl auch YV24. Sowohl in MagicYUV wie auch SSM steht die color matric auf Rec.709. Nur beim x264 von MeGUI steht noch nichts in der Custom Variable bzw. ist die colormatrix und die range nicht ausgewählt.


    x264 wird das so oder so in BT.709 konvertieren Standardgemäß wenn es sich um ein HD Video handelt. Das heißt das alle Videos ab 720p+ alle in BT.709 encodiert werden. (Ist ein Defaultwert)

    BT.709 aufnehmen, im SSM dann nix weiter machen an der Farbmatix (Also Standard belassen bei Farbe) und dann sollte x264 so oder so auch in BT.709 encodieren.