Bits/(Pixel*Frame) / blocky picture ?

[stevywonder]

I've did a search about the Bits/(Pixel*Frame) on the board and came up with this:
http://forum.doom9.org/showthread.php?s=&threadid=16699&highlight=Bits%2FPixel%2AFrame

My understanding is to use bits/pixel-frame only when yer pre-compression test. It is used for estimating resolution and bitrate.

Once a compression test has completed, ignore bits/pixel-frame and use the load factor from the test.


do i realy have to ignore the Bits/(Pixel*Frame)?
i've done a 1 cd encode at 512 x XXX (sorry forgot the height)
the Bits/(Pixel*Frame) was way high and the compres test stated about 70%
now when i played the divx back in full screen it was way blocky around edges.

then i came across this text on:
http://www.everwicked.com/modules.php?op=modload&name=DivX_Guide&file=divx-05



Generally, the Bits/(Pixel*Frame) indicator shows how many pixels will be used to encode each frame. The more the better. Each time you lower the resolution the Bits/(Pixel*Frame) grows. However if you use too many bits for each frame, you sacrify resolution i.e. when you playback the movie and it gets resized you will have a blocky picture (looks like an ASF file). Therefore, there should be a balance between your encoding resolution and the Bits/(Pixel*Frame). By selecting 16 as the W-Modul you get a larger scale of resolutions and hence Bits/(Pixel*Frame).


so, should i realy ignore the Bits/(Pixel*Frame) and look for another option to blame for this blockyness?
(maybe resolution, resize filter,...)


thx in advance.

[dividee]

b/(p*f) guidelines implicitly assumes that every source compresses as well; the compression test gives you a better estimation since it has some knownledge about the source. So basically yes, you should disregard b/(p*f) once you have the compression test (but maybe not completely: for very difficult sources, you sometimes needs more than 70% in the compress test, and you can recognize difficult sources when you have a very high b/(p*f) and a low % in the compress test).

You didn't stated much about your encoding. You propably came across a difficult source. I wouldn't go lower than 512x... (except maybe for 4:3 movies), but you can try a different resizing method, or a denoising filter. And maybe a different codec?
Also, particularly if you used divx4 or 5, are you sure postprocessing was on when you played it back ?

[stevywonder]

ok, here are the spec:

movie.....:Snake eyes
aspect....16:9
res.......:720:576
Frame rate:25fps
frame tye.:interlaced (no lines showing in preview)
length....:94min 30sec

Frames....:141748


divx;) 3.11
1cd:(695MB)
average bitrate: 867 kBits/s
mp3: --alt-preset 128

now, ive' put w-modul on 32 and h-modul on 16
choose a res of 576x240
i get got a 0.257 Bits/(Pixel*Frame) and the compres test was 61.1% of 0,421

when i go lower to 544x 224 i get 0.291 Bits/(Pixel*Frame) and 69.3% of 0.421

and at 512x208 i get 0.333Bits/(Pixel*Frame) and 79.3%of 0.421.

*i used softbicubic resize.

[dividee]

These figures seems reasonnable.
Did you encode a problematic scene with these different resolutions? Did you see an improvement when lowering resolution?

Just a note (sorry I feel picky today): when you change resolution, you should redo a compressiblity check; you'll find that the max. b/(p*f) actually increases when you lower resolution; if you had 0.421 at 576x240, you'll find that you have maybe 0.438 at 512x208, thus you compress check % will not be 79% but 76%. If b/(p*f) doesn't increase that much (say, 0.430), it is a strong indication that a denoising filter will be helpful.