How to force bframe=# to hold?

[lexor]

Hi everybody, I'm trying to figure out the limits of PS3's abilities and I have trouble testing the number of bframes that PS3 supports.

At first I had the same trouble with ref=#, which I could set arbitrarily high and it would still play, but switching the sample to one that could actually use high ref count helped me find out the max.

Back to bframes, no sample I have needs a high number of bframes... either that or PS3 can supports 20 bframes (doubtful). So how can I force x264 to use the bframe # that I set (I'm not going for quality here, I'm just testing features).

Thanks.

[Dark Shikari]

--bframes X --no-b-adapt --scenecut=-1

Max bframes is 16.

[Mr VacBob]

I doubt its decoder has any limit on B-frames.

[lexor]

For anyone interested (especially those using the slow ps3/360 profile for MeGUI for squeezing every last bit):

Upto 1280x720 limits are:
--level 4.1 --ref 9 --bframe 16 --vbv-bufsize 9000 --vbv-maxrate 24000

maxrate might be higher now, but I didn't check since I wouldn't even use that much. I've seen discussion about level 5.1 support, but you still need to add --level 4.1, otherwise it won't play regardless of settings.

I think I found a bug in x264 though, block hell near some scene changes if I use --ref 9 --bframe (13-16) --no-b-adapt (--scenecut=-1 or default --scenecut=40, doesn't matter). PS3, FFDShow, and MPC-HC DXVA all show blocking. Source doesn't have a slightest hint of it. Blocking get's more severe as I raise bframe value. Changing ref value seems to only change the scene on which it occurs. Removing --no-b-adapt fixes the blocking.

Problem Sample (http://www.megaupload.com/?d=1KV44O1E)

[Dark Shikari]

I think I found a bug in x264 though, block hell near some scene changes if I use --ref 9 --bframe (13-16) --no-b-adapt (--scenecut=-1 or default --scenecut=40, doesn't matter). PS3, FFDShow, and MPC-HC DXVA all show blocking. Source doesn't have a slightest hint of it. Blocking get's more severe as I raise bframe value. Changing ref value seems to only change the scene on which it occurs. Removing --no-b-adapt fixes the blocking.Translation:

Hey, look, if I totally screw up frametype decision quality gets worse! This must be x264's fault ;)

[lexor]

Translation:

Hey, look, if I totally screw up frametype decision quality gets worse! This must be x264's fault ;)

No. And don't put words in my mouth again.

On a longer clip you'd see that shadows of last frame before scene change are superimposed upon frames after scene change, which themselves appear to be proper under the translucent blocky afterimage of old frames. That is not degradation of quality, that is screwed up frame order.

[Dark Shikari]

No. And don't put words in my mouth again.No, I was right, I just downloaded your video and the reason for the "visual artifacts" is simply because of the manner in which you've screwed up ratecontrol and frametype decision. The simple result is that x264 is forced to skip nearly every block at the very high given quantizer, resulting in artifacting.