Quality/pixel and bits/pixel

[Sagittaire]

Many coders use the bits/pixel (like GK use bpf for example) to make their encodings. But this method has two problems:
- the source compressibility is not predictible
- bpf = f (resolution) with same source



|---------------|--------------------|--------------------|--------------------|
| | files sizes | bit/(pel*fps) | bit/(pel^0.75*fps) |
|---------------|--------------------|--------------------|--------------------|
| q2 1024*576 | 3389 Kbps | 0.239 bpf | 6.63 sci |
| q2 720*400 | 1890 Kbps | 0.273 bpf | 6.33 sci |
| q2 512*288 | 1143 Kbps | 0.323 bpf | 6.32 sci |
| q2 384*208 | 714 Kbps | 0.372 bpf | 6.26 sci |
|---------------|--------------------|--------------------|--------------------|
| q3 1024*576 | 2067 Kbps | 0.146 bpf | 4.04 sci |
| q3 720*400 | 1188 Kbps | 0.172 bpf | 3.98 sci |
| q3 512*288 | 735 Kbps | 0.207 bpf | 4.07 sci |
| q3 384*208 | 462 Kbps | 0.241 bpf | 4.05 sci |
|---------------|--------------------|--------------------|--------------------|
| q4 1024*576 | 1492 Kbps | 0.105 bpf | 2.92 sci |
| q4 720*400 | 875 Kbps | 0.127 bpf | 2.93 sci |
| q4 512*288 | 548 Kbps | 0.155 bpf | 3.03 sci |
| q4 384*208 | 344 Kbps | 0.179 bpf | 3.02 sci |
|---------------|--------------------|--------------------|--------------------|
source 1280*720
resize with lanczos
encoding with XviD



|----------------|--------------------|--------------------|--------------------|
| | files sizes | bit/(pel*fps) | bit/(pel^0.75*fps) |
|----------------|--------------------|--------------------|--------------------|
| q20 1280*720 | 4026 Kbps | 0.182 bpf | 5.63 sci |
| q20 720*400 | 1728 Kbps | 0.250 bpf | 5.79 sci |
| q20 512*288 | 1057 Kbps | 0.299 bpf | 5.85 sci |
| q20 384*208 | 661 Kbps | 0.345 bpf | 5.80 sci |
|----------------|--------------------|--------------------|--------------------|
| q25 1280*720 | 2074 Kbps | 0.094 bpf | 2.90 sci |
| q25 720*400 | 924 Kbps | 0.134 bpf | 3.09 sci |
| q25 512*288 | 573 Kbps | 0.162 bpf | 3.17 sci |
| q25 384*208 | 363 Kbps | 0.189 bpf | 3.18 sci |
|----------------|--------------------|--------------------|--------------------|
| q30 1280*720 | 1023 Kbps | 0.046 bpf | 1.43 sci |
| q30 720*400 | 460 Kbps | 0.067 bpf | 1.54 sci |
| q30 512*288 | 286 Kbps | 0.081 bpf | 1.58 sci |
| q30 384*208 | 181 Kbps | 0.094 bpf | 1.59 sci |
|----------------|--------------------|--------------------|--------------------|
source 1920*1088
resize with lanczos
encoding with x264


If you use bit/(pel^0.75*fps) to make your encoding then you don't have the second problem: with same source bit/(pel^0.75*fps) is constant whatever the resolution.

Example:

We want to make encoding with bitrate Bf and compressibility C. We make first pass with resolution Ri and we obtain bitrate Bi in quant 2. We will make encoding with resolution Rf to obtain the compressibility C and bitrate Bf

Rf = Ri*(Bf/(C*Bi))^(4/3)

first pass XviD 640*352 q2: 1550 Kpbs
I want 700 Kbps and 55% for compressibility
I want to find the resolution Rf for this encoding

Rf = 640*352*(700/(0.55*1550))^(4/3)
Rf = 173 218 pixels
Rf = 554*312
Rf ~ 576*320 is the best choice for 16/9 mod16 ...

[G-Slide]

what are you building for ?:confused:

[lexor]

Quote from South Park comes to mind:

that doesn't make any god damn sense

[akupenguin]

Responding to the post that was here before it was replaced by a construction sign:
Yes, bpp is bogus. But the correct exponent is not constant. I saw around bits/(pixel^0.5) to 0.6 on the few animes I benchmarked.

[Sagittaire]

update with x264 (constant quant for I,P & B)

[iradic]

hi

sorry if i dont get it ... but how did you came up with 0.75 value?

by the way its not always the same ... and i think calculations you want have been discussed before ... (i'm not familiar with it but it seems similar or at least the goal is)
http://www.geocities.com/analyzerdrf/quantsize_art.htm

[stephanV]

Originally posted by akupenguin
Responding to the post that was here before it was replaced by a construction sign:
Yes, bpp is bogus. But the correct exponent is not constant. I saw around bits/(pixel^0.5) to 0.6 on the few animes I benchmarked.

So if the exponent is not constant, the bit/(pel*fps^<fill in some exponent>), has no real meaning either. The problem has shifted from a varying bpp number to a varying exponent.

The problem probably still remains this:
- the source compressibility is not predictible

[Sagittaire]

bit/(pel^0.75*fps) is an empirical modeling

IMO 0.70 or 0.75 are good for all codec, all resolution (VCD to HDTV) and for all source. For particular source like anime it's possible that 0.5 or 0.6 will be better.

try to find the best value for your source ... ;)


Originally posted by iradic
sorry if i dont get it ... but how did you came up with 0.75 value?

by the way its not always the same ... and i think calculations you want have been discussed before ... (i'm not familiar with it but it seems similar or at least the goal is)
http://www.geocities.com/analyzerdrf/quantsize_art.htm


No ... :D

[708145]

Just a random late night thought:

Wouldn't basing the quality decision on some objective metric like SSIM help? Like:

Do various Q2 encodes to find a resolution such as:
SSIM( scale_to_orig_res(encode), original) is maximum.

bis besser,
Tobias

[yaz]

Many coders use the bits/pixel (like GK use bpf for example) to make their encodings.really ? the encoders i know uses bpp only for the very 1st guess. then they do sg u outlined, namely, findig a resolution providing 'encoding with bitrate Bf and compressibility C' while they don't care about bpp anymore.

i've checked my latest encodes and i found much lower coefficients (round 0.6) maybe because i prefer >66% compression. in add, the coefficient changes from encode to encode.
however, if i'd been using a coeff 0.6 for resizing i'd've got resolutions very close to that i used so ... maybe this theory deserves more attention.

the bests
y

[Emp3r0r]

Hey, I'm a long time encoder and I've found this formula useful. I like 2-pass encodings but I want to be flexible based on the source complexity. This formula helps me save time by estimating a good bitrate.

I am aware of compressibility tests but I have enough experience that I can skip that step and save time.

I've updated the bitrate calculator inside of MeGui with the formula support.

http://jvance.com/img/forum/BitrateCalc.png

The complexity slider alters the exponent from 0.72 - 0.78 and gives a pretty good quality estimate.

Also, there is a quality codec modifier that can also alter the exponent based on codec efficiency.

Here are the values I'm using:
MPEG2 1.022
ASP 1.018
AVC 1.0
VC1 1.004

I only do AVC encodes so I've guessed the other values based on previous experience. Please suggest better values if you have them (snow?).

[J_Darnley]

Oh god... I remember this thread.

Anyway, why would you do that? If you don't have a target file size, use crf.

[nurbs]

I am aware of compressibility tests but I have enough experience that I can skip that step and save time.
I'm sure you belive that, but I'm equally sure that you aren't able to tell reliably. I've done hundreds of CRF encodes with very variable results in filesize.

Anyway bits per pixel isn't a measure of quality. Playing around with exponents doesn't change that.

This formula is probably useful if you have a source, know what bpp yields good quality (i.e. by doing a compressibility test) and then want to downscale a little keeping the same "quality" in the resulting encode.

I agree with J_Darnley's recommendation.

Some interesting reading about bpp, scaling, etc:
By Teegedeck (http://forum.doom9.org/showthread.php?p=841511#post841511)
By Dark Shikari (http://forum.doom9.org/showthread.php?p=1311212#post1311212)

[Emp3r0r]

Thanks for the feedback. I am well aware of all of the arguments against using BPP as a measure of quality.

These arguments are the reason we have complexity slider (alters coefficient) and codec modifier.


private void CalcBitsPerPixel()
{
BitsPerPixel = (float)VideoSize.Bytes * 8F / (float)Frames / (float)(FrameSize.Width * FrameSize.Height);
}

private void CalcQualityEstimate()
{
QualityEstimate = (float)VideoBitrate / ((float)Math.Pow((float)(FrameSize.Width * FrameSize.Height), QualityCoeffient * QualityCodecModifier) * (float)FramesPerSecond) * 1000F;
}

So, the metric is still useful as a guideline for when we want to find a subjective balance in filesize and resolution. It is just an estimate. Estimates can and will be inaccurate. That doesn't make it any less useful. Many times, people like to take an estimate and double it, then double it again to be safe. :rolleyes: