Der x265-Encoder entwickelt sich...

    x265 ist jetzt 0.6+

    Auf die Ausweitung des RD-Parameters wurde darin noch nicht deutlich hingewiesen (0..2 => 0..6). Der wird sicher noch eine wesentliche Rolle bei manchen davon abhängigen Funktionen spielen, aber die Abhängigkeiten werden nicht jedem klar sein (kürzlich erst bei Adaptiver Quantisierung deutlich geworden).

    Der Unterschied zwischen tskip und tskip-fast wäre vielleicht auch interessant. Ohne detaillierte Erklärung dürfte es dabei wohl Missverständnisse geben können, was deren jeweiligen Einfluss auf Geschwindigkeit und Effizienz angeht.

    Was mich an dem RD stört, ist das:

    Code
    /*Level of Rate Distortion Optimization Allowed */
typedef enum
{
    X265_NO_RDO_NO_RDOQ, /* Partial RDO during mode decision (only at each depth/mode), no RDO in quantization */
    X265_NO_RDO,         /* Partial RDO during mode decision (only at each depth/mode), quantization RDO enabled */
    X265_FULL_RDO        /* Full RD-based mode decision */
} X265_RDO_LEVEL;

    Quelle: https://bitbucket.org/multicoreware/…65.h?at=default
    nur 3 und nicht 7 Level kennt,.. -> scheint als ob die die enumeration einfach nicht mehr nutzen, bzw. zu faul waren sie zu aktualisieren und sie deshalb nicht mehr nutzen,..

    Zitat

    There should be a large "under construction" sign implied here. We've shifted 1 & 2 to 5 & 6 and gave ourselves some room for faster modes. This should get fleshed out and well documented in x265.h over the next week and a half. it's not quite finalized yet.


    -> scheint etwas chaotisch ;) (persönlich hätte ich dann mit dem 0.6er Upgrade noch nen Tick gewartet) aber schön zu sehen wie schnell die Entwicklung geht, wenn da viele Leute am Werkeln sind.

    Hi, ich versuche mich gerade an ein paar Testläufen. Aber x265 crashed sofort (x265.06+296)

    Code
    "C:\Program Files (x86)\Video Tools\avs2yuv-0.24\avs2yuv\avs2yuv.exe" "black.avs" -o - | "C:\Program Files (x86)\Video Tools\x265.06+296\x265.exe" --y4m --crf 25 --log 3 --bframes 4 --ref 3 --b-adapt 2 --me 2 --subme 7 --input-depth 10 --input-res 1024x576 --output black.h265  -

    Jemand 'ne Idee ?
    Liegt's am 10 bit Input ?
    Liegt's an y4m
    Liegt's an Win 7 ?
    An übermäßigem Speicherverbrauch scheint's nicht zu liegen ... vielleicht doch besser die 64Bit Variante benutzen ?

    Hier ist der Output:

    Dither_quantize + Dither_out

    Zitat

    Dither a clip to a given bitdepth. It’s possible to keep the resulting clip at the initial bitdepth of 16 or to reduce it to the specified depth.

    Zitat

    This function allows Avisynth to output 16-bit YUV pixel components. This is achieved by sending fake YV12 data, containing actually yuv420p16 data. Frame serving should be done via a rawvideo pipe, so the encoding application relies on information provided by the user, not Avisynth directly.

    Dann unbedingt im Raw-YUV-Modus übergeben und für x265 den Farbraum explizit festlegen (soweit ich mich an Posts von anderen erinnere, selber noch nicht versucht). Musst mal schauen, ob bei doom9 oder VideoHelp noch was dazu zu finden ist, aber ich bin mir recht sicher, dass darauf ausdrücklich hingewiesen wurde, dass Y4M hier nicht geht.

    Wie LigH schon anmerkte, y4m geht nicht.

    Code
    avs2pipemod -rawvideo "Pfad zum 10bit avs"


    siehe: http://forum.doom9.org/showthread.php?p=1660233
    und

    Code
    x265-16bit --input - --input-depth 10 --input-res 640x352 --fps 25 --frames 429 ...


    sollte gehen, wichtig ist hierbei, dass '--input-depth', ' --input-res', '--fps' und '--frames' angegeben werden.
    (falls das nicht gehen sollte, müsste man erst nach ffmpeg und dann nach x265 pipen)

    Cu Selur

    Ps.: das ganze 'fakeYV12'-Zeug mit Avisynth wird hoffentlich irgendwann man entfernt (vielleicht in Avisynth+?)

    Zitat

    Wieso eigentlich 10 bit?


    a. H.265 unterstützt keine 16bit output
    b. x265 unterstützt kein 16bit Input
    c. scheint im verlinkten Thread ja auch zu klappen ;)
    Wie gesagt, braucht man eventuell auch avs2pipemod -> ffmpeg -> x265, nutze selber keine Filter welche diese fakeYv12 Farbräume ausgeben, ist also alles Theorie. :)

    Ja schon; aber die Farbtiefe der Komponenten Y, U und V liegt doch nicht bei 10 bit? Ob nun der Encoder bei der Quantisierung mit 10 bit genauen transformierten Werten rechnet, ist ja ein ganz anderes Thema, das kümmert AviSynth ja nicht weiter.

    Ähm, so wie ich das verstanden habe sind's sehr wohl 10 bit pro Kanal die da von Avisynth kommen ...
    Aber vielleicht sollte man es tatsächlich bei 16 bit belassen (also ohne Dither_quantize) ...
    Es scheint sehr wohl 16bit fähige Versionen zu geben -> link
    Und meine ist von hier - Fllear build...
    Die Frage bleibt aber: Was macht der x265 damit, denn laut Standart ist eine Farbtiefe bis 16 bit nicht definiert, was diese Tabelle zeigt

    2 Mal editiert, zuletzt von may24 (23. Januar 2014 um 13:16)

    x265 kann definitiv 10 Bit-Encodierung, habe ich bereits selbst mit VapourSynth erfolgreich getestet.
    Wie Selur schrieb:
    - 16 Bit-Build (beherrscht auch 10 Bit, soll dann in Zukunft auch Profile mit mehr als 10 Bit übernehmen.)
    - --input-depth 10
    - benötigt zwingend 10 Bit raw als Input. Im Gegensatz zu x264cli sind weder Y4M noch 8 Bit als Input erlaubt.

    Builds hatte ich von x265.cc

    So, endlich hat's mal geklapptmit der CLI ...
    Ich habe zunächst RAW Dateien ohne Container erstellt. Doch jetzt wollte ich das Ganze in .mkv muxen, doch mkvmerge streikt und will den File nicht annehmen. Yamb schon gar nicht ;) Doch sollte nicht (laut JEEB) mkvmerge seit 6.2 HEVC unterstützen ? Ich benutze die 6.7 Version ...

    YAMB ist nur eine Benutzeroberfläche für MP4Box. Was damit möglich ist, hängt von der Version der GPAC MP4Box ab. Hol dir aktuelle "Nightly Builds" für Win32 (im Win64-Paket ist der Osmo4-Player nicht mit dabei). Die MeGUI verwendet auch eine Version, die HEVC unterstützt, wenn sie schon x265 testweise anbietet.

    Und ich glaube nicht, dass mkvmerge bereits seit Version 6.2 etwas über HEVC wissen kann, die muss doch uralt sein, wenn jetzt erst Version 6.7 aktuell ist. Im Changelog bis Version 6.7.0 tauchen "HEVC" oder "H.265" nirgends auf (und Version 6.2.0 kam April/Mai 2013 heraus).

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden