Der x265-Encoder entwickelt sich...

  • Ich hatte noch nicht erwähnt, dass x256 "progressiv encodiert", das heißt: Je höher die Bitrate, je feiner die Quantiserung, umso mehr Zeit braucht er zum Sammeln aller Details, die sich da unterbringen lassen. Da kann CRF 18 schon fast doppet so lange brauchen wie CRF 28.

    Das bedeutet dann aber auch das es bei geringerer CRF Einstellung nicht zu "Blockartefakten" kommt sondern die Details des Bildes Reduziert werden oder nicht? Habe nun 3 Encodes gemacht CRF 19,20,24 sowie x264 CRF19, sehe keine Unterschied... allerdings kann ich die Bilder nicht direkt Vergleichen... der Unterschied in der Dateigröße ist jedenfalls erstaunlich...

    Achso, habe bei Handbrake Nachgefragt, die nutzen ebenso wie bei x264 CRF auch wenn es anders heisst...

     MacBookPro 15" 2017 | 4 x 3,1 Ghz | 16 GB Ram | 1TB SSD NVME |

  • Dass man nicht so schnell Blockartefakte sieht, wenn die Bitrate knapp wird, kann daran liegen, dass sie stärker/"besser" gefiltert werden. Es nähert sich dann eventuell einer Art Cartoon-Effekt an: Man sieht dann noch ein paar scharfe Kanten, ansonsten aber eher ziemlich glatte Flächen dazwischen. Aber auch WMV war für eher stärkeres Filtern berüchtigt. Es fehlt eben in jedem Fall an Details; nur sieht der Verlust mehr oder weniger störend aus.

  • Gibt es eigentlich schon Hardware, die das abspielt.
    (Mal vom PC abgesehen.)

    Eine Standard-Android-Box mit aktuellem Prozessor RK3288 sollte das können, z.B. diese.

    Zitat

    Real 4K x 2K supported, H.265 decoder

    GPU: *****ded Mali-T7 3D GPU, OpenGL ES 1.1/2.0 /3.0,and OpenCL 1.1,

    Suport 8Kx8K video input & 4Kx4K output.

    Gruß

    akapuma

    Wer weiß, wovon er redet, kann es sich leisten, sich verständlich auszudrücken.
    Besucht auch meine Homepage: http://akapuma.info

  • Heute mal außer der Reihe ein paar Builds, weil ich grad mit jb_alvarado's media-autobuild_suite zu tun habe.

    x265_1.5+420-24fdb661bb57.7z (MSYS, MinGW32, GCC 4.8.2, package from xhmikosr + 4x cross compile script, EXE+DLL)
    x265_1.5+420-24fdb661bb57.GCC492.7z (MSYS2, MinGW64, GCC 4.9.2, media-autobuild_suite, EXE only, stripped and UPX'ed)

    Ach ja, außerdem: Windows ist so nett und versetzt einen PC auch dann gern mal in einen Stromspar-Modus, wenn der eigentlich ordentlich was zu rechnen hat. Manche GUIs starten einen Encoding-Job deshalb mit Flags, die das verhindern sollen. Da ich x265 eher noch in der Batchdatei teste, habe ich ähnliches auch für CLI gesucht (gerade wenn ich dafür PCs verwende, die mir jetzt nicht direkt gehören, die ich also nicht einfach so umkonfigurieren will). Ich werde mal testen, ob unsleep hilft...

  • Heute wurde ein Patch vorgeschlagen, mit dem x265 unter Windows selber dafür sorgen will, den automatischen Ruhezustand zu verhindern. Ich nehme aber an, ein manueller bleibt möglich?

    Außerdem wird es in Zukunft wohl einfacher möglich sein, über eine cmake-Option die Compilierung optimiert für die vorhandene Architektur durchzuführen (-march=native).

  • Neue Produkte am 1. April machen mich ja manchmal etwas nervös, aber ... die meinen es wohl ernst:

    Multicoreware veröffentlicht "x265 HEVC Upgrade", ein Bundle aus einem Konvertierprogramm für MP4-Videos, basierend auf x265 als HEVC-Encoder, und UHDcode als HEVC-Decoder für DirectShow.

    Der "empfohlene Verkaufspreis" für dieses Bundle soll bei 29,95 USD liegen; für kurze Zeit ist es aber kostenlos herunterzuladen.

    https://x265.com/
    https://x265.com/store/index.php/download-free/ (einfach "Proceed to Checkout" klicken für einen 100% rabattierten Kauf, der lediglich eine Registrierung erfordert)

  • Neue Option ab etwa v1.6+115: "implementation of fine grained adaptive quantization" mit

    Code
    --qg-size <int>               Specifies the size of the quantization group (64, 32, 16). Default 64

    x265 1.6+117-095ed87526e5
    __

    P.S.: Im Moment bekomme ich nur die Syntax als Fehlermeldung angezeigt, wenn ich --qgsize 16 an die Parameter anhänge.

    P.P.S.: Mein Fehler: Noch einen Bindestrich dazwischen, --qg-size

  • Zitat

    Enable adaptive quantization for sub-CTUs. This parameter specifies the minimum CU size at which QP can be adjusted, ie. Quantization Group size.
    Allowed range of values are 64, 32, 16 provided this falls within the inclusive range [maxCUSize, minCUSize].
    Experimental. Default: same as maxCUSize

    Quelle: http://x265.readthedocs.org/en/latest/cli.…option--qg-size
    Hmm,.. stehe irgendwie auf dem Schlauch warum ist denn maxCuSize der Default? Würde minCuSize nicht mehr Sinn machen?

  • Aktuelle Builds sollen nun auch die Bitstream-Variante des HEVC-Formates mit Startcodes nach "Anhang B" ausgeben können. Allerdings scheint das CLI dafür noch keine Option veröffentlicht zu haben. — P.S.: Soll auch nicht. HEVC-Rohdaten sollen immer nach "Annex B" ausgegeben werden; das andere Format wäre nur interessant, wenn direkt in einen Kontainer gemultiplext wird.

    Außerdem wird in Kürze darauf hingewiesen, dass NUMA-Pool-Unterstützung (Mehr-Sockel-Threadpools) mindestens Windows 7 voraussetzt – nicht nur Vista. Mal schauen, ob dann explizit zwischen Kompatibilität oder Leistung nicht nur für 32 bit (noch XP oder schon Vista), oder auch für 64 bit (noch Vista oder schon W7+ mit NUMA) bereits beim Compilieren unterschieden werden muss. Für meine MinGW-Builds wäre die Entscheidung dann wohl: 32 bit für XP, 64 bit für W7+.

  • ich habe nun ein paar Testdurchgänge mit verschiedenen CRFs gemacht und kann nun nachvollziehen warum einige meinen das wäre eher was für Zeichentrick oder Animes.
    Trotz "tune grain" schaffe ich es nicht feines Rauschen so abzubilden wie x264 das auch bei eher niedrigen Bitraten kann, bei ungefähr gleicher Dateigrösse. Grobes Rauschen in einer Szene wird bei "tune grain" gut dargestellt, sobald es aber um feineres Korn geht bügelt x265 das irgendwie unter, es scheint so eine "Schwelle" zu geben, "Alles oder Nichts" sozusagen... Gibt es ein Kommando mit der ich diese Schwelle beeinflussen kann ?

  • Ich erinnere mich, dass im doom9-Forum jemand (mandarinka oder foxyshadis?) Hinweise gepostet hat, warum so etwas passiert, und es passiert wohl vor allem bei größeren Coding Units (32², 64²).

    Ob man bei der Lösung schon weiter ist, weiß ich nicht, aber eventuell kann man bei aktuellen Builds mal diesen Parameter testen:

    Code
    --qg-size <int>               Specifies the size of the quantization group (64, 32, 16). Default 64
  • x265 1.6+417-f2081ef64fd2 veröffentlicht jetzt einen Schalter, um die Auflösung der Ausgabe und der internen Daten zur Laufzeit auszuwählen:

    Code
    -D/--output-depth 8|10           Output bit depth (also internal bit depth). Default [I]{8|10}[/I]

    Der Standard ist abhängig von der Compilierungsoption.

    Jetzt frage ich mich: Wenn ein 64-bit-Encoder sowohl 8 als auch 10 bit Tiefe unterstützen soll, müsste dann nicht in beiden Compilierungsfällen ein "mehr oder weniger identisches" Ergebnis mit beiden Code-Gruppen herauskommen, damit überhaupt zur Laufzeit ausgewählt werden kann? Die normale und die HBD-Variante unterscheiden sich aber trotzdem noch (sowohl die DLLs als auch die EXEs). Ich zweifle noch, dass das wie geplant funktioniert (hab's aber noch nicht getestet)...

    Außerdem ist in diesem Paket DETAILED_CU_STATS aktiviert.
    __

    Ich glaube, der Depth-Parameter erlaubt nur einer EXE, zwischen beiden Bibliotheken zu wählen, wenn beide eingelinkt werden. Die bisherigen Make-Dateien wählen aber immer nur eine der beiden aus, bisher gibt es also nur entweder 8 oder 10 bit. Um eine EXE zu erschaffen, die sowohl-als-auch unterstützt, würde man wohl am einfachsten eine dynamische Version bauen, welche die jeweilige DLL mit entweder libx265_main oder libx265_main10 einbindet. Glaube ich. Liest sich jedenfalls für mich so in der Dokumentation.

  • x265 1.6+417-f2081ef64fd2 veröffentlicht jetzt einen Schalter, um die Auflösung der Ausgabe und der internen Daten zur Laufzeit auszuwählen:

    Code
    -D/--output-depth 8|10           Output bit depth (also internal bit depth). Default [I]{8|10}[/I]

    Der Standard ist abhängig von der Compilierungsoption.

    Jetzt frage ich mich: Wenn ein 64-bit-Encoder sowohl 8 als auch 10 bit Tiefe unterstützen soll, müsste dann nicht in beiden Compilierungsfällen ein "mehr oder weniger identisches" Ergebnis mit beiden Code-Gruppen herauskommen, damit überhaupt zur Laufzeit ausgewählt werden kann? Die normale und die HBD-Variante unterscheiden sich aber trotzdem noch (sowohl die DLLs als auch die EXEs). Ich zweifle noch, dass das wie geplant funktioniert (hab's aber noch nicht getestet)...

    Außerdem ist in diesem Paket DETAILED_CU_STATS aktiviert.
    __

    Ich glaube, der Depth-Parameter erlaubt nur einer EXE, zwischen beiden Bibliotheken zu wählen, wenn beide eingelinkt werden. Die bisherigen Make-Dateien wählen aber immer nur eine der beiden aus, bisher gibt es also nur entweder 8 oder 10 bit. Um eine EXE zu erschaffen, die sowohl-als-auch unterstützt, würde man wohl am einfachsten eine dynamische Version bauen, welche die jeweilige DLL mit entweder libx265_main oder libx265_main10 einbindet. Glaube ich. Liest sich jedenfalls für mich so in der Dokumentation.

    Perfekt wäre es wenn Nutzer (und GUI Autoren :) ) sich um nichts kümmern müssten außer eben den --profile Schalter.

    http://x265.readthedocs.org/en/latest/cli.…option--profile

Jetzt mitmachen!

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