Wie encodiert man AVC mit x264 mit 10 bit?

  • Guten Abend Leute,

    ich hab ein Problem, und zwar möchte ich auf 10-Bit encoden. Warum? Ich möchte Animes mit Untertitel gerne auf Youtube hochzuladen, hab aber keine Lust auf eine sehr große Ausgangsdatei, nachdem Encode. Ich hab gehört bzw. gelesen, dass wenn man 10-Bit encodet, die Datei geringer sein soll und die Farbqualität besser. Da ich in Encoding ein ziemlicher Laie bin oder besser gesagt, ich komme mit dieser Fachsprache nicht klar. Ich bräuchte am besten, ein einfaches Tutorial, dass mir erklärt Wie ich mit Megui oder Staxrip auf 10-Bit Encode.

    Ich hoffe ihr könnt mir helfen.

    Danke im Vorraus
    Vincent66

    P.S. Ich habe bereits SuFu benutz, ich habe leider nicht relevantes bzw. nur Bruchstrücke von Informationen gefunden. Verzeiht bitte, falls diese Frage schonmal vorkam.

  • 1) Hast du das Urheberrecht, um Anime weltweit zu veröffentlichen?

    2) YouTube rechnet Videos für niedrigere Auflösungen (240p, 360p, 480p) immer mit recht geringer Qualität um. Nur HD-Videos bleiben eventuell erhalten wie hochgeladen. Aber ich würde schon stark zweifeln, dass der Adobe Flash-Player 11 in der Lage ist, AVC-Video mit 10 bit pro Komponente korrekt zu decodieren, oder dass der von YouTube verwendete Konverter 10-bit-AVC konvertieren kann.

  • weñ man bei youtube ein 10bit video hochläd, dann ist für den yt-transcoder doch vorteilhaft, wenn das ausgangsmaterial eine hörere qualität hat...

    bei fansub-gruppen wird es sicherlich probleme geben nicht jeder hat ein 10bit decoder
    und wenn es am "dvd"-player angeschaut werden will, wird es da auch massive probleme geben.

    zu megiu... nimm die einfach die x264.exe in der 10bit version und ersetze die vorhandene im megui programmverzeichnis... vielleicht klappt es ja... :P

    variationen von x264 gibt es auf http://x264.nl
    nimm die 32bit version...

  • man kann:
    - 10bit Genauigkeit verwenden:
    Vorteil: bessere Kompression durch genauere Werte siehe: http://x264.nl/x264/10bit_03-…deo_quality.pdf
    Nachteil: kann nur am Rechner wiedergegeben werden, braucht sowohl beim En- als auch Dekodieren mehr Power (man sollte high10/high422/high444 als Profil verwenden)
    (wird entschieden dadurch, dass man eine bestimmte .exe verwendet)

    - einen anderen Farbraum als 4:2:0 verwendet:
    Vorteil:genauere Farbdarstellung, keine/geringere ChromaSubSampling-Probleme
    Nachteil: mehr Informationen -> größere Datei; kann nur am Rechner wiedergegeben werden, braucht sowohl beim En- als auch Dekodieren mehr Power (man sollte abhängig vom Farbraum high422 oder high444 verwenden)
    (wird entschieden dadurch, dass man den Output Farbraum entsprechend angibt; Achtung: entweder kein oder ein Profile angeben, was den Farbraum auch unterstützt, siehe: x264 --fullhelp)

    -64bit Version:
    Vorteil: ist flotter als die 32bit Version
    Nachteil: benötigt einen 64Bit Rechner beim Encoding; benötigt einen entsprechenden Encoder und kann nur mit Avisynth 64bit direkt gefüttert werden, dies ist aber i.d.R. kein Problem da aktuelle GUIs meist Pipes verwenden um nach belieben 64bit und 32bit Komponenten austauschen zu können

    ----
    -10bit sollte mit StaxRip möglich sein, wenn man die .exe austauscht (sofern sich unabhängig davon nicht irgendwelche Parameter geändert haben die StaxRip noch nicht kennt)
    -Anderer Farbraum wird mit StaxRip eventuell möglich sein, müsste man testen, ob es hilft: 1. den Output Farbraum und das Profile als CommandLineAddition (k.A. ob StaxRip sowas hat) anzugeben 2. das verwendete AvisynthSkript entsprechend anpasst.
    -> generell würde ich da nicht StaxRip sondern ne andere GUI verwenden,..


    Cu Selur

  • weñ man bei youtube ein 10bit video hochläd, dann ist für den yt-transcoder doch vorteilhaft, wenn das ausgangsmaterial eine hörere qualität hat...

    Aber nur wenn der von YouTube verwendete Decoder überhaupt mit 10-bit-AVC klarkommt. Wenn nicht, hat man kein besseres Ausgangsmaterial, sondern gar kein verwendbares.

    Mal abgesehen davon ist die Qualität bei LD-Videos auf YouTube oft so mies, dass die Winzigkeit an Vorteil von 10-bit (die ohnehin nur bei ganz bestimmtem Material überhaupt deutlich wird) in der Kopie vernichtet wird. Ich glaube, da wird sogar teilweise noch H.263 in FLV verwendet.

  • Zitat

    Wenn nicht, hat man kein besseres Ausgangsmaterial, sondern gar kein verwendbares.


    Stimmt, ob die YouTube Decoder mit anderen Farbräumen als 4:2:0 und 10bit Genauigkeit klar kommen wäre sicher erst zu testen.

    Zitat

    Vorteil von 10-bit (die ohnehin nur bei ganz bestimmtem Material überhaupt deutlich wird)


    Zumindest bei meinen Tests (1pass constant quantizer) war bis dato 10bit Material immer kleiner als 8bit Material, was YouTube daraus macht kann ist sicher ne Frage für sich, aber zumindest falls die Decoder damit klar kommen, ist es sicher nicht verkehrt als User das Qualitativ beste Material was man hat YouTube als Basis zu geben,... (ob es eventuell sinnig ist das eigene Material eventuell vorher noch speziell zu filtern, smoothing&co wäre sicher auch interessant für Leute die oft was bei youTube hochladen,..)

    Cu Selur

  • Andere Farbräume gehen, aber 10bit bezweifel ich auch ein bisschen.

    Die Qualitätsstufen am Player sind halt in der Tat keine bloße Auflösungseinstellung, sondern auf höherer Stufe gibt Youtube auch deutlich mehr Qualität. Audio als auch Video.

    Man kann sogar eine Hochskalierung mit Lanczos4 in Erwägung ziehen, auf zb 2048x1152 (ich brauchs nicht, mein Monitor kann eh 2048x1152 nativ und lade daher auch 2048x1152 Videos auf Youtube) und man wird das deutlich bessere Bild auf Youtube haben. Zum einen ist dann "Original" verfügbar, wo Youtube das Video in der originalen Auflösung von 2048x1152 abspielt und da gibt Youtube auch nochmal deutlichst mehr Videoqualität als bei 1080p. Und auch die kleineren Qualitätsstufen sehen natürlich hübscher aus, wenn man besseres Quellmaterial hochgeladen hat.

  • Aber nur wenn der von YouTube verwendete Decoder überhaupt mit 10-bit-AVC klarkommt. Wenn nicht, hat man kein besseres Ausgangsmaterial, sondern gar kein verwendbares.

    Habe es gerade getestet: Geht bei YouTube nicht. Das Video ist voll von den Artefakten, die man bereits von reinen 8-bit-Decodern kennt.

    - einen anderen Farbraum als 4:2:0 verwendet:
    Vorteil:genauere Farbdarstellung, was z.B. das leidige Problem des Bandings beseitigt

    Beseitigung von Banding ist ein Vorteil der 10-bit-Genauigkeit, gehört in Deiner Liste also in den Absatz darüber.

    2) YouTube rechnet Videos für niedrigere Auflösungen (240p, 360p, 480p) immer mit recht geringer Qualität um. Nur HD-Videos bleiben eventuell erhalten wie hochgeladen. Aber ich würde schon stark zweifeln, dass der Adobe Flash-Player 11 in der Lage ist, AVC-Video mit 10 bit pro Komponente korrekt zu decodieren

    Der flash-interne Decoder ist sogar in der Lage 10-bit zu decodieren. Gibt im Moment glaube ich nur einen kleinen Fehler, bei dem rechts ein pinker(?) Rand erscheint. Ist allerdings gemeldet, und da Adobe schon einmal mit dem Feature geworben hat, besteht sogar die Chance, daß es irgendwann gefixt wird.

    Vielleicht teste ich das gleich auch nochmal kurz.

    /edit:

    Ja, wird, mit Ausnahme des pinken Streifens, korrekt decodiert. Auch der Software-Fallback klappt. Obwohl ich mich jetzt frage, ob der Streifen playerabhängig ist. Habe einen älteren JWPlayer genutzt.

    Einmal editiert, zuletzt von sneaker2 (28. Januar 2012 um 16:58)

  • @ De-M-oN:

    Nur ein feineres Chroma-Subsampling macht noch keinen anderen "Farbraum"; ob 4:2:0 oder 4:2:2 oder 4:4:4 – YUV ist YUV (statt RGB als wirklich "anderer Farbraum").


    @ sneaker2:

    Ich habe mal feststellen müssen, dass der YouTube-Konverter insbesondere nur mäßige AVC-Komplexität unterstützt, also keinesfalls mit B-Frames und Referenz-Frames übertreiben. Insofern ist "brutale Dateigrößen-Minimierung" also nicht sinnvoll.

  • @ sneaker2:

    Ich habe mal feststellen müssen, dass der YouTube-Konverter insbesondere nur mäßige AVC-Komplexität unterstützt, also keinesfalls mit B-Frames und Referenz-Frames übertreiben. Insofern ist "brutale Dateigrößen-Minimierung" also nicht sinnvoll.

    Kann ich so nicht bestätigen. Habe erst kürzlich wieder einen Test durchgeführt mit massig bframes und 16 ref frames bei 1080p. Einzig die Videovorschau blieb grau/schwarz, das Video wurde aber letztendlich korrekt umgewandelt.

  • Nun ja, dann entwickelt sich der Konverter vielleicht auch weiter. Als ich die HD-Videos für unsere Terrassen, Pavillons und Saunen erstmalig hochgeladen hatte, ging die Konvertierung noch schief, und ich musste dann noch mal neu encodieren und hochladen. Mit "--preset slow" ging es.

  • Zitat

    Beseitigung von Banding ist ein Vorteil der 10-bit-Genauigkeit, gehört in Deiner Liste also in den Absatz darüber.


    Kann mir dann mal bitte jemand erklären wie banding entsteht, irgendwas muss ich da wohl falsch im Kopf haben?
    Nach meinem Verständnis von Banding entsteht dadurch das Farbübergänge nicht genau genug im Zielfarbraum dargestellt werden können, weil nicht genug bits vorhanden sind. Idealerweise sollte der Decoder dieses per Dithering mindern, aber ein Wechsel auf 10bit sollte meinem Verständnis nach keine genauere Darstellung des 4:2:0er Farbraums und damit Verhinderung von Banding zur Folge haben,.. (falls eventuelle 10bit Decoder besseres dithering vornehmen wäre das ne andere Geschichte)

  • "4:2:0" ist kein "Farbraum", nur eine Verhältnis der Auflösung der Farbigkeitskomponenten im Vergleich zur Helligkeitskomponente (Chroma-Subsampling).

    Es geht um die Konvertierung zwischen RGB und YUV sowie dabei entstehende Rundungssfehler, wenn man das nur mit 8 bit Genauigkeit pro Komponente berechnet. Denn danach wird ja auch noch deren Verlauf nach Frequenzkomponenten quantisiert, höhere Auflösung der YUV-Werte hilft also auch bei der Genauigkeit der Sample/Frequenz-Transformation (DCT oder H.264-Integer~).

    Zumindest glaube ich, dass das der Kern ist... keine Gewähr. :redface:

    In dem Fall wäre es auch unsinnig, x264 mit 10-bit-Berechnung mit YV12 aus AviSynth 2.5x zu füttern. Das Mehr an Bittiefe sollte mindestens aus der Interpolation eines feineren Chroma-Subsampling stammen, wenn nicht gar aus tatsächlich feiner gefiltertem Video.

  • @ De-M-oN:

    Nur ein feineres Chroma-Subsampling macht noch keinen anderen "Farbraum"; ob 4:2:0 oder 4:2:2 oder 4:4:4 – YUV ist YUV (statt RGB als wirklich "anderer Farbraum").

    Ich hatte mal 'ne 13 GB RGB verlustfrei komprimierte Datei hochgeladen und hat Youtube anstandslos encodiert.


    Zitat

    @ sneaker2:

    Ich habe mal feststellen müssen, dass der YouTube-Konverter insbesondere nur mäßige AVC-Komplexität unterstützt, also keinesfalls mit B-Frames und Referenz-Frames übertreiben. Insofern ist "brutale Dateigrößen-Minimierung" also nicht sinnvoll.

    Jemand anders den ich im ICQ hab, hat spaßeshalber mal Placebo Preset verwendet (mit subme 11, und noch ausgeweitet mit me range 64^^), 2048x1152 Auflösung und hat youtube anstandslos ohne Fehler encodiert.

    Wichtig ist nur, das keine Kopfdatenkompression verwendet wird. Das mag Youtube oftmals gar nicht.

  • Nun ja, dann entwickelt sich der Konverter vielleicht auch weiter. Als ich die HD-Videos für unsere Terrassen, Pavillons und Saunen erstmalig hochgeladen hatte, ging die Konvertierung noch schief, und ich musste dann noch mal neu encodieren und hochladen. Mit "--preset slow" ging es.

    Könnte durchaus hinkommen. Deine Videos sind von Ende 2010, meine ersten Tests von Mitte 2011.

    Kann mir dann mal bitte jemand erklären wie banding entsteht, irgendwas muss ich da wohl falsch im Kopf haben?
    Nach meinem Verständnis von Banding entsteht dadurch das Farbübergänge nicht genau genug im Zielfarbraum dargestellt werden können, weil nicht genug bits vorhanden sind. Idealerweise sollte der Decoder dieses per Dithering mindern, aber ein Wechsel auf 10bit sollte meinem Verständnis nach keine genauere Darstellung des 4:2:0er Farbraums und damit Verhinderung von Banding zur Folge haben,.. (falls eventuelle 10bit Decoder besseres dithering vornehmen wäre das ne andere Geschichte)

    Besseres Dithering oder ähnliches hat mit dem Decoder eigentlich nichts zu tun, da im H.264-Standard genau festgelegt wird, wie die Ausgabe zu sein hat. Alle Decoder sind hier in der reinen Decoding-Qualität also identisch (bzw. sollten es sein). Dithering ist auch nur ein Verfahren zum Reduzieren der Farbtiefe, ohne daß Banding entsteht. Was Du meinst, wäre Debanding, wie es z.B. ffdshow als Filter anbietet.
    Die Reduzierung der Bandingartefakte resultiert meines Wissens aus der höheren Genauigkeit der internen H.264-Berechnungen, welche bei 8bit-H.264 auch auf 8 Bit begrenzt sind. Bei den verschiedenen Encodierstufen kumulieren sich die Rundungsfehler auf. Bei 9 Bit werden diese Rundungsfehler um 50 % reduziert, bei 10 Bit um 75%. Die Ausgabefarbtiefe ist in der Praxis irrelevant - die meisten Monitore sind sogar auf 6 Bit begrenzt. Dark Shikari hatte da mal was zu geschrieben bzw. als die 10bit-"Welle" aufkam, kursierten hier auch mal ein paar PDFs. Ich glaube "wirklich" verstehen wird man es erst, wenn man sich tiefer mit der dahinterstehenden Mathematik beschäftigt. Ansonsten muß man es einfach als gegeben hinnehmen.

    /edit:
    gleich drei Zwischenposts, ich schreibe einfach zu langsam.

    Einmal editiert, zuletzt von sneaker2 (28. Januar 2012 um 17:51)

  • Zitat

    Besseres Dithering oder ähnliches hat mit dem Encoder eigentlich nichts zu tun,..


    Stimmt hab dithering mti debanding vertauscht :) werde mal im englischen Forum suchen ob dich die Äußerungen von Darkshikari dazu finde,..
    -> http://x264.nl/x264/10bit_03-…deo_quality.pdf Seite 9 ist vermutlich das worauf Du anspielst :)

Jetzt mitmachen!

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