Der x265-Encoder entwickelt sich...

Yo, Quelltext + geguckt welche Command Line Switches zu den internen Parametern passen.

Zitat

Allerdings bezweifle ich, dass man hier Vorstellungen von "gleicher Qualität bei gleichen Parametern" entwickeln sollte; immerhin sind noch längst nicht alle Basisfunktionen des HEVC-Standards implementiert.

Definitiv nicht! Halte es selber auch eher für einen Fehler die Presets&Tune Optionen jetzt schon ein zu führen, da sowohl die Defaultwerte als auch die Bedeutungen hinter den Presets&Co sich wohl in den nächsten Versionen noch ändern werden.

Angenehm, ist aber das man mit den aktuellen MPC-HC nightly builds das HEVC Material ohne Probleme decodieren kann.

Vor kurzem wurde noch in einem Beitrag zum Thema Ziel-Bitrate für x265 darauf hingewiesen, dass für eine Begrenzung der Bitrateschwankungen eine VBV-Regelung nötig wäre ... Und schon wird entsprechendes in der Developer Mailinglist erwähnt.

Wobei das meiner Ansicht nach kommen sollte wenn VBV hinzugefügt wird,...

Ja, meine ich doch?! ... Wo war jetzt das Missverständnis?

Irgendwie hab ich das VBV überlesen

Hinweis:

Die "Adaptive Quantisierung" hat x265 bereits (--aq-mode 1). Allerdings benötigt die z.Z. wohl noch volle RDO-Analyse (--rd 2); alle Presets schneller als "slower" verwenden jedoch nur eine eingeschränkte RDO-Analyse (--rd {<2}). Das kann zu Kompressionsartefakten führen.

Die Presets sind auch ausführlicher (und etwas aktueller) im aktuellen x265 Evaluator's Guide dokumentiert.

"Die Presets sind auch ausführlicher (und etwas aktueller) " was hat sich denn geändert?

Ich hab nicht alle im Detail verglichen, aber mir ist sofort aufgefallen, dass bei deiner ersten Übersicht nirgends ein "--rd #" enthalten war.

Zitat

bei deiner ersten Übersicht nirgends ein "--rd #" enthalten war.

Sicher,... mal ans Ende der Zeile geguckt?

Unterschiede die mir aufgefallen sind:
1. --lft ist schon ab 'superfast' dabei, war vorher erst aber fast dabei
2. --tskip ist erst ab veryslow aktiv

nur so nebenbei: Die presets haben sich komplett geändert.

Ist auch nicht weiter verwunderlich, wenn noch längst nicht alle Basisfunktionen von HEVC so weit fertig sind, dass sie auch unter allen Voraussetzungen miteinander zusammenarbeiten. Was allerdings bisher schon miteinander funktioniert (hier noch encodiert mit x265 v0.5+259), sieht schon erfreulich gut aus:

--crf 24 -w -i 240 --bframe-bias 20 --rdpenalty 1 --rd 2 --aq-mode 1

Ich habe anhand dieses Beispiels auch festgestellt, dass der LAV-Decoder im Nightly MPC-HC 1.70.0.208 schnell genug sein kann für die Decodierung eines 1080p-HEVC-Videos auf einem Phenom-II X4 945 (3 GHz). Der LAV-Decoder in Version 1.70.0.154 war es noch nicht. Und der GPAC-Decoder im Nightly Osmo4 (GPAC 0.5.1-DEV rev4904) erst recht nicht.

Den Strongene PC HEVC/H.265 Decoder (aktuell: V2.0.1.17 / 2013-11-06) habe ich nicht installiert; sollte ich?

Geht --wpp eigentlich mittlerweile wieder?

Wieso? "Wavefront Parallel Processing" sollte "default: enabled" sein.

Quad-Tree analysis:
   --[no-]wpp                    Enable Wavefront Parallel Processing. Default enabled

Meine es gab letztens Probleme damit,.. ah,.. verwechselt mit "--weightp"

Die Probleme zwischen "weighted prediction in P slices" und "concurrently encoded frames" dürften nun ziemlich gelöst sein. Beide sind standardmäßig aktiv bzw. automatisch nach Anzahl der CPU-Kerne voreingestellt.

Mittlerweile beschäftigt man sich schon mit der B-Frame-Pyramide.

Ah, hatte verpasst, dass die weighted prediction wieder auf in den defaults aktiviert hatte.

Sicher, dass da die Anzahl der CPU-Kerne als genommen wird, wenn --frame-threads 0 verwendet wird? (im Evaluation Guide steht, dass wenn der Parameter nicht gesetzt ist eine automatische Anpassung stattfindet, wenn man in die Defaults im Source code guckt, steht da aber nur param->frameNumThreads = 0;

Auf meinem Phenom-II X6 zeigt der Process Explorer für diesen Prozess 10 Threads an, davon sind 6 Threads deutlich stärker beschäftigt als die anderen: Ja, ich glaube, dass jeder Kern sein Frame berechnet.

Quelltexte habe ich nicht zur Hand; vielleicht findest du ja noch eine Stelle, wo (?)->frameNumThreads später noch mal ausgewertet und in eine echte Anzahl umgerechnet wird — was du da gefunden hast, ist anscheinend erst mal nur der CLI-Parser, der sinnvolle Inhalte in internen Variablen absichert.

Suche ich vielleicht die Tage mal nach, momentan keine Zeit&Nerven.
Bei x265 nervt mich aktuell am meisten, dass man anscheinend nur unter Mavericks eine lauffähige Version erstellen kann, doof nur für alle die nicht Mavericks laufen haben.

Wie interpretierst du das:

Zitat

-F/--frame-threads Number of concurrently encoded frames
Range of values: >=0. Default = auto-determined from a formula based on the number of CPU cores

+

void x265_param_default(x265_param *param)
{
    memset(param, 0, sizeof(x265_param));


    /* Applying non-zero default values to all elements in the param structure */
    param->logLevel = X265_LOG_INFO;
    param->bEnableWavefront = 1;
    param->frameNumThreads = 0;
    param->poolNumThreads = 0;

-> vermute deshalb, dass 0 = auto ist.

wenn ich jedoch:

Zitat

--sao-lcu-opt 0: SAO picture-based optimization (requires -F1); 1: SAO LCU-based optimization (Default)

lese würde das ja heißen, dass im Auto-Mode '--sao-lcu-opt 1' nicht erlaubt wäre, was falsch erscheint.

-----

Nebenbei: Presets&Defaults haben sich mal wieder geändert, eine neuer Evaluation Guide ist draußen, der aber eine schöne Preset-Übersicht hat.

Der Code, den du da zitiert hast, ist die Vorbelegung mit sinnvollen Standardwerten.

Jetzt fehlt nur noch der Code, der da später zum Beginn der Encodierung noch Werte >0 einsetzt, wenn nach abgeschlossener Auswertung der Kommandozeilenoptionen da immer noch 0 drinsteht. Denn wenn die Anzahl der Pool- und Frame-Threads zu Beginn der Encodierung immer noch 0 wäre, würde nichts encodiert werden.