Der x265-Encoder entwickelt sich...

Nächster Meilenstein deklariert:

Zitat von Steve Borho

x265 version 1.7 has been released. This release contains a large amount of assembly code optimizations, some preliminary support for high dynamic range content, improvements for multi-library support, and some new quality features.

Full documentation at: http://x265.readthedocs.org/en/1.7/

This release simplifies the multi-library support introduced in version 1.6. Any libx265 can now forward API requests to other installed libx265 libraries (by name) so applications like ffmpeg and the x265 CLI can select between 8bit and 10bit encodes at runtime without the need of a shim library or library load path hacks. See --output-depth, and http://x265.readthedocs.org/en/1.7/a...rary-interface

For quality, x265 now allows you to configure the quantization group size smaller than the CTU size (for finer grained AQ adjustments). See --qg-size.

x265 now supports limited mid-encode reconfigure via a new public method: x265_encoder_reconfig()

For HDR, x265 now supports signaling the SMPTE 2084 color transfer function, the SMPTE 2086 mastering display color primaries, and the content light levels. See --master-display, --max-cll

x265 will no longer emit any non-conformant bitstreams unless --allow-non-conformance is specified.

The x265 CLI now supports a simple encode preview feature. See --recon-y4m-exec.

The AnnexB NAL headers can now be configured off, via x265_param.bAnnexB This is not configurable via the CLI because it is a function of the muxer being used, and the CLI only supports raw output files. See --annexb

Misc:
* --lossless encodes are now signaled as level 8.5
* --profile now has a -P short option
* The regression scripts used by x265 are now public, and can be found at: https://bitbucket.org/sborho/test-harness
* x265's cmake scripts now support PGO builds, the test-harness can be used to drive the profile-guided build process.

Alles anzeigen

Aus diesem Anlass:

x265 1.7+2-d7b100e51e82

Hinweis: Beginnend mit v1.7 sind jetzt andere Dateinamen enthalten, um sich leichter dem neuen Multi-library Interface anzupassen.

Die Befürchtung, neue Versionen könnten deutlich langsamer als vorherige sein, hat sich als Fehlalarm herausgestellt (Steve Borho hatte wohl versehentlich Builds mit Test-Compile-Parametern verglichen).

Es sind Patches in Vorbereitung, die das statische Linken von 8- und 10-bit-Bibliotheken in die gleiche EXE erlauben.

Gerade neu eingereichter Patch:

Zitat

--aq-mode <0|1|2|3>
...
3. AQ enabled with auto-variance and bias to dark scenes

AQ-Mode 3 ist wohl noch nicht drin; dafür funktioniert jetzt aber auch die Identifizierung der CPU-Features richtig (d.h. -D 10 -V warnt in 32-bit-Builds vor der "noasm"-Option), wenn eine alternative Encoder-Bibliothek verwendet wird, sowohl in einer Multilib-EXE als auch in einer 8-bit-EXE mit 10-bit-DLL).

Und da die Frage aufkam, ob Multilib auch XP-kompatibel sei ... nun ja, ich habe meine 32-bit-Versionen mit aktivierter XP-Kompatibilität compiliert. Ob es auch funktioniert, weiß ich nicht, ich habe kein XP mehr...

Dafür habe ich jetzt noch zusätzlich eine aktuelle MSYS-Umgebung von XhmikosR mit GCC 4.9.2 installiert; wahrscheinlich steige ich dann um. Bis dahin erst mal zwei parallele Builds mit der aktuellen "merge with stable"-Revision:

x265 1.7+266-68d089360477 (GCC 4.8.2)
x265 1.7+266-68d089360477 (GCC 4.9.2)

Mittlerweile wird wohl auch die Einbindung künftiger 12-bit-Encoder vorbereitet, erste Patches wurden übermittelt.

Ein 12-bit-Build scheint compilierbar zu sein, das werde ich mal testen. Allerdings ist davon auszugehen, dass die Assembler-Unterstützung hier noch minimal ist... oder um es mit den Worten von Rudolf Scharping (bzw. Ingo Appelt) zu sagen: "Laaaaangsaaaaam."

Ja, ich hab es hingekriegt ... nicht nur separate DLL und EXE, sondern (nach dem Patchen der linklist.rsp) auch eine Multilib-EXE von v1.7+282 mit 8 bit, 10 bit und 12 bit.

Ob ich die guten Gewissens veröffentlichen kann?

12bit :cool: wooohooo ...
Welche Parameter muß ich übergeben um das zu aktivieren ? (wird auf Debian mit cmake und cross-compiler gebaut ...)

may24: kleine Warnung bzgl. 12bit HEVC: Es wird aktuell von keinem Decoder unterstützt, sprich man müsste x265 sagen, dass es y4m als Output liefert und dieses dann vergleichen.

-----

Mal am Rande, weiß jemand genaueres wie '--master-display <string>' und '--max-cll <string>' zu nutzen sind?

Der wichtigste Fehler war, dass mehrere zu linkende Bibliotheken durch Semikola getrennt werden müssen, nicht durch Leerzeichen:
-DEXTRA_LIB="x265_main10.a;x265_main12.a"
Bei den anderen Compilerumgebungen (außer MSYS) war das wohl korrekt.

Egal ... es ändert sich schon wieder was im Multilib-Skript. Mittlerweile soll es auch schon möglich sein, eine Multilib-DLL zu erstellen (das scheint zu funktionieren), und außerdem ein All-In-One-Binary, also eine Multilib-CLI-EXE, die auch noch die Funktionen wie eine DLL exportiert (so könnten andere Programme die EXE einbinden, als ob sie aus einer DLL die Funktionen dynamisch laden; das jedoch scheint bei mir mit v1.7+298 noch nicht zu klappen, MS PEScanner jedenfalls erkennt in der EXE kein Export-Kapitel).

Anscheinend wurde die Liste mit zu exportierenden Funktionen (x265.def) nur in die EXE übernommen, wenn der MSVC verwendet wird. Der GCC kann das aber auch. Daher präsentiere ich – nach einer kleinen Anpassung in der Vorlage für die CMakeLists.txt – die ersten "All-In-One" x265.exe v1.7+298, die man auch wie eine DLL linken könnte (theoretisch, noch nicht getestet):

x265 1.7+298-523540864864 AIO (GCC 4.8.2)
x265 1.7+298-523540864864 AIO (GCC 4.9.2)

Mit dem 12-bit-Code geht es ein wenig voran... aus der Entwickler-Mailingliste:

Zitat von Steve Borho

Thanks to Min's hard work the Main12 profiles are now functional if you stick with just the C code (either build with ENABLE_ASSEMBLY=OFF, or run with --no-asm)

I'm working on a patch to ffmpeg that will enable feeding 12bit inputs into our encoder (hopefully your source video is 12bits per channel or higher)

known issues:

• the asm testbench reports many primitives are wrong for Main12 (mostly constant or dynamic range issues)
• there are probably primitives that are passing tests but are still broken (because the test bench is not always catching dynamic range issues)
• Main12 needs unique lambda tables, just as Main10's differ from Main. Until this gets resolved, Main12 compression efficiency will suffer greatly.
• There are likely other places where the code assumes HIGH_BIT_DEPTH means Main10, these will only be found by code review

If anyone would like to work on any of these, please respond with a description on which area(s) you are working.

Alles anzeigen

Für mich heißt das also: Egal ob bisher kein Decoder das korrekt wiedergeben kann, x265 kann HEVC im Main12-Profile bisher noch nicht einmal völlig korrekt erzeugen. Aber in ein paar Wochen (mehr oder weniger) kann das schon besser aussehen; wenn auch noch in langsamem C-Code.

-> dann warte ich denke ich erst mal noch etwas

Der Fehler mit dem nicht ganz vollständigen full-help sollte korrigiert worden sein, hoffentlich auch die (vermutlich durch die gleiche Ursache: versehentlich doppelt zurückgesetzte Parameter in Langform) ignorierten Zonen. Und wenn ich Patch 8f60362f8555 richtig deute, dann sollte auch Assembler-Unterstützung für das Main12-Profil bis SSSE3 bereits teilweise verfügbar sein. Ein neues Release spare ich mir aber bis Ende dieser oder Anfang nächster Woche...

Zitat von LigH

Und wenn ich Patch 8f60362f8555 richtig deute, dann sollte auch Assembler-Unterstützung für das Main12-Profil bis SSSE3 bereits teilweise verfügbar sein.

Welcher Vorteil ergibt sich denn durch Main12 jetzt z.B. gegenüber Main10?

Es gibt von Seiten der Entwickler die klare Ansage, dass Main12 eigentlich nur nützt, denn man HDR-Material als Original hat; wenn die Basis nur 8-bit RGB oder 8-bit YUV ist, dann bringt Main12 gegenüber dem Vergleich zwischen Main und Main10 keine merklichen Vorteile mehr, die Effizienz wird geringer sein.

Problem bei HDR Material: Welcher Decoder kann denn damit umgehen? (muss man ja irgendwie an x265 liefern mit SMPTE 2084/2086 und den noch total unklaren Optionen –master-display und –max-cll)
+ Kommen aktuelle Displays eigentlich mit HDR klar?

HDR war vielleicht falsch ausgedrückt, eher: Hohe Farbauflösung. Also z.B. Raytracer-Rendering mit 16 bit pro Kanal. Die Entwickler haben u.a. medizinische Videos als Beispiele genannt.

Weil es heir am Besten hineinpasst:

HEVC Lizenzpreise sind raus: http://hevcadvance.com/pdf/RoyaltyRatesSummary.pdf

Besonders springt einem da ins Auge:
a. die Preise sind einiges angestiegen im Vergleich zu AVC (siehe: http://www.mpegla.com/main/programs/avc/Documents/avcweb.pdf)
b. es gibt keine Freigrenze (bei AVC waren die ersten 100k units pro Jahr frei,..)
-> mal schauen was das noch gibt.

So wie ich das momentan sehe müsste theoretisch jeder der einen Software HEVC Decoder oder Encoder zur Verfügung stellt 1.1€ pro Download zahlen.
Falls die (hoffentlich) ist es die schlechte Presse nicht Wert und man wird kleinen Hobby-Toolentwicklern und Leuten die z.B. x265 zum Download anbieten da nicht aufs Dach steigen.
(ansonsten wird der HEVC Support in freien Tools wohl stark einbrechen)