Farbanteil

akapuma

Hallo,

wenn ich einen Farbfilm in x264 encodiere, wie groß ist in etwa der Anteil, der für die Helligkeitsinformation verwendet wird, und wie groß ist der Anteil, der für die Farbinformation verwendet wird (mit dem Standard --chroma-qp-offset 0)?

Gruß

akapuma

Selur

da die Farbinformationen i.d.R. einiges weniger an 'Informationsumfang' hergeben sollten als die Helligkeitsinformationen und die Farb/Chroma auch nur mit der Hälfte der Auflösung gesampled werden würde ich sagen das die Helligkeits/Luma - Informationen einen Großteil ausmachen sollten und die Chroma-Informationen eher gering sein sollten.
Kannst ja mal einen (bunt) Film/Clip mit konstantem Quantizer erstmal normal Encoden und dann in das Avisynthscript Greyscale rein werfen und gucken in wieweit von der Größe und der Encodingzeit ein Unterschied besteht.

Hab da nie wirklich drüber nachgedacht muss ich gestehen.

Cu Selur

Ps.: eventuell wäre ein Vergleich bei lossless auch noch interessant.

Kopernikus

Ich hab eine Hausnummer von 5-10% im Kopf, aber auf jeden Fall ist es sehr wenig

Selur

Ja, irgend sowas habe ich auch aus Diskussionen im englischen Board im Kopf,... aber sicher weiß ich das nicht mehr.

Cu Selur

Ps.: mache gerade mal nen lossless Vergleich
1. normal bunt: 12,8 fps (1.96GB)
2. mit Greyscale() am Ende des Scripts: 14,43fps <- etwa 13% schneller (1,39GB <- 30% weniger)

akapuma

Hallo,

im XviD-Wissenswertes steht, daß die Verwendung des XviD-Parameters "Greyscale", d.h. das Weglassen aller Farbinformationen, ca. 5-7% einsparen würde.

Im x264-"man" steht unter "--chroma-qp-offset", "Je nach Film kann hierdurch zwar bis zu 10% der Bitrate einsparen,". Hierbei würde "--chroma-qp-offset" allerdings nur zu einer stärkeren Kompression, und nicht zu einem Wegfall der Farbe führen. Und dann wären 10% ja ne Menge.

Bin mal gestpannt, was bei Deinem (Selurs) Test rauskommt. Ist es nur ein kleiner Prozentsatz, dann werd ich über "--chroma-qp-offset" nicht Nachdenken.

Gruß

akapuma

Selur

Die Frage ist noch inwieweit man lossless mit wirklichem Komprimieren vergleichen kann.
-> ich mach mal nen Encode mit konstantem quantizer 30 zum vergleich.

Code

--qp 30 --no-fast-pskip --bframes 5 --b-pyramid --bime --weightb --direct auto --analyse p8x8,b8x8,i4x4,p4x4 --b-bias 30 --threads auto --thread-input --progress --no-psnr --no-ssim

grau: 17,68fps (59,5MB)
bunt: 17,4fps (69,2MB)
Da sind wir dann auch wieder in dem Bereich der mir so vorschwebte.

Cu Selur

akapuma

Hallo,

hab mal nen Test gemacht, in wie weit sich die Erhöhung des Quantizers für die Farbe um 3 bemerkbar macht:

Code

%CLI% --crf 25 -I 300 -i 120 -r 6 --mixed-refs --chroma-qp-offset 3 --no-fast-pskip -b 4 --b-pyramid --me umh --merange 32 --b-rdo --bime -w -f 1,1 -m %subme% -A all -8 --qpstep 8 --aq-strength 0.5 --direct auto --b-bias 30 %agkpzones% %threads% --progress --no-psnr --no-ssim -o %4 %5

CRF25: 3946kB
CRF25 + --chroma-qp-offset 3: 3844kB

Spart immerhin 2,6%.

Gruß

akapuma

LigH

Also wenn man von der Theorie ausgehen würde (unkomprimiert: YUV mit Chroma Subsampling 4:2:0), dann wäre das ein Platzbedarf von 4x Y + 1x U (= Cb) + 1x V (= Cr). Man braucht also 4/6 = 2/3 Helligkeit und 2 x 1/6 = 1/3 Farbdifferenzen.

Wenn jetzt noch die Farbdifferenz-Informationen weniger Details aufweisen und sich dadurch leichter quantisieren und komprimieren lassen, dann verschiebt sich das Verhältnis noch ein wenig.

Selur

Beim lossless Encoden scheint dies ja auch in etwas zu zutreffen, beim normalen Encoden ist es dann schon einiges weniger an Platzdifferenz und auf die Encodingzeit bezogen macht es fast nix aus.

Cu Selur

LigH

Zitat von Selur

und auf die Encodingzeit bezogen macht es fast nix aus.

Was unter anderem daran liegt, dass Farbigkeitsinformationen erstens einen geringeren Umfang haben, und zweitens (auch deshalb) per Standard oft nicht bzw. ungenauer für die Bewegungssuche verwendet wird.

Jetzt mitmachen!