Wie vermeide ich bei x264 "Rausch-Wolken" in dunklen Bereichen?

  • Habe eben bei r1732 "--opengop" dazugepackt, aber er bricht damit sofort mit error ab...


    @ LigH
    auch mit Bindestrich gibts error...



    Ist es denn zu viel verlangt, mal die exakte Fehlermeldung hier zu zitieren?! :motz:
    __

    Zu heller Bildschirm einerseits (die heutigen LCD-Bildschirme brauchen teilweise Treiber-Gamma 0.7, um wieder halbwegs lineare Helligkeit zu zeigen), TV-Scale bei der YUV-Videoausgabe andererseits (wie letztens im Nvidia-Treiber entdeckt).

  • danke Selur :)
    komisch... habe nun in den Settings auf den Development-Updater gestellt, alles nochmal updated + r1732 drauf, aber egal ob ich mit --open-gop normal, oder none/bluray encode, das Resultat ist so besch... wie am Anfang als noch das ältere build arbeitete.

    LigH
    reg dich ab, war mein Fehler. Daher gibts auch keine exakte Fehlermeldung.

    Zitat

    Zu heller Bildschirm einerseits (die heutigen LCD-Bildschirme brauchen teilweise Treiber-Gamma 0.7, um wieder halbwegs lineare Helligkeit zu zeigen), TV-Scale bei der YUV-Videoausgabe andererseits (wie letztens im Nvidia-Treiber entdeckt).

    dann verstehe ich nicht, warum mit VLC mein Bildschirm zu hell und mit dem WMPlayer auf einmal ordentlich abgestimmt sein soll, denn da habe ich keine Rauschwolken ?

    Einmal editiert, zuletzt von lil barny (9. Oktober 2010 um 18:23)

  • Unterschiedliche Player können unterschiedliche Renderer verwenden. Und speziell der "Hardware Overlay"-Renderer hat seine eigenen Werte, unabhängig vom Desktop.

    Und wie gesagt: Ich habe noch keine Bestätigung, dass der AVC-Decodierfehler im VLC beseitigt worden wäre. Keine Ahnung, ob der noch fehlerhaft arbeitet.

  • Beim MPC-HC:

    Einstellung = O(ptionen) - Wiedergabe - Ausgabe
    Kontrolle = Rechtsklick ins laufende Video - Filter - ...

    Beim VLC media player:

    Einstellung = Extras - Einstellungen - { Einfach: Video - Anzeige | Alle: Video - Ausgabemodule }
    Kontrolle = ?


    Leider haben nicht alle Player den selben Namen für den gleichen Renderer (z.B. VMR7 bzw. VMR9 im MPC-HC findet man in VLC wohl als DirectX oder Direct3D), und auch nicht alle Renderer sind für jeden Player verfügbar (z.B. SDL und OpenGL gibt's wohl nur in VLC, aber nicht in MPC; madVR und Haali Renderer sind wohl nur im MPC-HC verfügbar - wenn installiert). Und "Standard" ist relativ nichtssagend.

  • glaub ich bin scho ganz meschugge vom vielen encoden und vergleichen. Ich kanns nicht mehr sehen.
    VLC sagt auch wie vorhergesagt nichtssagend "Standard".

    Damit bin ich am Ende meiner nulligen Weisheit angelangt, gebs auf.

  • Auch mal nachschauen, ob in den treiberspezifischen (Nvidia/ATI) Anzeigeeigenschaften irgendwelcher Schnickschnack aktiviert ist. z.B. Nvidia: "Randverbesserung", "Rauschunterdrückung", "dynamische Kontrastverbesserung", "Farbverbesserung". ATI hat bestimmt ähnliches, kenn' ich aber nicht.

    Sicherstellen, dass all dieses Zeugs deaktiviert ist.

  • Nicht einfach nur gucken, "Standard" lesen und aufgeben ... sondern mal alle durchprobieren und schauen, wie es sich (eventuell - vielleicht auch nicht) verändert. Auch unter Beobachtung der CPU-Auslastung beim Abspielen - es nützt einem ja nichts, wenn nur der langsamste Renderer gut aussieht.

  • Deswegen auch mein Hinweis auf die Anpassungsoptionen des Videotreibers. Die greifen nämlich nur bei hardwarebasierten (oder -gekoppelten) Renderern, z.B. HW-Overlay oder EVR, aber nicht bei rein softwarebasierten Renderern wie z.B. Haali's Renderer.

    Das könnte auch ein unterschiedliches Verhalten bei verschiedenen Playern erklären. Der Renderer alleine sollte nicht solche Unterschiede verursachen.

  • Danke für die Anteilnahme...
    kann ich aus euren Äußerungen schließen daß ihr konkret NICHT diesen Effekt mit meinem sample und dem VLC oder KMplayer nachvollziehen könnt ?

  • Aaahh ... doch, mit dem VLC-Player gibt's etwas zu sehen, was man nicht sehen sollte.

    Vermutlich "veraltete" Decoder, die mit dem x264-Feature "weighted P-frames" nicht zurechtkommen.

    => entweder weightp deaktivieren, oder (besser) keine veralteten Decoder verwenden ...

  • krass... :hm:

    und ich dachte ihr hättet von vornherein das sample auch mit dem vlc getestet da ich ja geschrieben habe dass ich damit diese Rauschwolken hab...

    dachte immer der vlc wäre durch die ständigen updates ein "state-of-the-art"-player.
    Weit gefehlt. Wie gestern gemerkt hab kann der im Vergleich zu anderen playern auch überhaupt kein H264 in 1080p50 abspielen... :nein:

  • Hab ein ähnliches Problem: Dunkle Bereiche werden mit x264 zu stark komprimiert. Dachte eigentlich das es dafür eine Einstellung gibt, mit der man gegensteuern könnte. Aber die gibt es anscheinend nicht?

  • Nein. — Doch! — Oooh!

    Oder wie? Leute, reißt euch zusammen.
    __

    @ 3ds:

    Hast du den Beitrag überhaupt schon komplett gelesen und hast mal ein paar der erwähnten Tipps ausprobiert?

    Liegt es am Encoder (z.B. zu wenig Bitrate oder sonstige ungeeignete Optionen) oder am Decoder (mangelnde Unterstützung der "weighted P frames") => mal mit unterschiedlichen Playern getestet?

    Mal eine ausführliche x264-Kommandozeile hier zur Analyse anbieten, am besten noch mit einem Schnipsel Beispiel-Video?

    Mögliche Ursache für solche Probleme ist oft nicht nur ein einzelner Parameter, sondern eine Kombination mehrerer (Bitratenvorgabe, Deblocking, psychovisuelle Optimierungen...), deshalb kann es keine kurze Antwort geben.

  • Hab keine relevante Option in dem Thread gefunden.

    Mag sein, das mein TFT einfach zu viel aus dem dunklen Bereichen zeigt. Aber wäre unschön, wenn ich es so einstellen müßte damit man einfach nichts mehr im dunklen sieht...

    Nachdem MeGUI zumzickt, bin ich dazu übergegangen, preset zu nutzten. Hier mal ein Beispiel:

    Code
    x264.exe --level 4.1 --tune film --preset slow --profile high

    Aber auch die MeGUI 2pass defaults führen zu wenig bitrate in dunklen Bereichen -> Artefakte...

  • Hast du denn überhaupt irgendwelche (2-pass-) Bitraten- oder (1-pass-CRF-) Qualitäts-Vorgaben gemacht?

    Über die Bitrate (bei 2-pass), Bildfläche und Spieldauer ließe sich auch schon mal die "Flächenbitrate" (bppf) berechnen, die ein Anhaltspunkt dafür wäre, ob deine Wahl vielleicht schon zu knapp für gute Qualität wird.

  • Zitat

    Aber wäre unschön, wenn ich es so einstellen müßte damit man einfach nichts mehr im dunklen sieht...


    Dann stell den Gamma beim Playback runter. :)

    Ansonsten poste doch mal:
    (0. ist der Monitor einigermaßen Kalibriert?)
    1. png Screenshot des Inputs und des Reencodes (mit Virtual Dub erstellen) damit klar ist ob nicht eventuell die Quelle schon das Problem hat und bei dieser beim Playback nur der Playbackfilter anders eingestellt ist.
    2. einen kurzen Ausschnitt (< 30Sekunden) von Problemmaterial
    3. Was für Player und Filter werden beim Playback verwendet?

    Cu Selur

Jetzt mitmachen!

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