x265 mit hoher Farbtiefe versorgen

  • Da x265 mittlerweile nicht nur das Profil Main10, sondern auch Main12 unterstützt, wäre ich mal neugierig, wie man es denn mit Videomaterial mit hoher Farbtiefe versorgen kann, auch wenn ein Unterschied beim Abspielen vielleicht nicht offensichtlich wird. Nur rein technisch, wenn man was hätte.

    Ich habe zumindest ein wenig Material: Die Frames 11270 bis 12709 "graded_edit_%05d.tif" als TIFFs mit 16 bit pro Komponente von "Tears of Steel" in 4K-Auflösung. Die müssten also irgendwie als Sequenz in YUV420P16 (möglicherweise über ffmpeg, wohl eher als rohes YUV statt als Y4M) zu x265 gestreamt werden. Vielleicht auch unter Mithilfe von VapourSynth, das die TIFFs z.B. via L-SMASH Source für VS einlesen kann. So waren jedenfalls die letzten Vorschläge im doom9-Forum.

  • Ich glaube, ich habe es soweit geschafft. Hier ein Beispiel, wie ich aus den TIFFs in RGB444p16 zunächst einen Clip in YUV444p16 bekomme, auf 720p skaliere und letterboxe, und erst am Ende als YUV420p12 an x265 übergebe:

    tos_60s_720p.vpy

    Code
    import vapoursynth as vscore = vs.get_core()ret = core.imwri.Read('graded_edit_%05d.tif', firstnum=11270)ret = core.std.AssumeFPS(clip=ret, fpsnum=24)ret = core.fmtc.matrix (clip=ret, mat="709", col_fam=vs.YUV, bits=16)ret = core.resize.Spline(clip=ret, width=1280, height=536)ret = core.std.AddBorders(clip=ret, top=92, bottom=92)ret = core.fmtc.resample (clip=ret, css="420")ret = core.fmtc.bitdepth(clip=ret, bits=12)ret.set_output()


    tos_60s_720p.vpy.bat

    Code
    E:\Programme\VapourSynth\core64\vspipe --y4m tos_60s_720p.vpy - | E:\Programme\x265\x265 - -D 12 --y4m -o tos_60s_720p_main12.vpy.hevc

    Voraussetzung dafür ist, dass man das ImageMagick-VS-Plugin (test6) und das fmtconv-VS-Plugin installiert hat.

    Mit dem L-SMASH Source Plugin werde ich es vielleicht auch noch testen. Das gibt aber von vorn herein nur YUV aus, und da scheint nicht so klar zu sein, ob nach Rec601 oder Rec709.
    __

    Noch ein leicht abgewandelter Vorschlag von sneaker, weil resample auch skalieren kann (ich bevorzuge beim Verkleinern "Spline16", andere haben da sicher ihre Favoriten):

    Code
    import vapoursynth as vs
    core = vs.get_core()
    ret = core.imwri.Read('graded_edit_%05d.tif', firstnum=11270)
    ret = core.std.AssumeFPS(clip=ret, fpsnum=24)
    ret = core.fmtc.matrix (clip=ret, mat="709", col_fam=vs.YUV)
    ret = core.fmtc.resample (clip=ret, w=1280, h=536, kernel="spline16", css="420")
    ret = core.fmtc.bitdepth(clip=ret, bits=12)
    ret = core.std.AddBorders(clip=ret, top=92, bottom=92)
    ret.set_output()


    __

    Von wegen, kein HEVC-Decoder unterstützt bisher Main12 ... da hatte wohl eher x265 bisher keinen korrekten Bitstream erzeugt. Mit MPC-HC 1.7.9 sieht das ganze nicht mal schlecht aus (nur die Farben scheinen etwas ... "lebhaft"):

    tos_60s_720p_main12.vpy.hevc.mp4 (11 MB)

    Auf gute Zusammenarbeit:

    REGELN befolgen | SUCHE benutzen | FAQ lesen | STICKIES beachten

    3 Mal editiert, zuletzt von LigH (23. Juli 2015 um 16:28)

  • Von wegen, kein HEVC-Decoder unterstützt bisher Main12 ... da hatte wohl eher x265 bisher keinen korrekten Bitstream erzeugt. Mit MPC-HC 1.7.9 sieht das ganze nicht mal schlecht aus (nur die Farben scheinen etwas ... "lebhaft"):

    tos_60s_720p_main12.vpy.hevc.mp4 (11 MB)

    Spielt gut - auch unter ffplay und mpv.
    Kannst du noch ein Main10 zum Vergleich machen?

  • Ob es mit ffmpeg klappt, weiß ich nicht; kann ffmpeg auch RGB48-TIFFs verarbeiten? Und wenn ja, wie müsste die Kommandozeile aussehen? Wahrscheinlich hätte ich weniger Einfluss auf die interne Verarbeitung des Clips innerhalb von ffmpeg, könnte also weniger sicher sein, dass da bis zum Ende mit hoher Bittiefe gearbeitet wird.

    Zwischendurch ist für x265 noch mal ein neuer Patch mit aktuellen Lambda-Werten gekommen (was auch immer das genau ist, aber es ist wohl dafür verantwortlich, dass die Bitraten in vernünftigem Rahmen bleiben). Und ich habe die Y4M-Datei mal physisch herausschreiben lassen, das Auslesen und Verarbeiten der 4K-UHD-TIFFs ist wohl das langsamste an der ganzen Kette. So kann ich für weitere Tests dann weniger Zeit verschwenden. ;)

Jetzt mitmachen!

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