x264 Banding ... Verständnisfrage

    Offensichtlich hast du nicht verstanden, dass Banding entsteht, weil die Abstufung/Auflösung der digitalen Pegel nicht fein genug ist. Das lässt sich eben nur mit höherer Bitrate oder feinerer Matrix (10 bit) bekämpfen. Es gibt keine Wunder. Oder man setzt dem Video künstliches Rauschen/Korn zu, was die Bitrate auch wieder stark in die Höhe treibt - so bei kommerziellen Blu-rays.
    CRF 18 ist bei solchen Poblemen auch noch nicht genug (PSNR ca. 45 dB), ab CRF 16 kommt man dem Original schon bedeutend näher. Bei Blu-rays gehen die Hersteller sogar noch weiter runter, um Reserven zu haben, was zu den entsprechenden Dateigrößen führt.

    Du kannst auch mal den Abfall der Qualität in den P/B-Frames verringern: Quantizers Ratio auf 1,2/1,1 oder 1.0... Dies ist die Hauptursache für schlechtere Abstufung/Quantisierung. Die GOP auch auf 1-2 s verkürzen.
    Trifft es nur wenige Stellen, kann man auch mit Zones arbeiten, dann bleibt der Rest unverändert.
    Dazu CRF 16 und das Banding sollte auch bei 8 bit in den Griff zu kriegen sein.

    Doch doch ... ich hab schon verstanden wo das herkommt. Aber nur mehr Bitrate draufhauen oder den Encoder zu zwingen die Bitrate zu verlagern (gradfun) bringts für sich alleine nämlich leider nicht.
    Ich hab mal sämtlich Kombi's probiert und bin zu folgenden Ergebnissen gekommen:

    a) mit gradfun tausch ich massives banding gegen geringes blocking, was zu mehr Bitrate führt
    b) ohne aq-strenght 1.5 passiert rein garnix
    c) ohne qcomp 0.7 greift es nur, wenn sich die Bänder nicht bewegen
    d) ausschließlich in 10-bit encoden (ohne qcomp und aq-strength) bringt nur weniger Bitrate, aber dieselben Artefakte wie mit 8-bit
    ***wobei ich sagen muss, das die Farben wesentlich natürlicher und nontrastreicher wirken ... das sieht viel "lebendiger" aus
    e) die Kombination aus 10-bit, qcomp 0.7 und aq-strength führt zu einem 90%igen Ergebnis bei nahezu gleicher Bitrate

    Wenn ich so sachen mache, wie auf CRF 16 zu gehen, bekomme ich lange nicht das geniale Bild von e) ... jedoch eine wesentlich größere Datei.

    Ich persönlich habe mich entschieden und sch**ß auf die kompatibiltät ... obwohl ich außer meinem Monitor eigentlich garkein Gerät habe, was die Detail und Farbvorteil darstellen kann :)

    Die Tage probier ich das noch mit Youtube aus und dann mach ich mich auf den steinigen Weg den VLC 2.0.8 mit meiner uralten dBox zu vermählen ... sonst kann ich den Film nämlich momentan nicht am TV glotzen :)

    Zitat von TheGenesis

    d) ausschließlich in 10-bit encoden (ohne qcomp und aq-strength) bringt nur weniger Bitrate, aber dieselben Artefakte wie mit 8-bit

    Dann reden wir aber nicht mehr von Banding?!

    Zitat von TheGenesis

    ***wobei ich sagen muss, das die Farben wesentlich natürlicher und nontrastreicher wirken ... das sieht viel "lebendiger" aus

    Beachte, daß viele Player bei 10 Bit automatisch Rec.709-Farben erwarten. Überprüfe das arbeite ggf. mit ColorMatrix() vor.

    Zitat von sneaker2

    Dann reden wir aber nicht mehr von Banding?!

    Naja ... manche Banding-Artefakte haben wesentlich kontrastreichere/harte Übergänge als andere ("normale").
    Ich denke das liegt am schwer verrauschten Quellmaterial ... Neat muss da z.T. ziemlich aggressiv filtern und das Ergebnis sieht zwar aus wie banding, ist aber (wegen dem "harten" Rand) eigentlich nur noch eine Aneinanderreihung von "Scheiben".
    Da hab ich auch nicht viel mehr erwartet, als das es bei höherem aq nur nicht mehr ganz so stark verblockt wird.

    Aber ohne aq 1.5 bleiben die wirklichen bandings nahezu unangetastet und mit 1.5 sind sie kaum noch zu erkennnen.

    Zitat von sneaker2

    Beachte, daß viele Player bei 10 Bit automatisch Rec.709-Farben erwarten. Überprüfe das arbeite ggf. mit ColorMatrix() vor.

    Wie meinen?

    Ich hab gerade noch ein Phänomen entdeckt.
    Wenn ich im Script nach YV12 wandle, ist der Output ebenfalls völlig daneben.

    Eingang kommt mit BT.709 und wird dann nach RGB32 umgewandelt.

    Jetzt wollte ich einen depan() dahintersetzen und hab davor nach YV12 (ohne Colormatrix) gewandelt ... Ergebnis ist schlecht ... hab ich jetzt damit den Farbraum halbiert?

    Wenn ja, was mach ich denn da, wenn ich noch ein paar Filter anwenden will, die YV12 oder YUY2 brauchen?

    YV24 machts übrigens total kaputt und nach YV12 mit BT.709 bringt garnix ... wo ist der Denkfehler?

    Wie sieht das Script aus, was ist die Source, welche Versionen welcher tools werden verwendet.

    Zitat

    Ergebnis ist schlecht


    Das heißt jetzt was?

    Zitat

    YV24 machts übrigens total kaputt und nach YV12 mit BT.709 bringt garnix ... wo ist der Denkfehler?


    die Annahme das hier nur Gedankenleser mitlesen :)

    Sorry ... jetzt hab ich das Script nochmal komplett zerlegt und nur mit den ConvertXYZ() verglichen.

    Eine Quelle der Artefakte ist wie bereits erwähnt das starke filern vom Neat.
    Die sind jedoch noch minimal/vertretbar.

    Die zweite Quelle für Banding-Artefakte hatte ich bisher völlig übersehen ... natürlich (im nachhinein :) ) geht das in die Hose, wenn ich von RGBA nach YV12 konvertiere.
    Dabei entstehen bereits sehr starke Artefakte.

    Wenn ich jetzt den qcomp und den aq-strenght weglasse, tut der x264 in Ermangelung von Bitrate für die Details sein letztes.

    Ich habe wohl zuviel hin und her experimentiert und dabei die Farbraumkonvertierung völlig ignoriert ... jaja ... wenn man vorher ausschließlich mit SD rumgehempelt hat, weiß man das halt nicht.

    Ich würde liebend gern den ein oder anderen Filter beim bearbeiten verwenden, aber viele von denen mögen kein RGB ... mit Dither_convert_rgb_to_yuv(matrix="601") sind die Artefakte weg, aber ich finde die Farben und der Kontrast sind jetzt viel blasser.

    Das Script sieht momentan so aus:


    Soll ich das "anders" nach YV12() konvertieren oder am Ende wieder hochsamplen?
    Bringt wahrscheinlich nix, weil die Farbinfo's dann eh schon weg sind, oder?

    Was auch ziemlich weh tut, ist der Performanceeinbruch beim depan() ... krieg ich den horizontalen jitter aus der Normwandlung (bereits in der Quelle) evtl. anders wieder raus ohne den Farbraum zu beschneiden?

    nur mal so am Rande:
    a. Warum AssumeFPS(25) ?
    b. Sicher das es nicht cleverer wäre was anderes als NeatVideo zu verwenden?
    c. Warum verwendest Du nicht Stab() anstatt den Inhalt des Skripts da reinzukopieren?
    d. Warum verwendest Du Dither überhaupt?
    e. Würde empfehlen mal über Avisynth MT nach zu denken,... (zumindest Stab wird dadurch wesentlich flotter)

    Zitat von TheGenesis

    mit Dither_convert_rgb_to_yuv(matrix="601") sind die Artefakte weg, aber ich finde die Farben und der Kontrast sind jetzt viel blasser.

    Wie gesagt: bei 10 Bit erwarten viele Player Rec.709-Farben. Wenn Du sie mit Rec.601 fütterst, werden die Farben entsprechend verfälscht. Kommt jetzt noch darauf an, was für Farben Deine Quelle überhaupt liefert:

    Falls Quelle Rec.601:
    #sourcefilter, trim, crop
    Dither_convert_yuv_to_rgb(matrix="601", mode=0)
    #neat
    Dither_convert_rgb_to_yuv(matrix="709", mode=0)
    #rest

    Falls Quelle Rec.709:
    #sourcefilter, trim, crop
    Dither_convert_yuv_to_rgb(matrix="709", mode=0)
    #neat
    Dither_convert_rgb_to_yuv(matrix="709", mode=0)
    #rest

    Am besten dann auch die x264-Ausgabe entsprechend mit --colormatrix bt709 (--colorprim bt709 --transfer bt709) kennzeichnen. Falls Du mit 8 Bit Encoding arbeitest, am besten Rec.601-Ausgabe für SD und Rec.709-Ausgabe für HD anpeilen. So erreicht man die größtmögliche Kompatibilität.

    Anstelle der Dither-Varianten erfüllen die AviSynth-eigenen ConvertToXYZ in diesem Fall eigentlich dieselben Funktionen (siehe Punkt d. in Selurs Beitrag). Hatte mit denen aber komischerweise letztens auch Artefakte? Muß ich mir vielleicht noch mal genauer anschauen...

    4 Mal editiert, zuletzt von sneaker2 (11. September 2013 um 16:20)

    Zitat von LigH

    Das zu beurteilen, ist mit Blick auf ein Stück Quelle sicher leichter... Wenn mir der Link entgangen ist, entschuldige bitte.

    Ne, hab noch nichts hochgeladen. Mach ich die Tage noch.

    Zitat von Selur

    nur mal so am Rande:
    a. Warum AssumeFPS(25) ?
    b. Sicher das es nicht cleverer wäre was anderes als NeatVideo zu verwenden?
    c. Warum verwendest Du nicht Stab() anstatt den Inhalt des Skripts da reinzukopieren?
    d. Warum verwendest Du Dither überhaupt?
    e. Würde empfehlen mal über Avisynth MT nach zu denken,... (zumindest Stab wird dadurch wesentlich flotter)

    a) weil die Quelle 23.976024 ist und ich PAL haben will :)
    b) nein, Neat holt echt hammermäßig alles raus was geht ... außer bei Standbildern, die sind dummerweise in dem Film öfter mal verbaut worden
    c) weiß nicht ... glaube, weil ich "mal schnell" reinpacken wollte und nicht wusste, ob ichs behalte ... außerdem wollte ich die Detection-Area feinjustieren und dann hätt ich ständig in der Funktion rumsauen müssen.
    d) weil der eingebaute ConvertToYV12() noch mehr Banding reinhaut und fürchterlich viel Artefakte produziert
    e) Was is'n das? Multithreading? Grübel ... war das nicht das Teil was ständig absemmelt?

    Zitat von sneaker2

    Wie gesagt: bei 10 Bit erwarten viele Player Rec.709-Farben. Wenn Du sie mit Rec.601 fütterst, werden die Farben entsprechend verfälscht. Kommt jetzt noch darauf an, was für Farben Deine Quelle überhaupt liefert:

    Falls Quelle Rec.709:
    #sourcefilter, trim, crop
    Dither_convert_yuv_to_rgb(matrix="709", mode=0)
    #neat
    Dither_convert_rgb_to_yuv(matrix="709", mode=0)
    #rest

    Das hab ich schon mit zich Kombinationen ausprobiert sobald ich irgendwo eine 709er reinschreibe, wird es entweder viel zu dunkel oder viel zu hell.
    Ich hab solange rumprobiert, bis ich bei ConvertToRGB(ohne matrix) dann Dither_convert_rgb_to_yuv(matrix="601") dasselbe Bild habe, wie wenn ich die Quelle mit MPC_HC aufmache ... oder kann ich dem auch nicht trauen?

    Der Abgriff nach dem Neat, direkt in den x264-10-Bit gibt mehr Helligkeit und kräftige, kontrastreiche Farben.
    Ist wahrscheinlich aber falsch, denn es produziert mehr Banding.

    Zitat von sneaker2

    Am besten dann auch die x264-Ausgabe entsprechend mit --colormatrix bt709 (--colorprim bt709 --transfer bt709) kennzeichnen. Falls Du mit 8 Bit Encoding arbeitest, am besten Rec.601-Ausgabe für SD und Rec.709-Ausgabe für HD anpeilen. So erreicht man die größtmögliche Kompatibilität.

    Das hab ich noch nicht probiert ... werd die Reihenfolge von dir mit den x264-Einstellungen nochmal checken.

    Zitat von sneaker2

    Anstelle der Dither-Varianten erfüllen die AviSynth-eigenen ConvertToXYZ in diesem Fall eigentlich dieselben Funktionen (siehe Punkt d. in Selurs Beitrag). Hatte mit denen aber komischerweise letztens auch Artefakte? Muß ich mir vielleicht noch mal genauer anschauen...

    Genau deswegen hab ich den Dither reingehauen. Das Ergebnis ist übrigens spitze, obwohl ich meine etwas Kontrast verlohren zu haben ... nur Gefühl oder ist das Zwangsweise so? Wenn ja, läßt sich der Dither nicht auf "komplexe Bereiche" einschränken?

    4 Mal editiert, zuletzt von TheGenesis (12. September 2013 um 03:26)

    Zitat

    e) Was is'n das? Multithreading? Grübel ... war das nicht das Teil was ständig absemmelt?


    läuft bei mir super, aber ich hab auch nirgends Dither in meinen Skripten,..

    Zitat

    wie wenn ich die Quelle mit MPC_HC aufmache ... oder kann ich dem auch nicht trauen?


    ohne genau zu wissen was für Filter da mit welchen Einstellungen verwendet wurden und ob diese Einstellungen zur Quelle passen: Natürlich nicht!

    Zitat

    nur Gefühl oder ist das Zwangsweise so?


    dither -> Rauschen wird hinzugefügt -> erscheint mir sinnig, dass dabei Kontrast weniger stark wahrgenommen wird

    Zitat

    Wenn ja, läßt sich der Dither nicht auf "komplexe Bereiche" einschränken?


    Ehm, banding sollte eigentlich bei langsamen Farbübergängen auftreten und nicht in komplexen Bereichen,...

    Zu e)

    Wer nicht beachtet, dass das parallele gleichzeitige Ausführen von Filtern auch parallel gleichzeitig mehrfach RAM belegt, und sich die Parallelität bei der Verwendung von Filtern, die selber multithreaded arbeiten (z.B. EDI-Threads in QTGMC), quadrieren kann, bei dem kann das dann auch mal an gewisse Grenzen stoßen, v.a. die 2-GB-pro-Prozess-Grenze der 32-bit-Architektur (ohne weitere Vorsorge).

    Mit vernünftiger Begrenzung läuft AviSynth MT 2.6 aber genauso stabil wie die Standardversion.

    Zitat von TheGenesis

    Ich hab solange rumprobiert, bis ich bei ConvertToRGB(ohne matrix) dann Dither_convert_rgb_to_yuv(matrix="601") dasselbe Bild habe, wie wenn ich die Quelle mit MPC_HC aufmache ... oder kann ich dem auch nicht trauen?

    ConvertToRGB() und Dither_convert_rgb_to_yuv(matrix="601") sind praktisch die Umkehrfunktionen voneinander, d.h. die eine macht die andere rückgängig (abgesehen von Rundungen/Resizen, welche die Farben aber nicht sichtbar beeinflussen sollten). Welche Matrix MPC-HC annimmt, hängt vom Eingangsformat und den verwendeten Filtern ab. Bei AviSynth in der Regel raten nach Auflösung, d.h. SD=Rec.601, HD=Rec.709. Bei 10 Bit H.264 häufig immer Rec.709. Einige Filter erkennen auch die Flaggen im Stream, also was man mit z.B. --colormatrix reingeschrieben hat. Also nein: dem kannst Du nicht unbedingt trauen. Mit madVR kannst Du über STRG + J sehen, welche Matrix er nutzt. Du kannst natürlich zum Testen auch im AviSynth-Skript selbst am Ende nach RGB wandeln.

    Zitat von TheGenesis

    Das hab ich schon mit zich Kombinationen ausprobiert sobald ich irgendwo eine 709er reinschreibe, wird es entweder viel zu dunkel oder viel zu hell.

    Also in der Regel kommen solche Farbprobleme durch Verwechselungen von Rec.601<>Rec.709. Die jeweiligen Umwandlungen mit Dither oder ConvertToXYZ sollten Dir jetzt bekannt sein, also kannst Du nach dem Ausschlußverfahren vorgehen, also schauen, an welchem Filter es liegt - ist es überhaupt ConvertToXYZ/Dither oder liegt das Problem evtl. doch bei einem anderen Filter? Und welche Farben hat überhaupt Deine Quelle?


    Zur 2-GB-Grenze: Durch ein Pipe-Programm mit entsprechendem Flag kann man das auf 4 GB anheben und x264 in einem eigenen Prozess laufen lassen, kann sich also noch etwas Luft verschaffen. Ist hier aber vermutlich schon der Fall, da er 10 Bit eh pipen muß. 64-Bit-Betriebssystem ist allerdings Voraussetzung.

    Einmal editiert, zuletzt von sneaker2 (12. September 2013 um 15:04)

    Zitat von Selur

    Ehm, banding sollte eigentlich bei langsamen Farbübergängen auftreten und nicht in komplexen Bereichen,...

    Sorry ... mit "komplex" hab ich "feine Übergänge" gemeint.

    Zitat von LigH

    Zu e)

    (Filter und RAM Verbrauch)

    Mit vernünftiger Begrenzung läuft AviSynth MT 2.6 aber genauso stabil wie die Standardversion.


    Ok ihr beiden ... wie kann ich denn rauskriegen, ob es überhaupt Sinn macht, diesen oder jenen Filter zu paralellisieren?

    Irgendeiner ist doch bestimmt immer der Flaschenhals wenn die Filter in Serie geschaltet sind ... da wartet doch dann immer der eine auf den anderen, oder?

    Mhmm ... ich hab z.B. konkret das Problem, das Neat meine Graka nur zu 25% auslastet und der rest (inkl. x264) gerade mal mit 40%-60% an meinem Prozessor knabbern.
    Wenn ich dagegen den Dither() und DePan() -kram aus dem Script nehme und nur noch ConvertToRGB()+Neat()+x264 laufen lasse, geht die Graka auf 65% und der Prozzi wird mit 90% belastet.

    Gibts da 'nen "good practice" wie man die Filter effizient Multithreaded? Ich möchte mich nämlich nicht jedesmal 10 Stunden mit der performanten/optimalen Konfiguration beschäftigen um am ende einmal 10 Stunden schneller rendern zu können :)

    Zitat von sneaker2

    ConvertToRGB() ... Dither_convert_rgb_to_yuv(matrix="601") ...

    Also in der Regel kommen solche Farbprobleme durch Verwechselungen von Rec.601<>Rec.709.

    Nu kann das natürlich sein, das AviSynth die Farbgeometrie aus der Quelle nicht richig erkannt hat ... DGindex hat Rec.709 im Log angegeben. Gibts sowas wie "AssumeColormetry("Rec.709") o.ä.?

    Zitat von sneaker2

    Du kannst natürlich zum Testen auch im AviSynth-Skript selbst am Ende nach RGB wandeln.

    Ja und dann?

    Das komische ist, sobald ich anstatt Dither_convert_rgb_to_yuv() den ConvertToYV12() nehme, bekomme ich auch schon in der Vorschau mit VD massive Bandingartefakte (egal ob mit oder ohne eine von beiden matrizen).

    Lass ich den ConvertToYV() ganz weg, ist das Bild einwandfrei.

    Eigentlich müsste es doch mit einem ConvertToRGB("Rec.709") + Neat() + ConvertToYV12("Rec.709") + DePan() auch ohne die Dither()-Funktionen klappen, oder?

    Zitat von sneaker2

    Du nach dem Ausschlußverfahren vorgehen, also schauen, an welchem Filter es liegt - ist es überhaupt ConvertToXYZ/Dither oder liegt das Problem evtl. doch bei einem anderen Filter?

    Nein, hatte ich auch erst gedacht, bis ich nur die ConvertToXYZ() ausprobiert habe ... der ConvertToYV12() reicht aus um das Ding kaputt zu machen, auch wenn ich am Ende wieder zu RGB zurückwandle.

    Zitat von sneaker2

    Und welche Farben hat überhaupt Deine Quelle?

    Wenn DGindex nicht völlig daneben liegt, dann 709 ... hier das log:

    Zitat von sneaker2

    Zur 2-GB-Grenze: Durch ein Pipe-Programm mit entsprechendem Flag kann man das auf 4 GB anheben und x264 in einem eigenen Prozess laufen lassen, kann sich also noch etwas Luft verschaffen.
    Ist hier aber vermutlich schon der Fall, da er 10 Bit eh pipen muß. 64-Bit-Betriebssystem ist allerdings Voraussetzung.

    Ein Pipe-Programm? Du meinst Frameserver oder? Denn mein Rechner spricht nur Windoof :)

    Einmal editiert, zuletzt von TheGenesis (12. September 2013 um 23:29)

    Zitat

    Gibts da 'nen "good practice" wie man die Filter effizient Multithreaded? Ich möchte mich nämlich nicht jedesmal 10 Stunden mit der performanten/optimalen Konfiguration beschäftigen um am ende einmal 10 Stunden schneller rendern zu können


    Du solltest die Frage anders rum stellen: kannst Du eine Filterkombination bauen, die bei Multithreading langsamer ist?

    Zitat

    Ein Pipe-Programm? Du meinst Frameserver oder? Denn mein Rechner spricht nur Windoof


    Er meint ein tool was wie avs2yuv, mencoder, ffmpeg,... das Avisynth script dekodiert und mittels einer (eventuell 'named') pipe den decodierten Output an den encoder übergibt.
    Falls nicht klar ist war eine Pipe ist: http://de.wikipedia.org/wiki/Pipe_%28Informatik%29

    Mit dem "Pipe-Programm" sind Hilfsprogramme wie avs4x264mod gemeint, die ein 64-bit-x264 mit dem Video aus 32-bit-AviSynth versorgen. Ist das Programm als "Large Address Aware" gekennzeichnet (avs4x264mod ist es), darf es auch mehr als 2 GB RAM belegen, wenn so viel übrig ist, und teilt sich dann auch den Speicher nicht mit x264.

    Parallelisierung kann sich bei allen Filtern lohnen, deren Aufgabe nicht gerade trivial ist. Je aufwändiger ein Filter voraussichtlich rechnen muss, umso wahrscheinlicher wird das Skript beschleunigt, wenn er im Multithreading-Bereich enthalten ist. Bei CPUs mit sehr vielen virtuellen Kernen (bei intel evtl. HyperThreading nicht vergessen) sollte man nur wissen, ob die sich selber noch mal vervielfachen, und dann geeignet die Parallelisierung begrenzen.

    Mit dem "Pipe-Programm" sind Hilfsprogramme wie avs4x264mod gemeint, die ein 64-bit-x264 mit dem Video aus 32-bit-AviSynth versorgen. Ist das Programm als "Large Address Aware" gekennzeichnet (avs4x264mod ist es), darf es auch mehr als 2 GB RAM belegen, wenn so viel übrig ist, und teilt sich dann auch den Speicher nicht mit x264.

    Parallelisierung kann sich bei allen Filtern lohnen, deren Aufgabe nicht gerade trivial ist. Je aufwändiger ein Filter voraussichtlich rechnen muss, umso wahrscheinlicher wird das Skript beschleunigt, wenn er im Multithreading-Bereich enthalten ist. Bei CPUs mit sehr vielen virtuellen Kernen (bei intel evtl. HyperThreading nicht vergessen) sollte man nur wissen, ob die sich selber noch mal vervielfachen, und dann geeignet die Parallelisierung begrenzen.

    Zitat von TheGenesis

    Wenn DGindex nicht völlig daneben liegt, dann 709

    Ok, wir nehmen das jetzt mal so an: Quelle ist Rec.709.

    Jetzt zum Grundsätzlichen: wir arbeiten meist mit YUV-Daten, d.h. so sind die Daten auf DVDs, auf Blu-Rays und im TV "gespeichert". Zur Anzeige am Bildschirm wandelt ein Player das üblicherweise zu RGB. In MPC-HC in der Regel einer der ausgewählten Video-Renderer. Dabei wird bei der Umwandlung auf eine bestimmte Matrix zurückgegriffen, wobei wir wissen müssen, welche Matrix vom Author des Videos genutzt wurde, um die Farben korrekt umwandeln zu können. Um das besser kontrollieren zu können, machen wir das nun zum Testen selbst im Skript. Folgendes nehmen wir dazu ab jetzt als Quellreferenz:

    Code
    DGSource("Logans Run.dgi")Dither_convert_yuv_to_rgb (matrix="709", mode=0)


    Davon kannst Du nun einen Screenshot erstellen und als Vergleichsquelle nehmen.

    Das ist nun Dein Skript zum Testen:

    Jetzt fängst Du an, der Reihe nach einzelne Filter auszukommentieren (z.B. Neat) und schaust, welcher Filter für die falschen Farben verantwortlich ist. Wenn Du weitere Fragen hast, erstelle Screenshots und Samples von Ein- und Ausgabe und lade sie hoch.
    Sobald alles stimmt, entfernst Du die letzte Zeile wieder, weil wir bei x264 üblicherweise mit YUV-Daten arbeiten. Den H.264-Stream nun entsprechend über --colormatrix bt709 (--transfer bt709 --colorprim bt709) markieren. Diese Info kann Playern helfen, beim Abspielen die richtige Matrix für die YUV->RGB-Konvertierung zu wählen.

    Zitat von Selur

    Du solltest die Frage anders rum stellen: kannst Du eine Filterkombination bauen, die bei Multithreading langsamer ist?

    Ok. Ich probiers heut mal aus.

    Zitat von Selur

    Er meint ein tool was wie avs2yuv, mencoder, ffmpeg,... das Avisynth script dekodiert und mittels einer (eventuell 'named') pipe den decodierten Output an den encoder übergibt.

    Ihr meint, AviSynth() und x264.exe laufen in demselben Prozess?
    Und welche Threads erstellt x264 dann separat, wenn ich mein --threads 14 angebe?

    Zitat von Selur

    Falls nicht klar ist war eine Pipe ist ...

    Jetzt hattest du mich aber erschreckt ... ich dachte ich hab irgendeine Neuerung in Windoof verpasst ... schade das mickydoof auf Kommandozeilenebene nichtmal eben alle möglichen Streams von links nach rechts durchreichen kann.

    Ja, im weitesten Sinne wäre das mit einem "Encoder-Proggie" wohl ein pipe ... ist aber lange nicht so flexibel verwurschtelbar wie in Linux :)

    Zitat von LigH

    ... avs4x264mod gemeint... "Large Address Aware" ... und teilt sich dann auch den Speicher nicht mit x264.

    Jetzt ist mein Weltbild doch etwas nach links gerückt ... du meinst, im Zeitalter von Windows7-x64 und 80Euro für 8Gb wird das immernoch nicht vom Betriebssystem optimiert?

    Ich hatte jetzt echt angenommen, das DGindex(), AviSynth(), Neat() und x264 alle in einem separaten Kontext laufen.

    Benutzt ihr avs4x264mod generell? Da hab ich nämlich noch nie was von gehört.

    Zitat von sneaker2

    Ja, das geht, aber die Dither() machen viel zu viel Salz in das Bild ... wäre cool, wenn man die irgendwie dazu bringen könnte, nur die problematischen Bereiche neu zu mischen.

    Zitat von sneaker2

    Jetzt fängst Du an, der Reihe nach einzelne Filter auszukommentieren (z.B. Neat) und schaust, welcher Filter für die falschen Farben verantwortlich ist.

    Verantwortlich ist/war der Dither_convert_rgb_to_yuv(matrix="601"). Ich hatte den Kontrast als "besser" empfunden ... ist aber im Original nicht so.

    Der Neat produziert ein paar sharpen-overshots und wenn man das nicht dithered, gibts an ein paar wenigen Stellen die blöden Bänder.
    Ja, ich hab den sharpen schonmal reduziert ... da leiden dann die übrigen 90% vom Film drunter.
    Die hints brauchen die Player hierbei scheinbar nicht ... sowohl MPC als auch VLC haben das korrekt erkannt und stellen es entsprechend dar.

    Wie gesagt ... ein dither() in den "schwierigen Bereichen" wäre 'ne coole Geschichte ... das würde mit Sicherheit auch einiges an Bitrate sparen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden