Der x265-Encoder entwickelt sich...

Gibt es Gründe für "Constant Quantizer" statt "Constant Rate Factor"?

Profile ... muss man nicht vorgeben, ergibt sich aus den Grenzwerten. Außer man weiß, dass ein Abspielgerät was nicht unterstützt, und deshalb Vorgaben machen muss. Allgemein wird bei YUV 4:2:0 (YV12 oder analoges für DeepColor) sicher "Main Profile" für 8 bit und "Main10 Profile" für 10 bit Tiefe gewählt; "Main Still" wäre für "alles I-Frames", und 4:2:2-Varianten werden wahrscheinlich von vielen Geräten nicht unterstützt.

Ne für "Constant Quantizer" statt "Constant Rate Factor" gibt es kein Grund... ist nur default von Hybrid... habe ich nun geändert "crf 19", in der Hoffnung das es dem 19 von x264 etwa entspricht...

Da ich schon mit x264 10-Bit sehr gute Erfahrung gemacht habe würde ich dies gerne auch weiter nutzen, also "Main 10"... weil die Grenzwerte für Player wird doch über "Levels" gemacht oder? also 5,1 usw. da habe ich "unbegrenzt"

AVC Profile@Level stimmen mit HEVC Profile,Tier@Level nicht grundsätzlich überein (bei HEVC kommt noch eine "Tier"-Dimension hinzu). Blu-ray-Player werden AVC Main/High Profile @ Level 4.1 unterstützen; über zu erwartende Werte beim Nachfolger oder bei UHD-DVB mit HEVC ist mir noch nichts bekannt.

x264-CRF und x265-CRF haben auch wenig Gemeinsamkeiten, die Größenordnung ist jedenfalls qualitativ nicht direkt vergleichbar. Schau dir nur die Standardwerte an: CRF 23 bei x264, CRF 28 bei x265.

Hmpf, warum einfach wenn es auch kompliziert geht... lustig ist das z.B. Handbrake praktisch keine Optionen bei x265 hat.. einzig "slow" usw. gibt es...

Könnte an dem unlustigen Grund liegen, dass sich Parameter-Sets und APIs (falls die Bibliothek direkt eingebunden wird) doch immer noch mal ändern. Wozu also eine GUI basteln, die jetzt schon so viele Parameter unterstützt wie möglich, wenn man die dann aller paar hundert Patches wieder ändern müsste? Nun ja, ffmpeg und StaxRip stellen sich dieser Herausforderung...

GUIs programmieren ist wenn man es ohne ausgeklügeltes System macht zeitaufwendig, lästig und langweilig, bei x264 und x265 kommt mit den Presets und Tunings noch Zusatzarbeit hinzu, wählt man ein Preset sollen schließlich alle entsprechenden Werte in der GUI geändert werden. Ich mach es so dass Dialoge mit vielen Einstellungen dynamisch generiert werden, also ohne Formdesigner, muss ich dann eine Einstellung oder ein Schalter hinzufügen oder ändern muss ich im Code ohne viel Zeit und Mühe nur eine oder maximal zwei Stellen bearbeiten.

Nachdem ich mir heute ein Mobilen USB-Stick mit ffmpeg und x265 sowie Testfiles gebastelt habe um mal Diverse Rechner durchprobieren zu können ist mir was bezüglich "--pools" aufgefallen... Kann es sein das das überhaupt nicht nötig ist? Hab hier eine codezeile die zufällig ohne --pools war habe festgestellt das im Status Trotzdem die Richtige Tread Zahl erscheint...

Werde die Tage mal im AppleStore vorbei gehen und mal schauen was die neuen dinger so können...

So wie für x265 bis v1.4 die Angabe von "--threads" nie wirklich nötig war (x265 erkennt die Anzahl der Rechenkerne und entscheidet selbst, wie diese halbwegs effizient genutzt werden), so ist für die neueren v1.5 auch die Angabe von "--pools" nicht zwingend nötig; allerdings kann sie helfen, x265 mitzuteilen, dass da – in deinem Fall – nicht eine CPU mit 24 Kernen ist, sondern zwei physisch getrennte CPUs mit jeweils 12 Kernen, so dass x265 dann weiß, dass der Austausch von Daten zwischen den zwei CPUs wohl langsamer sein kann als zwischen den Kernen je einer CPU.

Nun erzeugt x265 aber ohnehin offenbar gar nicht so viele Threads, wie du bei deiner Hardware Kerne zur Verfügung hast. Deutlich wichtiger wird die Pool-Verwaltung also wohl bei Systemen mit mehr physisch getrennten CPUs mit jeweils weniger Kernen pro CPU, und erst recht, wenn die Kerne auch noch bezüglich des Datenaustauschs "weiter entfernt sind" als mehrere Sockel auf dem gleichen Mainboard.

tach auch !

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

UHD-Fernseher wohl.

Aktuelle und kommende Änderungen: RD-Level werden auf den Bereich 0..4 zusammengefasst (3=4 und 5=6 waren zuvor ohnehin gleich); die Presets ultrafast und superfast werden angepasst.

die Presets sind angepasst, RD-levels sind aber noch wie bisher 0-6

Ja, da war ich vielleicht zu früh; anscheinend war das nur ein Vorschlag. Darauf folgte ein Gegenvorschlag, dass man die bisher gleichen Paare auch durch zusätzliche Änderungen trennen könnte... Na, in den nächsten Tagen oder Wochen wird das sicher klargestellt.

Hier mal ein Test auf dem aktuellen Apple Mac Pro 6-Core

Left-Wall-3-3-Mac-Pro:~ apple$ /Volumes/x265-TestSystem/ffmpeg -y -loglevel fatal -threads 8 -r 24000/1001 -analyzeduration 100M -probesize 100M -i "/Volumes/x265-TestSystem/x265Test.m2ts" -map 0:0 -an -sn -vf crop=1916:816:2:132 -vsync 0 -r 24000/1001 -pix_fmt yuv420p -f rawvideo - | /Volumes/x265-TestSystem/x265-1.5+ --input - --input-res 1916x816 --fps 23.976 --subme 0 --merange 60 --rect --amp --min-keyint 1 --qp 19 --psnr --colormatrix bt709 --output "/Volumes/x265-TestSystem/x265Test.265"
yuv  [info]: 1916x816 fps 23976/1000 i420p8 unknown frame count
x265 [info]: HEVC encoder version 1.5+175-45deb0125890
x265 [info]: build info [Mac OS X][clang 6.0.0][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: --psnr used with psy on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 12 threads
x265 [info]: frame threads / pool features       : 3 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : hex / 60 / 0 / 2
x265 [info]: Keyframe min / max / scenecut       : 1 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CQP-19 / 0.0 / 0
x265 [info]: tools: rect amp rd=3 rdoq=0 psy-rd=0.30 deblock sao signhide tmvp 
x265 [info]: frame I:     16, Avg QP:16.00  kb/s: 41734.78  PSNR Mean: Y:47.120 U:47.511 V:47.943
x265 [info]: frame P:    334, Avg QP:19.00  kb/s: 12338.62  PSNR Mean: Y:44.569 U:46.205 V:47.235
x265 [info]: frame B:   1073, Avg QP:20.71  kb/s: 4661.77   PSNR Mean: Y:43.763 U:45.689 V:46.848
x265 [info]: global :   1423, Avg QP:20.26  kb/s: 6880.49   PSNR Mean: Y:43.990 U:45.830 V:46.951
x265 [info]: Weighted P-Frames: Y:1.5% UV:1.2%
x265 [info]: consecutive B-frames: 8.3% 4.0% 10.3% 27.7% 49.7% 


encoded 1423 frames in 245.69s (5.79 fps), 6880.49 kb/s, Global PSNR: 44.590
Left-Wall-3-3-Mac-Pro:~ apple$

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.

Da ich eh noch nicht weiß welchen CRF ich wohl nutzen sollte ist das nicht so wichtig aber gut zu wissen... die ganzen anderen settings stehen auch noch in den Sternen...

Wie schon erwähnt, gibt es da noch einen deutlichen Sprung. Standardwerte sind: CRF 23 für x264, CRF 28 für x265; das sind aber noch keine "visuell transparenten" Qualitäten, höchstens "erträgliche". Relativ gut wird es bei x264 etwa mit CRF 20, und bei CRF 24 sollte x265 etwa ebenso gut aussehen. Schätze ich. Zumindest hat x265 den Vorteil, dass man hier den SSIM-Wert in dB verfolgen kann, das ist schon ein recht guter Anhaltspunkt. Bei x264 sieht man den wohl erst am Ende, glaube ich... Im Moment kann ich grad nicht testen.

Habe mal ein paar Test Encodes gemacht um zu sehen wie so die Dateigrößen sind... Habe dazu Handbrake genutzt CQ 19, wobei das ganze hier "Constand Quality" heißt aber CRF nutzt, bei x264 jedenfalls... jedenfalls ist die Scala gleich...

CRF 19 x264: 9,67 GB
CQ 19 x265: 7,65 GB
CQ 20 x265: 7,28 GB
CQ 24 x265: 6,40 GB

Ist schon richtig: Für etwa konstante Qualität (oder genauer, einen konstant geringen Qualitätsverlust) wird mit einem "Constant Rate Factor" gearbeitet anstatt mit einer "Constant Quantization". Da kann also die Quantisierung schon mal schwanken; aber wenn man bei x265 den Log-Level 3 bzw. info und die SSIM-Ausgabe aktiviert, kann man an der Konsole schön beobachten, dass der Unterschied zum Original, gemessen via SSIM, nicht besonders stark schwankt (der Rate-Faktor selber wird dabei nicht ausgegeben, glaube ich; wäre aber auch nicht gerade intuitiv).

Heute mal vorsichtiger formulieren... :redface:

Es wurde ein Patch vorgeschlagen, der eine feinere Steuerung der Quantisierung je nach CTU-Größe erlaubt:

Currently adaptive quantization adjusts the QP values on 64x64 pixel coding tree
units (CTUs) across a video frame. the new param option --max-dqp-depth will
enable quantization parameter (QP) to be adjusted to individual quantization
groups (QGs)
 
Example:
--max-dqp-depth=0 for 64x64 blocks
--max-dqp-depth=1 for 32x32 blocks
--max-dqp-depth=2 for 16x16 blocks
 
currently this feature not supported for block 8x8

Ob das wohl helfen kann, Banding mit Blockartefakten zu vermeiden?