Nicht zufriedenstellende Bildqualität bei x264

    Die Resultate, die ich mit x264.exe erreiche, sind für meine Begriffe nicht wirklich zufriedenstellend.

    Wenn ich mir diese Videos hier ansehe:
    http://www.adobe.com/products/hdvideo/hdgallery/
    (480p-Version), so stelle ich fest, dass diese mit etwa 4mbit encoded sind.

    Encode ich nun mit 2mbit erhalte ich viel verpixeltere, artefaktreiche Resultate, insbesondere dann, wenn sich viel bewegt (auch in der hdgallery von oben sind beispiele mit viel bewegung). Was mache ich falsch? Klar, die qualität wird schlechter, aber so schlecht?

    Folgendermaßen gehe ich vor:

    Code
    x264 -b 3 --b-pyramid -r 6 -B 2700 -p 1 -A "all" --bime --no-fast-pskip --stats "stat.tmp" -o NUL input.avs
x264 -b 3 --b-pyramid -r 6 -B 2700 -p 2 -A "all" --bime --no-fast-pskip --stats "stat.tmp" -o temporary.264 input.avs

    Wenn ich im .avs ein Resize auf z.b. 480 mal 320 einstelle, werden die ergebnisse noch schlechter (verschwommen), als wenn ich einfach das 1280*X-quellmaterial nehme.

    Encodingzeit ist mir nicht so wichtig, aber die Qualität hinten sollte halt stimmen. Krieg ich das mit einer bitrate von 1,8-2 mbit überhaupt hin?

    Ich habe schon diverse guides durchgelesen und settings angepasst, aber dies blieb ohne nennenswertem resultat.

    Ein Beispielencode: http://www.gamersunity.de/videosys/output2.mp4

    Mache ich grundlegend etwas falsch oder ist einfach nicht viel mehr drin? Das Quellmaterial hat eine hohe qualität.

    (Ein Problem dabei ist sicher der recht langsame encoding-prozessor, der nicht allzuviel herumprobieren ermöglicht)

    Zitat

    so stelle ich fest, dass diese mit etwa 4mbit encoded sind. .. Encode ich nun mit 2mbit erhalte ich viel verpixeltere, artefaktreiche Resultate...


    Und was ist da jetzt verwunderlich/unerwartet? Du sagst eine 480p Version sieht bei 4MBit super aus, und willst dann dass eine 720p Version bei der halben Bitrate besser aussieht?

    Zitat

    Ein Beispielencode:


    Ein Beispiel des Quellmaterials wäre hilfreicher. (auf voller Auflösung)

    Mir ist etwas unklar was Du erreichen willst, willst Du HD Material (720p/1080p) erstellen oder willst Du 480p erstellen?
    Ist die feste Beschränkung die Datenrate oder die Auflösung?

    Cu Selur

    Ganz pauschal würde ich sagen, dass man bei maximal 2 Mbps nicht viel mehr als SD-Auflösung erwarten kann, für HD reicht das - wenn überhaupt - nur bei Material fast ohne Bewegung.

    Im Prinzip ist mir die Auflösung nicht wichtig. Es geht vorallem um eine möglichst gute Endqualität bei bitrate X (700kbit, 1700kbit, 2700kbit), und darum, dass es mit Flashplayer 9 kompatibel ist (muss H.264 sein, VP6 ist unerschwinglich)

    Komisch war halt, dass nach Verkleinerung durch LanzcosResize per .avs-Script die Qualität noch geringer war (eigentlich hatte ich angenommen, dass bei einer geringeren Auflösung bei einer Bitrate von 1700kbit ein besseres Ergebnis zu erwarten ist).

    Was ich mit dem Beispiel von Adobe darstellen wollte, war lediglich der enorme Qualitätsunterschied.

    Das Quellmaterial gibt's hier: http://dl4.gamersunity.de/get/Broll-Final.rar
    (wenns probleme mit der Dateigröße gibt: Soll ich screenshots draus machen oder einen Teil "ausschneiden"?, müsste halt erstmal rausfinden, wie das möglichst gut geht, aber das soll nicht das problem sein ^^)

    Danke für die Hilfe!

    Zitat

    Komisch war halt, dass nach Verkleinerung durch LanzcosResize per .avs-Script die Qualität noch geringer war


    Nur wenn Du das Bild später beim Playback größer machst als Du es encodest,..

    Zitat

    Das Quellmaterial gibt's hier:


    ich guck mal drauf. :)

    Zitat

    Es geht vorallem um eine möglichst gute Endqualität bei bitrate X (700kbit, 1700kbit, 2700kbit), und darum, dass es mit Flashplayer 9 kompatibel ist (muss H.264 sein, VP6 ist unerschwinglich)


    Hmm,.. wobei man bei H.264 auch aufpassen muss bzgl. MPEG-LA Gebühren.

    Zitat

    hab mich auch mal umgeguckt wie das mit mp4(avc+aac) Material ist:


    source: page 9 of http://www.mpegla.com/avc/avcweb.ppt

    So this would mean since the first term is from August 1, 2002 to December 31, 2010 Free Internet Broadcast of avc material should be free. :D


    source: http://www.vialicensing.com/products/mpeg4…dio_FAQ.html#Q6

    => wenn man also Material auf seine Homepage packt auf das jeder ohne Registration oder Kosten zugreifen kann ist das Ganze zumindest bis 2010 noch kostenfrei :D

    Cu Selur

    Dank dir :)

    Genau das mit den (derzeit) nicht vorhandenen Gebühren war die Motivation, H264 einzusetzen :)

    Was mir noch Auffiel: VP6 hat bei gleicher bitrate mehr hinbekommen imho, ist der bei niedrigen bitraten einfach besser, oder liegts doch an unguten einstellungen?

    Zitat

    Nur wenn Du das Bild später beim Playback größer machst als Du es encodest,..

    Wird bei der Vollbildfunktion halt leider automatisch der Fall sein :/
    Hatte aber den Eindruck, dass selbst bei "kleinem" Playback die Qualität schlechter (verschwommen) ist, wenn ich die Auflösung runter setze.

    Zitat

    VP6 hat bei gleicher bitrate mehr hinbekommen imho, ist der bei niedrigen bitraten einfach besser, oder liegts doch an unguten einstellungen?

    Einstellungen. H.264 ist besser, VP6 glättet bei niedrigen Bitraten mehr, was es teilweise 'schöner' erscheinen lässt. ;)

    Zitat

    Hatte aber den Eindruck, dass selbst bei "kleinem" Playback die Qualität schlechter (verschwommen) ist, wenn ich die Auflösung runter setze.

    Das sollte nicht passieren, ich teste gerade ein paar Sachen durch, werde mich dann man melden. (Das sind die Momente wo es mich wieder ärgert, dass der Q9450 von Intel immer noch nicht erhältlich ist,... ewig gespart um die CPU&Co zu kaufen und nun gibt's sie nicht. :()

    Cu Selur

    Okay erstes Feedback:
    Die Quelle ist nicht was ich high quality nennen würde, wenn es um Ausgangsmaterial für HD geht. Das ist ja schon MPEG-4 ASP, gerade zwischen Frame 500-1000 sieht man ringing und Kompressionsartefakte
    (http://de.wikipedia.org/wiki/Gibbssches_Ph%C3%A4nomen + http://de.wikipedia.org/wiki/Datenkomp…ssionsartefakte)
    Das Problem ist hierbei, dass diese dazu führen, dass die Quelle für den Codec mehr Details erhält als sie bereits hat!
    -> Screencapturing sollte mit einem verlustfreien Codec vorgenommen werden, wenn das Material weiterverarbeitet werden soll.


    Hast Du die Quelle als MPEG-4 gecaptured? Falls nein, solltest Du dieses Material auch nicht als Quellmaterial verwenden.

    Hier mal auf die schnelle was mit Deinem Quellmateral passieren würde:
    http://selur.movie2digital.com/test
    direkter Download des Clips: http://selur.movie2digital.com/test/clips/brollfinal_500.mp4

    Cu Selur

    Das hat weitergeholfen!

    Man sieht nämlich jetzt, dass durchaus ein signifikanter Unterschied besteht zwischen deinem encoding und meinem (gleiche Bitrate), siehe hier:
    http://img155.imageshack.us/my.php?image=beispielau8.png (meins ist das unten)

    Quellmaterial: Gut zu wissen, dummerweise komme ich nicht an das ursprungsmaterial ran bzw. werde es bei anderen Clips leider auch nicht.

    Was empfiehlst du mir, um mit den leider bestehenden beschränkungen möglichst gute Resultate zu erzielen? (Auflösung doch runter? LanczosResize verwenden oder anderen Avisynth-Verkleinerer...) Kann ich H.264 auch dazu bekommen, bei niedrigen Bitraten mehr zu glätten? Mit welchen Parametern (siehe dein man x264-pdf) soll ich mal rumspielen?

    (zum glück weis ich nun, dass man das encoding nur für die ersten x Frames durchführen kann, was expirimentieren natürlich erleichtert).

    Was besonders gut wäre, wäre vorallem mehr Schärfe im Video.

    @prozessor: Und ich muss mich hier mit einem Virtuellen System und dementsprechend weniger Rechenpower rumschlagen ^^, wenn das ganze mal unter Linux zum Kompilieren funktionieren würde, könnt ich auf 8 Cpu-Cores zurückgreifen ^^ - Aber das ist wieder ein ganz anderes Thema, dass angegriffen wird, sobald das Encoding mal steht...

    Zitat

    Was besonders gut wäre, wäre vorallem mehr Schärfe im Video.

    Das Problem mit der Schärfe ist, dass dann die schon vorhandenen 'Schäden' im Material noch mehr Details erzeugen würden und die Datenrate noch weniger reicht. ;)
    Ich hab vor dem Encoden noch geglättet bzw. Rauschen entfernt. :)

    Wegen Linux hätte ich vielleicht ne Idee,.. muss da aber erst was testen.
    Was für eine Distribution verwendest Du?

    Cu Selur

    Ps.: das wesentlich Problem unter Linux ist es einen schönen x264 build zu erstellen (mit dem adaptive quantizer patch von Dark Shakiri, ansonsten könnte ich Dir mit mencoder&x264 ne kleine Anleitung schreiben,...)

    Damit ich nicht wieder ewig rumsuchen muss (die Tatsache, warum ich nicht mehr versuche alles selbst herrauszufinden, ist, dass ich bereits dutzende Stunden in Fragen mp4-Encoding herumgesucht etc. habe um dann festzustellen, dass es so nicht funktioniert - ohne Witz ^^): Wie kann ich einfach glätten/rauschen entfernen (kommandozeile only, avisynth...)? Link zu (verständlicher) anleitung genügt :)

    Linux: Debian Etch
    Problem dabei: Habe rumversucht zu kompilieren etc. pp. (x264-library um ffmpeg mit x264 kompilieren) und es hat auf den tod nicht funktionieren wollen ^^. Wäre allerdings extrem hilfreich, so wies im moment läuft, isses nämlich etwas kompliziert:

    - Film wird auf Hauptserver geladen (linux)
    - Hauptserver läd Film zu Windows-Vserver
    - Windows encoded lahm
    - Windows-Vserver läd Film zu Linux-Hauptserver
    ^^

    Auflösung: Generelle Frage: Auflösung vom quellmaterial einfach so belassen generell - mache ich so nichts großartig falsch?

    PS: Die Quellmaterial-Sache ist echt schade, muss man die entsprechenden Veröffentlicher-Stellen mal versuchen, dazu zu bewegen, verlustfreies Material herauszugeben.

    Allgemein:
    ffmpeg mit x264 drinne gibt nix ordentliches :)

    guck lieber das Du:
    1. mencoder installierst (standard Version aus dem Paketmanagment reicht)
    2. x264 mit dem Adaptive Quantizer 0.48 Patch von Dark Shikari gebaut bekommst. (sollte nicht so kompliziert sein)
    3. gpac installierst (Standard Version im Paketmanagment reicht)
    wenn Du das hinbekommen hast kannst Du folgendes machen:

    Anzumerken ist hierbei, dass ich Resize&Denoise mit mencoder und dessen Ausgabe an x264 übergebe. :) (Das Vorgehen hat den Vorteil, dass man nur x264 neu bauen muss wenn da mal ne neue Version mit tollen Features&Patches kommt.)
    Zum Multiplexen verwende ich MP4Box, da ffmpeg&mencoder gerne mal je nach Version Probleme beim Multiplexen haben. ;)

    Zitat

    Auflösung: Generelle Frage: Auflösung vom quellmaterial einfach so belassen generell - mache ich so nichts großartig falsch?

    Bei der Ziel-Datenrate würde ich für 2700kBit/s auf 960x544 resizen. (hab ich oben in der Anleitung auch gemacht)

    Cu Selur

    Ps.: die x264 Settings im 2nd pass kann man durchaus auch anders einstellen, das waren nur die Settings die bei mir auf die Schnelle die besten Ergebnisse mit dem Clip lieferten. ;)
    (--me tesa kann man aber sicher auch ohne Probleme gegen --me umh ersetzen)

    Thxi! :)

    Leider bricht mencoder auf die erzeugung der raw-videofile mit folgendem Fehler ab (hab bewusst mal -really-quiet weggehauen):

    http://img233.imageshack.us/my.php?image=debianfehler1pe7.jpg

    mp4-multiplexing-probleme durfte ich schon leidvoll erfahren ^^.

    Unter Windows scheint es bis dato zu klappen :)

    UPDATE: Unter Windows funktionierts. Werde mal noch rumprobieren mit Linux, das krieg ich irgendwie hin :)

    Frage zum patchen kurz:
    Da is ja so eine .diff-Datei bei dem Patch . Muss ich jetzt x264 kompillieren und einfach in /etc/bin und dann "patch x264 < patch.diff"?
    Konnte diesbezüglich nichts brauchbares, sicher funktionierendes ergoogeln.

    UPDATE2: Gutes Ergebnis erreicht! (ähnelt deinem), sehr fein, bigthx dafür!
    Gleich mal noch mit weiteren quellvideos probieren :)

    UPDATE3: Der ton ist etwas asynchron (egal), grund ist wohl, dass du oben fürs muxen "-fps 23.976" geschrieben hast und ansonsten "--fps 29.970" ^^ - Wäre vielleicht nicht schlecht, nochmal kurz über die Anleitung zu gucken, wenn später mal jemand nach googelt verwirren ihn die paar kleinen fehlerchen ansonsten noch (raw-file-erzeugung steht zweimal drin, außerdem --stats "G:\Broll-Final.stats")

    :)

    UPDATE4: Wenn ich mit mencoder aus ner .wmv das audio rausextrahieren will, klappt das nicht wirklich, gute lösung spontan parat? Meine temporär-lösung:
    mplayer -vo null -vc null -ao pcm:file=temporary.wav input.wmv
    (nachteil: geht nur in realtime, also etwas langsam, wenn ich :fast einfüge erzählt der mir was von prozessor zu lahm.)

    Zitat

    Leider bricht mencoder auf die erzeugung der raw-videofile mit folgendem Fehler ab

    Eigentlich sollte das gehen und das mit dem Faces bezieht sich auf Subtitles die ja nicht vorhanden sind. ;)

    zum Compilieren:
    der Patch muss vor dem compilieren angewendet werden ;)

    zum Asynchron:
    muss beides mal: 29,96 sein sorry nicht aufgepasst.

    mit wmv hab ich auch wenige Erfahrung sorry, wandle den Stream immer direkt um und extrahiere ihn nicht separat.

    Zitat

    Gutes Ergebnis erreicht! (ähnelt deinem), sehr fein, bigthx dafür!


    Freut mich, dass es gut geklappt hat.
    Wie gesagt, wenn das Quellmaterial besser ist sollte auch das Ergebnis besser sein.

    Cu Selur

    Ps.: hab über Nacht auch mal einen Rechner das Video encoden lassen sollte ca. ab 7:30Uhr bei http://selur.movie2digital.com/test liegen. (Wollte mal das Ganze Video mit --me tesa encoded sehen.)

    Eins ist noch aufgetreten :)

    Und zwar war der Ton bei einem Inputvideo nicht synchron, das Video war schon vorbei und der Sound lief noch weiter. Dann habe ich einfach mal bei MP4Box die Optionen "-fps 29.976 -par 1=1:1" entfernt. - Zack, funtkionierte.

    Dann habe ich allerdings bei einem anderen Video ebenfalls die Optionen weggelassen, und dann war dort der ton nicht synchron. Weist du zufällig, wie ich im vorraus erfahren kann, ob ich die option anwenden soll oder ob nicht?

    Zitat

    Weist du zufällig, wie ich im vorraus erfahren kann, ob ich die option anwenden soll oder ob nicht?


    "-fps 29.976" legt die Framerate fest, hier sollte die Framerate deines Inputfiles stehen, wenn es nicht 29.976 ist muss da ein anderer Wert hin.
    "-par 1=1:1"
    legt das PixelAspectRatio fest, wenn Deine Quelle ein anderes PixelAspektRatio hat muss da ein anderer Wert hin. ;)

    Cu Selur

    Irgendwas stimmt da mit einem Video nicht ganz, dass angeblich 29fps hat. Bei 29er einstellung hängt der Ton nach einigen minuten ein paar Sekunden hinterher. Bei 29.976 ists auch nicht ganz synchron.

    Gibt es eine Möglichkeit, die Framerate absolut exakt auszulesen, bevor ich encode?

    Zitat

    Gibt es eine Möglichkeit, die Framerate absolut exakt auszulesen, bevor ich encode?


    Nein. Gerade Material was mit variabler Framerate encoded wird spricht dagegen. :)
    Wenn man keine variable Framerate vorliegen hat, sind die Infos von MediaInfo meist recht zuverlässig.

    Cu Selur

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden