Der x265-Encoder entwickelt sich...

Zitat von x265_Project

We're just starting to work on 2-pass encoding. It will take more than one milestone.

Das klingt, als sei damit eher so um Version 1.5 als 1.2 damit zu rechnen...

.. oder 3.0 anstatt 2.0 man weiß ja nie was die jetzt als 'milestone' verstehen,....

Der letzte Patch soll den RAM-Bedarf wesentlich reduzieren. Da lade ich gleich mal die v1.1+193 hoch, vielleicht lässt sich damit ja nun (im Gegensatz zu älteren Versionen) 4K-Video gerade noch mit 32 bit encodieren...
__

Stabil bei 1,6 GB für preset slow, sieht vielversprechend aus.

Wie viel war es denn vorher?

An die 3 GB, wenn ich mich recht erinnere, war also auch auf 64-bit-OS mit 32-bit-LAA-EXE recht knapp und eher nicht ausreichend. Aber da jetzt gerade noch ein Encode läuft, teste ich das nicht noch mal parallel dazu.
__

v1.1+133: 2,1 GB — also zu viel für ein 32-bit-OS.
__

Der Speicherbedarf der aktuellen Version scheint nun abhängig von der Komplexität zu sein, bei Preset "slower" erreicht x265 etwa 1,9 GB (bei "slow" waren es 1,6 GB). Insofern ist es noch keine "Revolution", aber schon ein vernünftiger Schritt.

In Kürze wird es wohl auch Psy-RDO für RD-Level 2-4 geben, ein Patch dafür wurde eingereicht.

Wenn das bisher nur für RD-Level ab 6 verwendbar war, fehlt mir jetzt noch Level 5. Hab ich das übersehen, ist das dann mit inklusive, oder wird das eigene Anpassungen brauchen? ... Na, erst mal muss es noch nachweislich fehlerfrei arbeiten.

v1.1+202-e2ed009d296a mit dem angekündigten Psy-RDO-Patch für kleinere RD-Level.

Übrigens: Für Decoding-Tests wird empfohlen, die 64-bit-Version eines Players zu verwenden, vor allem wenn er libav-Decoder verwendet, weil ein 32-bit-Decoder für HEVC nicht so geschwindigkeitsoptimiert wäre.

Zitat von nevcairiel

Note when testing H.265 playback, you should most definitely use 64-bit versions of the player and decoder, as they are up to 50-100% faster, especially on 4K content (at least for anything FFmpeg based, like LAV/MPC-HC/etc.)
A lot of the decoder assembly is not compatible with 32-bit due to its complexity (and because the developers didn't want to spend time making it even more complex by allowing 32-bit support).

Zitat

Für Decoding-Tests wird empfohlen, die 64-bit-Version eines Players zu verwenden, vor allem wenn er libav-Decoder verwendet, weil ein 32-bit-Decoder für HEVC nicht so geschwindigkeitsoptimiert wäre.

Doof nur, dass viele Leute auf 32bit 'gezwungen' werden weil es keine 64bit Version von MadVR gibt,...

Von madVR erwarte ich, dass er die Chrominanz hübscher skaliert und dafür langsamer rechnet als direkte Renderer. Oder kann er überhaupt schneller sein? Vermutlich nicht bei Stromspar-Grafikkarten.

Nur weil es nicht schneller wird, durch 64bit heißt ja nicht, dass man 64bit User außen vor lassen muss und in diesem Fall heißt es dann: Entweder besseres HEVC decoding oder besseres Chroma handling,...

So, wir haben dann mal Version 1.2, mir fehlt nur noch eine ausführliche Zusammenfassung.

Nebenbei: Weiß einer wie die NAL unit codes der einzelnen Frames aussehen bei HEVC? (wollte FrameCounter auch HEVC tauglich machen)

Vielleicht hilft das PDF "Overview of the High Efficiency Video Coding (HEVC) Standard" (hier oder da), hat u.a. eine Tabelle der NAL Unit Types. Allerdings muss man für deren Verständnis wohl vorher noch ein paar Kapitel verstanden haben...

Vermutlich etwa das gleiche gibt es auch im RFC-Stil (ASCII-Hypertext).

Oder offiziell die Spezifikationen bei der ITU: Recommendation H.265 (04/13)

Zitat

Allerdings muss man für deren Verständnis wohl vorher noch ein paar Kapitel verstanden haben...

Genau deshalb frag ich ob da jemand ne Ahnung hat.

https://bitbucket.org/multicoreware/…el-profile-tier -> da freut man sich, dass Steve Borho irgendwie einsichtiger als Fiona ist.

...als Fiona Glaser?

Nun, ich würde dieser Argumentation wohl zustimmen: Wenn jemand den Parameter "--level" verwendet, dürfte er wohl dadurch hoffen, Einschränkungen dieses Levels zu erzwingen, wenn das im Zusammenspiel mit den restlichen Parametern möglich ist; welchen Sinn hätte es, absichtlich nur ein möglicherweise inkompatibles Level zu flaggen, wenn der Player dann wohl doch aussteigt, falls die Eigenschaften des Videostreams ihn überfordern?

Zitat

...als Fiona Glaser?

yup.

Zitat

welchen Sinn hätte es, absichtlich nur ein möglicherweise inkompatibles Level zu flaggen, wenn der Player dann wohl doch aussteigt, falls die Eigenschaften des Videostreams ihn überforder

Keine Ahnung, aber bei x264 ist der 'level&profile'-Eintrag nur ein Flag dem man erst mal nicht trauen kann und ich hatte es schon einige male angebracht und das Feedback bekommen, dass das so gewollt ist.
(+ Komissars force_level-patch existiert ja schon ne Weile,....)

Mir ging es auch um das fehlende "als" oben.

Hups,.. gefixed

In den aktuellen Versionen gibt es neben --psy-rd auch --psy-rdoq (leider noch nicht ausführlich dokumentiert); Kurzdoku dazu:

--psy-rd <0..2.0>             Strength of [B]psycho-visual rate distortion optimization[/B], 0 to disable. Default 0.000000
   --psy-rdoq <0..2.0>           Strength of [B]psycho-visual optimization in quantization[/B], 0 to disable. Default 0.000000

Ich hoffe mal, dass jemand den Unterschied zwischen den beiden verständlich erklären kann...