x264 Starke Verschlechterung des Bildes innerhalb der GOP

  • Hallo,
    ich was schon länger nicht mehr hier... weil es nach der letzten Hilfe doch sehr gut mit dem x264 geklappt hat. Jetzt mein Problem... im Verlauf der GOP (25~250) verschlechtert sich das Bild (HD Material) so das beim beginn einer neuen GOP der Spung zum I Frame optisch deutlich auffällt. Das ganze ist extrem in einhetlichen Texturen wie dunklen Flächen, Fliesen, Tapeten usw... je Detailreicher eine Fläche ist, umsoweniger unterliegt diese diesem Phänomen. Habe auch mal die GOP stark verkürzt... dann sieht man den Sprung halt häufiger.


    Egal ob ich mit crf20 oder 2Pass 8000 code... die Einstellungen des x264 im Bild im Anhang.


    Ist eine recht neue Version des x264 (64bit) da der Mediacoder die recht fix aktualisiert.


    Ich habe einige ältere x264 Videos die dieses Phänomen nicht haben... hat sich da vieleicht im x264 etwas geändert?


    Ich habe bisher folgende Ansätze verfolgt:
    - no-fast-pskip
    - teste gerade mit und ohne mbtree
    - paar Kleinigkeiten... die aber keinen gewünschten Erfolg brachten.

  • "Muxer frame buffer cannot allocate memory" kombiniert mit "--rc-lookahead 80" (<- totaler Unfug!!) zusammen mit 'number of reference frames (0+5) exceeds max (4; probably corrupt input),.. "
    hört sich so an als ob:
    1. MPlayer beim Decodieren der Speicher ausgeht
    2. MPlayer der Ansicht ist die Quelle hat ne Macke (oder jemand, ohne Sinn und Verstand, die Level flags geändert) und MPlayer deshalb Probleme mit dem Inptu hat
    3. Du hoffentlich ordentlich viel Arbeitsspeicher (der hoffentlich keine Probleme hat weil eventuell der Rechner übertaktet ist) hast, weil rc-loohahead 80 einiges schlucken wird


    Zitat

    hat sich da vieleicht im x264 etwas geändert?


    dauernd, aber nichts was zu dem von Dir beschriebenen Problem führen sollte


    Cu Selur

  • 8GB Speicher PC1600... dem ist es erst mal egal ob der X6 auf 3.2 oder 3.8Ghz läuft... hab die Kiste erst seit Freitag... bisher nur mit dem AMD Tool unter Windows mal kurz auf 3.8 gejagt...ohne die Speichertimings zu ändern.
    Ist aber ist auch so schnell genug... und auch nur der Boxed Lüfter drauf...
    Die Speicheranzeige liegt dann ständig bei 900-1200MB...


    Ich habe das Problem gefunden... habe alles außer QABAC und MB Tree abgeschaltet und dann einzeln zugeschaltet... es war der "deblocking loop filter". Wenn ich den aus lasse sieht es wieder blendend aus...


    Werde aber deinen Hinweisen nachgehen!


    Dank dir

  • Moment...


    Ausgerechnet der "Inloop Deblock Filter" ist eigentlich eine der sinnvollsten Optionen im Zusammenspiel zwischen AVC-Encoder und AVC-Decoder. "Ausschalten" sollte man den eigentlich nicht. Vielleicht kann man seine Grenzwerte etwas verringern. Standard ist "0:0", verminderte Stärke wäre typischerweise z.B. "-1:-1".


    Leider kann ich nicht sagen, welcher Unterschied zwischen den beiden Grenzwerten exakt besteht, ihre Wirkung betreffend.

  • Hallo,
    habe mich gerade hingesetzt und mal zwei MKV`s erstellt... als Quelle Gesichter weil das Auge da wohl sehr stark drauf reagiert.


    Als Download hier: http://akhome.dnsdojo.net/x264test.7z (leider nur 45kb/s upload)


    Mit dem Komandozeilentext für x264... im groben: crf 21 nur QABAC und MBTREE... einmal mit und einmal ohne "deblocking filter" (0,0)


    Wie man sieht springen die Pixel mit dem Filter... das Bild verschlechtert sich zusehends... was hier leider nicht sichtbar ist... hat man einen verwaschenen Hintergrund... z.b. Fliesen mit der Filmunschärfe baut sich dieses Flimmern innerhalb der GOP auf... mit dem nächsten I Frame hat man dann wieder "volle" Qualität... ist nervig.

  • nö... preset tune normal... ich kann "temporal3d cleaner" per klick dazwischenschalten...


    UPLOAD: Gibt viele Wege nach Rom... mein Webserver steht aber neben mir und ich kann per Gigabit drauf zugreifen ;-) Sind doch nur 4Mb... hab doch nicht den ganzen Film zwei mal hochgeladen .-)


    Ja, der Bildschirm ist heller als der Beamer... also Gamma. Aber die Sprünge in den Texturen sieht man auch auf dem Beamer...

  • Was hatte ich geschrieben? --preset grain ?? Auah, so'n Schwachsinn ... sollte natürlich --tune heißen.



    > ich kann "temporal3d cleaner" per klick dazwischenschalten...


    Wenn Du den Film unbedingt verhunzen willst, dann mach das.


    Probier's doch einfach mal mit --preset slow --tune grain. Die x264-Programmierer werden sich schon etwas mit dem grain-Tuning gedacht haben. Und die Alien-Filme haben ja nun wirklich reichlich Korn.

  • Was Didée meinte, ist: Probier doch als Tuning mal "Grain" aus (--tune, nicht --preset).

    Code
    1. --tune <string> Tune the settings for a particular type of source
    2. or situation
    3. ...
    4. - grain (psy tuning):
    5. --aq-strength 0.5 --no-dct-decimate
    6. --deadzone-inter 6 --deadzone-intra 6
    7. [B]--deblock -2:-2[/B] --ipratio 1.1
    8. --pbratio 1.1 --psy-rd <unset>:0.25
    9. --qcomp 0.8
  • Ok, heute morgen nochmal kurz den letzten Vorschlag mit Preset Slow und Tune Grain durchgeführt (crf mode). Jeweils mit und ohne "deblocking filter" (außer QABAC und MBTREE) alles aus. Das Ergebniss (subjektiv per Auge):
    1. mit "deblocking filter" ist das Video ca. 30% kleiner, hat immer noch ein paar Sprünge in einzelnen Pixeln und "flat textures" sehen scheisse aus
    2. ohne "deblocking filter", klar... ist größer, sieht aber um längen besser aus. Will sagen das Details sehr viel besser aussehen. Und die "flat textures" sowie dunkle Verläufe sind fehlerfrei.


    Natürlich haut der 3dcleaner extrem rein... sieht aber subjektiv bessser aus als der "deblocking filter". Kommt bei mir aber nur zum Einsatz für "Frauenfilme"... die merkt das sowieso nicht :-)... drückt im crf Mode aber locker um 30% die Bitrate (je nach Material).


    Fazit: Da ich inzwischen einen BR Brenner mein eigen nenne kann wegen meiner der Film auch bis 24GB groß werden (der Rest für AAC5.1 und SUB)... da bleibt der "deblocking loop filter"aus und dafür bleiben Details (in "flat textures") erhalten...


    Nebenfrage: Gibt es eigentlich sowas wie "DVD Author GUI" oder "DVD Lab" für BR Authoring?

  • Psssst .... die Bezeichnung ist CABAC, nicht QABAC.



    1. mit "deblocking filter" ist das Video ca. 30% kleiner, hat immer noch ein paar Sprünge in einzelnen Pixeln und "flat textures" sehen scheisse aus
    2. ohne "deblocking filter", klar... ist größer, sieht aber um längen besser aus.


    Soso, Du hast also festgestellt dass ein 10GB Ergebnis besser aussieht als ein 7GB Ergebnis? Welch umwerfende Erkenntnis! :zunge: ;)


    Ein qualitativer Vergleich macht natürlich nur Sinn, wenn (per 2-pass) die Endgröße die gleiche ist. Ansonsten vergleicht man Äpfel mit Birnen: "Ein Porsche verbraucht bei 30 km/h weniger Sprit als ein Corsa bei 180 km/h" ==> ein Porsche ist sparsamer als ein Corsa. Alles klar.


    Ausserdem, ~irgendwie~ hab ich das Gefühl, dass mit Deinen Einstellungen irgendwas nicht stimmt. Der Unterschied mit-oder-ohne-Deblocking ist mit 30% nämlich viel zu groß. Ein Unterschied 2%~5% wären normal, 10% wären schon viel, könnte man aber noch erklären. Wenn der Unterschied 30% ist, bei ansonsten identischen Einstellungen, dann scheint's mir, dass da irgendwas ganz und gar nicht stimmt ....



    Zitat

    der 3dcleaner [...] drückt im crf Mode aber locker um 30% die Bitrate (je nach Material).


    Ja, und? Bei manchem sehr körnigen Material hab' ich mit MDegrain3 die Bitrate auch schon um 80%(!) schrumpfen können. Und qualitativ sicherlich besser 3dcleaner. ;)

  • Zitat

    Der Unterschied mit-oder-ohne-Deblocking ist mit 30% nämlich viel zu groß. Ein Unterschied 2%~5% wären normal, 10% wären schon viel, könnte man aber noch erklären. Wenn der Unterschied 30% ist, bei ansonsten identischen Einstellungen, dann scheint's mir, dass da irgendwas ganz und gar nicht stimmt ....


    Ne, dass kann schon passen. :) (gerade wenn man crf und psy-rd verwendet)

  • Na, wenn Du das sagst ... ich mach ja auch nicht jedes Encoding zwei Mal, einmal mit und einmal ohne Deblocking, um's dann zu vergleichen und in eine schlaue Tabelle einzutragen ...



    Gerade nochmal einen Test mit einer 5-Minuten-Sequenz (720p, mit "normal-starkem" Filmkorn)


    1) x264 --preset slow --tune film --crf 18
    2) x264 --preset slow --tune film --crf 18 --no-deblock


    (dieser Aufruf impliziert "--psy-rd 1.0:0.15"


    1) ==> 4553 kbps
    2) ==> 4573 kbps


    Unterschied: 0.5% :grübeln:


    Wenn "mit Deblocking" um 30% kleiner sei als "ohne Deblocking", dann wäre das 4553(mit)-->6500(ohne).



    Aber wenn ihr mir alle sagt dass 30% völlig normal sind, na dann isses halt so ...

  • Noch ein Test, um ein anderes Szenario abzudecken:


    - 1080p mit stärkerem, deutlich sichtbaren Grain.
    --preset slow --tune film --CRF 21.0 --psy-rd 1.0:0.25 --deblock 0:0
    --preset slow --tune film --CRF 21.0 --psy-rd 1.0:0.25 --no-deblock


    Ergebnis Unterschied Bitrate: 1.8% (14683 vs. 14955 kbps). Meilenweit entfernt von 30%. Ich komm' da einfach nicht hin, nur durch Abschalten des Inloop-Deblocking.



    Zitat von Selur

    ich habe nie geschrieben, dass das ein normaler Wert ist, sondern nur dass das durchaus passen kann.


    Ja, möglich ist alles. Es kann durchaus passieren, dass man im Lotto 6 Richtige mit Zusatzzahl tippt. Absolut möglich, nur vorkommen tut's ziemlich selten....



    Aaaaber ... ich vermute inzwischen noch was ganz anderes ...


    Zitat von textleiche

    einmal mit und einmal ohne "deblocking filter" (0,0)


    Wie man sieht springen die Pixel mit dem Filter... das Bild verschlechtert sich zusehends... was hier leider nicht sichtbar ist... hat man einen verwaschenen Hintergrund... z.b. Fliesen mit der Filmunschärfe baut sich dieses Flimmern innerhalb der GOP auf... mit dem nächsten I Frame hat man dann wieder "volle" Qualität...


    Ich sehe keine "springenden Pixel" (außer dem Grain selbst), "aufbauende Unschärfe" oder "I-Frame-Plopp", weder in den Samples von textleiche, noch in meinen eigenen Encoding.


    Das beschriebene Verhalten wäre allerdings typisch, wenn im Decoder das Deblocking abgeschaltet ist.


    Treffer, versenkt. ;)

  • Größere Unterschiede in der Endgröße bekommt man vermutlich zwischen


    --preset slow --tune film --crf 21.0


    und


    --preset slow --tune grain --crf 21.0


    (keine weiteren Optionen). Aber sicher auch entsprechend deutliche Unterschiede in der Reaktion auf das Grain.


    Natürlich ist dann eben aufgrund dieser Unterschiede ein wirklich aussagekräftiger "Vergleich" eigentlich nicht möglich. Sollte das Ergebnis mit Tuning "grain" aber immer noch I-Frame-Pumpen zeigen (trotz Tuning-Standardoption "--deblock -2:-2"), dann wäre ein Vergleich verschiedener Decoder unbedingt anzuraten.