Ausblutende Schriften

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

  • Ausblutende Schriften

    Anzeige
    Hallo zusammen,

    ich bin mal wieder etwas am rumwerkeln, da ich relativ komplexe Videos (viel Vegetation, rote transparente Schriften etc.) verarbeiten möchte.
    Bislang bin ich immer noch etwas unzufrieden mit den Ergebnissen.
    Vor allem die roten Schriften bluten beim encodieren aus, was mich besonders stört.
    Zur Aufnahme verwende ich den Dxtory Codec oder wahlweise auch den Magic Codec - beide in der höchsten Qualitätsstufe (also direkt nach RGB).
    Die Rohaufnahmen sehen soweit auch ganz gut aus - Magic schneidet hier etwas schlechter ab, ist aber in Ordnung.

    Ich dachte mir, ich teste mal den VP9 Codec zum encodieren und bin gerade etwas orientierungslos.
    Was muss ich mir auf deren Seite genau runterladen um den Codec nutzen zu können?

    Kann mir jemand sagen, welche Vorteile/Nachteile der VP9 bringt?
    Kann ich ihn mit MeGUI nutzen?

    Grüße,
    Terminus

    Terminus | World of Tanks & mehr
  • VP9 braucht deutlich länger, kommt dadurch mit weniger Bitrate aus.

    Warum nutzt du den nicht YV24 zum hochladen?

    Im SSM "YV24 Konvertierung der Videos"
    Und in MeGui Config -> Misc -> Custom Command Line - > --output-csp i444

    mehr wird nicht gehen, ein anderer Codec wird da auch nichts bringen da es mit den Schriften nicht mit der Kompression zusammenhängt, sondern durch den Farbraumverlust

    P.s. Wenn du ein Testvideo gemacht hast überprüfe ob MeGui nicht in das Skript eine ConverttoYV12 rein geschrieben hat
  • Danke dir.
    Er schreibt das Skript trotzdem jedes Mal wieder um.
    Habe schon versucht die settings.xml auf schreibgeschützt zu setzen...
    Zusätzlich habe ich folgenden Fehler wenn ich im SSM Spline100 nutze (Spline16 funktioniert):


    Terminus | World of Tanks & mehr

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

  • Warum nicht YV24 in RGB konvertieren? Ich meine... so ein massiven Rundungsfehler beim Konvertieren gibt es eh nicht das man ihn wahrnehmen würde ^^

    Edit:
    Wenn MeGUI fragt ob man nach YV12 konvertieren will, sagt man nein. Danach fragt MeGUI noch mal ob der Farbraum den das Skript aussondern beibehalten werden soll. Da drückt man dann ja. Und schon bleibt das so.

    Außerdem erklärt ihr ihn wie er das abstellen kann diese Nachrichten, aber keiner hat bis jetzt gesagt das er den Encoder auch um ein paar manuelle Parameter erweitern muss, wenn er YV24 oder RGB oder YUY2 Ausgabe haben will. ;D

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

  • Sagaras schrieb:

    Wenn MeGUI fragt ob man nach YV12 konvertieren will, sagt man nein. Danach fragt MeGUI noch mal ob der Farbraum den das Skript aussondern beibehalten werden soll. Da drückt man dann ja. Und schon bleibt das so.


    So ist es jetzt bei mir.
    Ich habe heute Abend mit UT Video RGB VCM aufgenommen, bin dann im SSM auf YV24 gegangen und habe MeGUI eingestellt wie hier beschrieben wurde.
    Die Schriften bluten immer noch aus.
    Das muss doch irgendwie in den Griff zu kriegen sein. :)

    @Sagaras: Welche Parameter müssen noch geändert werden?

    Grüße,
    Terminus

    Terminus | World of Tanks & mehr

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

  • Die werden dir so oder so "ausbluten". Egal was du tust.

    Selbst Blau würde "ausbluten" / verschmieren.

    Weil YV12 nun mal nur 50% des Chrominanz gegenüber den Luminanz nutzt.

    Sprich 100% Grautöne und 50% Farbanteil. Und die sind einheitlich verteilt. Darum verschmiert das auch so.

    Einziger Weg: RGB / YV24 Aufnahme mit AVISynth über einen Punkt Skalierer 2 fach vergrößern und dann die Restanteile mit einem anderen Skalierer wie Spline100 machen.

    720p RGB/YV24 -> 1440p RGB/YV24 via Punkt Skalierer -> 1800p RGB/YV24 via Spline100 -> Encodierten Video über MeGUI mit YV24 Output.

    Resultat auf YT wäre das dünne Schriften oder Linien mit Rot oder Blau Anteilen nicht mehr extrem verlaufen. Weil im Endeffekt hast du auf YT eh wieder YV12. Aber YT würde dann immerhin von der YV24 Quelle encoden die du hochgeladen hättest.

    Terminus schrieb:

    Welche Parameter müssen noch geändert werden?

    x264 Parameter:

    für den x264 64Bit, da über Pipeline:
    Für YUY2:
    AVISynth Skript muss ein YV16 Output haben + manueller x264 Parameter: output-csp "i422"

    Für YV24:
    AVISynth Skript muss ein YV24 Output haben + manueller x264 Parameter: output-csp "i444"

    YV12 wäre Standard, brauch ich denk ich nicht auflisten ^^

    für den x264 32Bit:
    Für RGB24/32:
    AVISynth Skript muss ein RGB24/32 Output haben + manueller x264 Parameter: output-csp "RGB"

    Für YV24:
    AVISynth Skript muss ein YV24 Output haben + manueller x264 Parameter: output-csp "i444"

    Für YUY2:
    AVISynth Skript muss ein YUY2/YV16 Output haben + manueller x264 Parameter: output-csp "i422"
  • RGB ist ja auch das idealste. Aber wenn du eine RGB Aufnahme in YV12 konvertierst bei gleicher Auflösung, dann hätteste dir das mit der RGB Aufnahme sparen können. Weil dann haste Effekt = 0.

    Grund ist einfach Chromadownsampling.

    YUV Farbunterabtastung mit Verhältnisangaben und Farbqualitätswerte in %:
    4:4:4 = 1:1 = 100% (Keine Verschmierung der Farben) <- (auch RGB24, RGB32)
    4:2:2 = 2:3 = ~66% (Leichte horizontale Verschmierung der Farben)
    4:2:0 = 1:2 = 50% (Leichte horizon- und vertikale Verschmierungen der Farben)
    4:1:1 = 1:3 = ~33% (Große horizon- und leichte vertikale Verschmierungen der Farben)
    4:0:0 = 0:1 = 0% (Keine Farben)

    Das Verschmieren kann reduziert werden, indem man das Quellvideo hochskalieren lässt, damit dünne 1px breite Linien größer werden und bei einer YV12 Konvertierung nicht extrem verlaufen.

    Einen hohen Farbraum später dann auf YT hochzuladen bringt den Vorteil das YT so oder so skalieren wird. Und auch den Farbraum in YV12 ändert. In der Regel wird aber immer zuerst skaliert und dann konvertiert. Weil das einen höheren Qualitätseffekt nach sich zieht.

    Wenn man aber erst den Farbraum konvertiert und dann skaliert, kommt es zu einem Disaster wo man sich fragt: "Wieso?" ^^