Log in

View Full Version : Fewer pixels => higher bitrate?


aurorix
9th July 2009, 08:41
I've encountered some odd behaviour with some video I'm encoding today. The source is Battlestar Galactica season 2, PAL dvd, 720x576 @ 25fps. It's got about a pixel's worth of crud around the edges that I want to get rid of.

Specifically, I've found that overcropping to the nearest mod16 resolution for both width and height, 704:560:8:8, results in a significantly larger output file than if I crop to the nearest mod4 res, 716:572:2:2.

Now, why is this the case? My understanding is that cropping to mod16 offers more efficient compression over mod4 because the encoder doesn't have to pad bits up to the next mod16. Further, I'd have thought that for the same input and options the source with fewer pixels to encode would result in a smaller output file. Does anyone know why the opposite is true here?

x264 options
cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=9 psy_rd=1.0:0.2 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-3 threads=5 nr=0 decimate=1 mbaff=0 bframes=3 b_pyramid=1 b_adapt=2 b_bias=0 direct=3 wpredb=1 keyint=250 keyint_min=25 scenecut=40 rc=crf crf=23.0 qcomp=0.67 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_ratio=1.30 aq=1:1.00

Result of crop at 716:572:2:2
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
x264 [warning]: width or height not divisible by 16 (716x572), compression will suffer.
x264 [info]: using SAR=509/358
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.0
...
Video stream: 1371.769 kbit/s (171471 B/s) size: 580793197 bytes 3387.120 secs 84679 frames
x264 [info]: slice I:912 Avg QP:19.19 size: 32730
x264 [info]: slice P:30627 Avg QP:21.80 size: 11181
x264 [info]: slice B:53139 Avg QP:23.46 size: 3923
x264 [info]: consecutive B-frames: 3.1% 23.4% 40.2% 33.2%
x264 [info]: mb I I16..4: 13.2% 73.8% 13.0%
x264 [info]: mb P I16..4: 1.2% 6.6% 0.8% P16..4: 53.3% 14.4% 11.1% 0.0% 0.0% skip:12.5%
x264 [info]: mb B I16..4: 0.1% 0.4% 0.0% B16..8: 55.0% 0.6% 1.0% direct: 2.5% skip:40.3% L0:40.3% L1:56.0% BI: 3.7%
x264 [info]: 8x8 transform intra:75.6% inter:79.0%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: coded y,uvDC,uvAC intra:81.0% 79.1% 39.6% inter:26.4% 35.5% 3.3%
x264 [info]: ref P L0 63.5% 20.1% 9.9% 6.5%
x264 [info]: ref B L0 78.5% 17.4% 4.1%
x264 [info]: ref B L1 93.6% 6.4%
x264 [info]: kb/s:1371.7

Result of crop at 704:560:8:8
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
x264 [info]: using SAR=91/64
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.0
...
Video stream: 1528.332 kbit/s (191041 B/s) size: 647080487 bytes 3387.120 secs 84679 frames
x264 [info]: slice I:918 Avg QP:19.06 size: 30602
x264 [info]: slice P:33130 Avg QP:21.76 size: 12170
x264 [info]: slice B:50630 Avg QP:23.37 size: 4262
x264 [info]: consecutive B-frames: 3.5% 36.3% 34.2% 26.0%
x264 [info]: mb I I16..4: 8.8% 86.6% 4.6%
x264 [info]: mb P I16..4: 1.2% 10.4% 0.4% P16..4: 46.1% 17.0% 13.0% 0.0% 0.0% skip:11.9%
x264 [info]: mb B I16..4: 0.1% 1.1% 0.0% B16..8: 46.9% 0.9% 1.8% direct: 3.9% skip:45.2% L0:40.2% L1:54.1% BI: 5.6%
x264 [info]: 8x8 transform intra:86.6% inter:82.2%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: coded y,uvDC,uvAC intra:82.9% 81.7% 46.3% inter:28.9% 35.0% 4.1%
x264 [info]: ref P L0 65.1% 18.7% 9.6% 6.5%
x264 [info]: ref B L0 77.4% 17.4% 5.1%
x264 [info]: ref B L1 94.8% 5.2%
x264 [info]: kb/s:1528.2

Manao
9th July 2009, 08:49
x264 [info]: slice I:912 Avg QP:19.19 size: 32730
x264 [info]: slice P:30627 Avg QP:21.80 size: 11181
x264 [info]: slice B:53139 Avg QP:23.46 size: 3923
...
x264 [info]: slice I:918 Avg QP:19.06 size: 30602
x264 [info]: slice P:33130 Avg QP:21.76 size: 12170
x264 [info]: slice B:50630 Avg QP:23.37 size: 4262It looks like the cropping influenced x264's bframe decision.You're getting 10% more P frames, which are inherently bigger than the B frames they replace, thus the bitrate increase. As for why x264's bframe decision care about the cropping, I don't know. I guess the edges you talked about were messing with it a bit.

Dark Shikari
9th July 2009, 09:02
It looks like the cropping influenced x264's bframe decision.You're getting 10% more P frames, which are inherently bigger than the B frames they replace, thus the bitrate increase. As for why x264's bframe decision care about the cropping, I don't know. I guess the edges you talked about were messing with it a bit.When VBV is off, B-frame decision ignores the macroblocks on the edge of the frame. If there's something very significant on that last row of macroblocks (which gets kept if you don't overcrop, but not kept if you do overcrop), it might affect the decision.

Also, at some point I should probably go and make CRF ratecontrol take P vs B into account bitrate-wise.

aurorix
9th July 2009, 10:32
When VBV is off, B-frame decision ignores the macroblocks on the edge of the frame. If there's something very significant on that last row of macroblocks (which gets kept if you don't overcrop, but not kept if you do overcrop), it might affect the decision.
Out of interest, what kind of video information in the final row would tend to bias the encoder towards using a p-frame or a b-frame? 10% more p-frames sounds like a lot considering the last row makes up under 3% of the total video area... there'd have to be something major going on in the last row for that 3% to influence the entire frame decision so strongly.

It will be interesting to experiment with this on different sources.

Dark Shikari
9th July 2009, 10:44
Out of interest, what kind of video information in the final row would tend to bias the encoder towards using a p-frame or a b-frame? 10% more p-frames sounds like a lot considering the last row makes up under 3% of the total video area... there'd have to be something major going on in the last row for that 3% to influence the entire frame decision so strongly.Frametype decision is often
choosing between two modes with very similar scores, so it doesn't matter much which way it picks for that particular decision. It could be that something small is able to (often) push it over that line.

Manao
9th July 2009, 11:38
To push an analogy with tennis, winning 51% of the points gives you a 60% chance of winning the match (see here (http://www.geocities.com/hofertennis@sbcglobal.net/tiparchive42.html)), and 55% of the points raise that to 90% chances of winning the match.