x264: Artefakt-Bildung an scharfen Kanten (Untertitel) bei Rekomprimierung

    Hi leute,
    hab da mal ein kleines Problem mit dem x264 encoder.
    Mir ist aufgefallen, dass x264 bei sehr scharfen Kanten artefakte bildet, die eigentlich nicht da sein sollten und ich weiß nicht woran das liegen kann.
    Da ich nicht weiß wie ich's richtig bechreiben soll hier noch ein Bild (vergleiche gelb eingekreiste stellen) und sample (mkv->encode und .264->original von BD).

    test nya000104.jpg

    Sample: http://www29.zippyshare.com/v/2w2hIVnB/file.html

    Vieleicht weiß ja einer von euch woran das liegen kann. Habs schon mit verschieden werten für aq-strength und psy-rd probliert aber ohne erfolg.
    Verwendete settings:

    Code
    cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10  / psy=1 / psy_rd=0.80:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 /  trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 /  chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0  / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 /  constrained_intra=0 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 /  direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 /  keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf  / mbtree=1 / crf=12.0 / qcomp=0.80 / qpmin=0 / qpmax=81 / qpstep=4 /  ip_ratio=1.40 / aq=1:0.80

    Ich hoffe jemand kann mir weiter helfen. Vielen Dank schon mal im vorraus.

    Auch wenn H.264 meist nicht die DCT, sondern eine andere Integer-Transformation verwendet, gibt es dennoch Grenzen in der Genauigkeit bei beschränkter Bitrate, also relativ grober Quantisierung. Ich stimme also insofern überein, als dass es sich wahrscheinlich um einen Quantisierungs-Kaskaden-Effekt handelt: Werden bereits quantisierte Daten noch mal mit anderem Quantisierungsfaktor neu komprimiert, gibt es Extremfälle mit Rundungsfehlern, die dann offensichtlich werden.

    Ja mein Rechner ist übertaktet, allerdings hab ich nach etwa 12 Stunden prime95 test keinen Rechenfehler feststellen können. Könnte es trotzdem daran liegen?
    Der Fehler tritt immer an dieser Stelle auf auch nach meheren encoding versuchen mit verschiedenen x264 builds sowohl 8bit alsauch 10bit.
    Ich werde das dann nochmal auf einem anderen Rechner testen.

    Könnte die Bitrate bei CRF 12 immernoch zu gering sein?

    Was ich merkwürdig finde ist, wenn ich vorher mit avisynth blur(0.1) filtere tritt das Artefakt nicht auf.

    EDIT:
    Habs jetzt auch mal auf einem anderen Rechner aus probiert (nicht übertaktet). Gleiches Problem an exakt der gleichen Stelle.

    Einmal editiert, zuletzt von kudo (17. Juli 2015 um 09:43)

    An Überhitzung liegt es nicht, solche Fehler sind mathematisch bedingt, die passieren auch bei kalter CPU.

    Es liegt daran, dass die Videokompressionstechniken auf natürliche Bilder optimiert sind, technisch scharfe Grafiken überfordern sie. Siehe: Gibbssches Phänomen

    Die Tatsache, dass eine minimale Unschärfe solche Fehler verhindert, ist ein deutliches Indiz dafür, dass die zu scharfen Kanten ein Teil der Ursache sind.

    Mit "CRF12" und "--tune grain" tritt das Problem nicht auf. Die Bitrate ist allerdings deutlich höher. Hab's auch mal mit dem Mainconcept H.264 Pro Encoder versucht - gleiches Problem!

    Habs jetzt auch noch mal mit einem anderen GPU basierenden Encoder (NVEncC von rigaya) getestet (http://forum.videohelp.com/threads/370223…IA-GPU-encoding). Auch hier bei h264 das selbe Problem, bei h265 tritt das Problem nicht auf, kann ich bestätigen.
    Das mit --tune grain werde ich dann auch mal testen.

    Wenn es wirklich ein Bug in x264 ist wo kann man das melden oder hat es jemand schon gemeldet?

    Hab auch noch ein zweiten Clip (ebenfalls ein Anime), bei dem auch dieses Problem auftritt. Wenn jemand interesse hat kann ich das Sample auch noch hochladen.

    Wenn es nicht nur mit x264, sondern auch mit NVEncC (und evtl. auch mit dem MainConcept Encoder) passiert, liegt es nicht spezifisch an x264, sondern allgemein an H.264, so wie ich das schon vermutet habe: Es ist vermutlich am ehesten eine Rechenungenauigkeit in der Integer-Transformation.

    Und ja, es wäre sicher interessant, das auch mal mit internationalen Größen der Videoencoder-Softwareentwicklung zu besprechen. Dann aber nur mit Testmaterial und Anleitung zum Nachstellen, so exakt wie nur möglich.

    Hat etwas länger gedauert aber hab hier nun Test Material und eine Anleitung zum Nachstellen.

    Anleitung zum Nachstellen:

    Avisynth version: 2.60 MT build vom 2015.02.20(SEt) https://www.dropbox.com/s/dckxoowjlzwk…nth_20150220.7z
    Verwendete GUI: MeGUI (version: 2525)
    x264 build: 2538kMod.10bit.x86_64(komisar) http://komisar.gin.by/

    sample1: http://www99.zippyshare.com/v/bi65oKvG/file.html
    avisynth script:

    Code
    LSMASHSource_LWLibavVideoSource(source="sample1.264")


    Verwendete x264 comandline:

    Code
    --preset veryslow --crf 12.0 --qcomp 0.8 --no-fast-pskip

    sample2: http://www98.zippyshare.com/v/kQEiIzx3/file.html
    avisynth script:

    Code
    LSMASHSource_LWLibavVideoSource(source="sample2.264")


    Verwendete x264 comandline:

    Code
    --preset veryslow --tune animation --crf 12.0 --deblock 0:0 --qcomp 0.8 --aq-strength 0.8 --psy-rd 0.80:0 --no-dct-decimate --no-fast-pskip --colorprim bt709 --transfer bt709 --colormatrix bt709

    Den downloads liegen bilder bei, auf denen die Problemstellen gekennzeichnet sind.
    Die *.264's sind unveränderte Ausschnitte der jeweiligen Bluray.
    Die *.mkv's encodiert mit x264 und dem beschreibenen Problem (siehe Beitrag #1)
    Ich hoffe das hilft weiter.
    Falls noch weitere Informationen benötigt werden einfach hier rein schreiben.:)

    Einmal editiert, zuletzt von kudo (24. Juli 2015 um 21:18)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden