Leo's x264 profile for PS3 (SD animation)

[LeoRexTyrannus]

Optiaml X264 Settings

I took MeGUI's, Handbrake's, RipBot264's PS3 profiles, averaged them against each other and then streamlined the settings they agreed on and went with the better settings they didn't agree on.

Then I played around and found out these guides and profiles are using inferior settings to what the PS3 can actually now handle as of this writing.

These are the settings I got to play (provided by MediaInfo if you find it useful, consider donating)

cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=crf / crf=18.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=25000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

The old optimal settings that I had compiled from MeGUI, Handbrake, and RipBot264

cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=7 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=crf / crf=18.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=2500 / vbv_bufsize=25000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

So thats

ref=3, subme=7, bframes=3, b_pyramid=0
vs
ref=16. subme=9, bframes=16, b_pyramid=1

If you see me on Playstation Network you owe me a thank you =P

Verify it and slap a sticky on this, far too many people are all over the internet asking about optimal settings, well now you have them, search over. Start encoding.

[tetsuo55]

that file will however only be compatible with the ps3, and will not work on many other standalone players. Please keep that in mind

[Comatose]

There is no such thing as optimal settings, because everyone has a slightly different goal, or a different threshold of acceptable/high quality. The rules say you can't make posts asking/stating what is best on doom9.

By the way, just because VBV settings higher than those recommended for the PS3 worked doesn't mean it can deal with that much. It's more likely that your encode simply didn't go >24Mbps anywhere. You also don't mention your resolution (with regard to ref=16).

[wyti]

but there is one big mistake about your settings. The PS3 don't support profile beyond 4.1, so you can't use 16 ref frames with HD contents !

And why is that optimal settings ? I may need more speed, or i may have a whole week to spent using --me tesa and merange 32.

the point is that optimal settings aren't existing ! it depends on what you need.

[Audionut]

Your way off the mark.

Refs=16 = silly.

me-range could be tweaked a little higher if your using other slow settings.

threads=3 <--- what happens if I have a octa core.

b-frames=16 with b-adapt=2 = crazy slow and plain stupid.

vbv_maxrate=25000 / vbv_bufsize=25000 <--- PS3 will take way more than that.

keyint=250 / keyint_min=25 <--- good for pal. Wrong for other frame rates.

crf=18.0 <-- overkill for a lot of people and some sources.

[tetsuo55]

I think LeoRexTyrannus is trying to improve the existing templates.

Improve in a quality+compression over speed.

[Dark Shikari]

me=umh"Maximum quality"? Hurr.

[roozhou]

If you need "maximum quality", use lossless.

[Comatose]

Or better yet, don't do anything at all. The original is lossless, too. :P

[Ninpo]

Why would you strangle your encode with things like 16 bframes and b-adapt 2, 16 refs then only use me umh and merange 16?!

[LeoRexTyrannus]

A few of you're just rude and need a lesson in manners and tact.

I am completely open to criticism of my settings, otherwise how else would I learn to improve them?

That said I will address the comments made individually.

Tetsuo said and I quote "that file will however only be compatible with the ps3, and will not work on many other standalone players. Please keep that in mind"

That could be completely true, I don't know, I have no interest in maintaining compatability across multiple hardware devices, just specifically the PS3 is my concern.

Comatose said and I quote "here is no such thing as optimal settings, because everyone has a slightly different goal, or a different threshold of acceptable/high quality. The rules say you can't make posts asking/stating what is best on doom9. By the way, just because VBV settings higher than those recommended for the PS3 worked doesn't mean it can deal with that much. It's more likely that your encode simply didn't go >24Mbps anywhere. You also don't mention your resolution (with regard to ref=16)."

I agree that optimal is subjective, I'm trying to improve the profiles that exist to what the PS3 can actually handle as of this writing. I didn't mean to violate a forum rule and I did so unintentionally, my apologies won't happen again. VBV settings higher than those recommended were never used, I simply left this to what all of the source profiles agreed was acceptable, RipBot264 says 24000, MeGUI and Handbrake say 25000, so I went with that. I didn't mention my resolution I was in such a hurry to get this out there and it was a late night posting, my apologies. My source was 720x480 NTSC DVD, specifically Squidbillies Volume 2, the test sample was a bonus on the disc called "Dragonbillies" they produced for Dragoncon. The source was interlaced, top field first. I hope that clears that up.

Comatose said and I quote "but there is one big mistake about your settings. The PS3 don't support profile beyond 4.1, so you can't use 16 ref frames with HD contents ! And why is that optimal settings ? I may need more speed, or i may have a whole week to spent using --me tesa and merange 32. the point is that optimal settings aren't existing ! it depends on what you need."

The PS3 supports audio at Level 4.2, however video does not function. I don't know if you can use R=16 w/ HD sources (i.e. Blu-ray, etc) but I am aware of people encoding HD content to level 4.1 and producing AVCHD discs. So obviously you can encode HD content to level 4.1, of course quality and bit rate would suffer but it's quite doable.

Audionut said and I quote "Your way off the mark. Refs=16 = silly. me-range could be tweaked a little higher if your using other slow settings. threads=3 <--- what happens if I have a octa core. b-frames=16 with b-adapt=2 = crazy slow and plain stupid. vbv_maxrate=25000 / vbv_bufsize=25000 <--- PS3 will take way more than that. keyint=250 / keyint_min=25 <--- good for pal. Wrong for other frame rates. crf=18.0 <-- overkill for a lot of people and some sources.

Firstly thank you for insulting me for no reason at all, very childish of you. Ref=16 is silly how... because it improves quality and lowers file sizes? me-range could be tweaked, PS3 in my tests with my above mentioned sample was able to handle a file with an me_range=64 the only downside was that it took immensely longer to encode it. B-Frames 16 and Adapt 2 improved quality and didn't increase my encoding time noticably, I think you're just plain wrong about this one Audio. as for the VBV well if the PS3 will take way more than that, someone perhaps you define its limits since no one has and that's the point of this. Keyint=250, Keyint_min=25 were the settings the profiles of MeGUI and RipBot264 agreed upon. Handbrake uses Keyint=300, Keyint_min=30 nothing more nothing less, give me your opinion of what these would ideally be for NTSC SD content and I'll revise. Threads=3 was included because I c & p'd from RipBot. CRF 18 looks nice to me, has a good level of compression to the files, I'm happy with it and that's why I use it, plus nearly all opinions I've heard say it's the sweet spot.

Ninpo said and I quote "Why would you strangle your encode with things like 16 bframes and b-adapt 2, 16 refs then only use me umh and merange 16?!"

Definte how is it strangling it? If by strangle you mean improving the perceptable quality... then I think you answered your own question. If UMH sucks so much then why is it the default in every encoder app I've encountered.... you guys speak so lowly of it. That aside the "better" methods of ESA and TESA would immensely increase encoding time as does a 32-64 me_range.

If you can be so kind as to deconstruct and inform me of where and how I am wrong, not in an insulting childish way but in an informative educational way please do.

From http://trac.handbrake.fr/wiki/x264Options

Motion Estimation Method (me)
Controls the motion estimation method. At the most basic setting, dia, x264 will only consider a diamond-shaped region around each pixel. The default setting, hex, is similar to dia but uses a hexagon shape. Uneven multi-hexagon, umh, searches a number of different patterns across a wider area and thus is slower than hex and dia but further increases compression efficiency and quality. esa, an exhaustive search of a square around each pixel (whose size is controlled by the me-range parameter), is only intended for experimentation and testing of algorithms and should not be used, as umh will generally produce as good or better results in vastly less time.

^- UMH will generally produce as good or better results in vastly less time than ESA, no clue about TESA but that has to take longer.... why would you want to use ESA or TESA ever?

[roozhou]

I guess you are looking for SLOWEST settings instead of OPTIMAL settings, aren't you?

[Betsy25]

"Maximum quality"? Hurr.

I thought anything above me=umh was "placebo' ?????:confused:

[wyti]

I thought anything above me=umh was "placebo' ?????:confused:

it isn't placebo, it really increase the quality, but it's too slight to be visible by the human eye, and the speed down is terrible.

[Chengbin]

@LeoRexTyrannus

Nobody is insulting you.

It is a fact that bframe 16 + b adapt 2 AND ref-frame is incredibly stupid. It is stupid because there is almost no increase in compression while slowing the encode to a crawl. Ref 4 and bframe 4 + b adapt 2 will give you 99% of the compression while speeding up the encode like crazy.

The thing about umh and merange 16.

If we see someone that is using a ridiculously slow setting like 16 b and ref frames with b adapt 2, then we assume that the OP wants the slowest setting. Seeing that you have umh and merange 16 makes no sense.

[nm]

I agree that optimal is subjective, I'm trying to improve the profiles that exist to what the PS3 can actually handle as of this writing. I didn't mean to violate a forum rule and I did so unintentionally, my apologies won't happen again. VBV settings higher than those recommended were never used, I simply left this to what all of the source profiles agreed was acceptable, RipBot264 says 24000, MeGUI and Handbrake say 25000, so I went with that. I didn't mention my resolution I was in such a hurry to get this out there and it was a late night posting, my apologies. My source was 720x480 NTSC DVD, specifically Squidbillies Volume 2, the test sample was a bonus on the disc called "Dragonbillies" they produced for Dragoncon. The source was interlaced, top field first. I hope that clears that up.
I'd suggest changing the thread title to reflect this. For example, "Leo's x264 profile for PS3 (SD animation)".

The PS3 supports audio at Level 4.2, however video does not function. I don't know if you can use R=16 w/ HD sources (i.e. Blu-ray, etc)
As Comatose said, you can't. PS3 restricts the number of allowed references to L4.1 limits.

Ref=16 is silly how... because it improves quality and lowers file sizes?
Because it only works for SD resolutions (and even then it isn't portable to other standalone players that may require L3.1 for SD) and the quality improvement over ref=3..8 is minimal. Cel animation benefits more than other types of video, which may be the reason you're seeing any improvement at all -- assuming you've actually done proper experiments.

B-Frames 16 and Adapt 2 improved quality and didn't increase my encoding time noticably, I think you're just plain wrong about this one Audio.
I tried your settings on a T7200 (2 GHz Core 2 Duo), 576p25 video (deinterlaced DVB capture of a news program), bitrates matched by adjusting CRF slightly:
(a) ref=16, bframes=16 ---> fps:2.2 (SSIM:0.9869982, OPSNR:44.767, kb/s:2932.85)

(b) ref=16, bframes=3 ---> fps:3.0 (SSIM:0.9869707, OPSNR:44.748, kb/s:2929.53)

(c) ref=3, bframes=16 ---> fps:3.1 (SSIM: 0.9869583, OPSNR:44.750, kb/s:2931.90)

(d) ref=3, bframes=3 ---> fps:4.6 (SSIM: 0.9869579, OPSNR:44.743, kb/s:2930.30)
(d) is over twice as fast as (a) and I only had to increase the bitrate by 1 % (30 kbps) to make the SSIM and OPSNR of (d) exceed those of (a) on this video.

CRF 18 looks nice to me, has a good level of compression to the files, I'm happy with it and that's why I use it, plus nearly all opinions I've heard say it's the sweet spot.
Since you are encoding under VBV restrictions with high quality / slow parameters, you might also want to consider running a second pass after a CRF first pass (pass=1:crf=18) with the target bitrate set to the average bitrate that you got in the first pass. x264's VBV works better in 2-pass mode. You can speed the encoding up by using fast settings in the first pass. This would make the whole process 20-40 % slower than a single CRF pass.

[LeoRexTyrannus]

@Roozhou one mans slow is another mans optimal. My goal is simply best perceiveable quality possible with X264+PS3. I used settings I thought would achieve it, if I was wrong it's out of niavity not malice.

@Betsy and Wyti I'm sure TESA gives higher quality, at a cost of vastly increased encode time with minimal perceptable differences, it's after all called Thorough Exhaustive.

@Chengbin it may be true R=4 B=4 Adapt=2 could equal 99.9% but encoding time isn't my concern in this application, only final quality within the constraints imposed. I completely understand the attitude with UMH and MERANGE=16, given my settings and what you've all been so kind to enlighten me with I agree with those settings I should be using TESA and MERANGE=64. To be hoenst when I found all this out, I was using RipBot264 and RipBot doesn't have an option for changing the MERANGE.

@nm I agree with the title change, though I'd have to do tests of these settings and compare them for non-animated SD content before I would assume this wouldn't work very well for it. This is Cel based hand drawn animation they then computer animate so your point in that regard carries a lot of weight. On your test encodes what were your file sizes like though? That's the interesting part, mainly I was using the increased R&B frames because I noticed a significant if not giant reduction in file sizes with no perceivable negative impact to quality. Perhaps the FPS is halved by the fact that your source is real life vs. mine being animation. I'll do more tests.

So pretty much everyones consensus is that these settings are overkill, and if it's overkill I'm half assing it with the UMH and MERANGE 16.

Thank you for all of the imformative posts, I do appreciate you holding the hand of an obvious encoding "noob".

Sorry if I offended anyone, not my intention certainly.

[LeoRexTyrannus]

I whipped out RipBot264 1.14.1 using my little test clip I did two encodes one with these settings below, and then another with the settings farther down, note the only difference is ME=UMH vs ME=TESA

--level 4.1 --aud --nal-hrd --vbv-bufsize 25000 --vbv-maxrate 25000 --filter 0,0 --ref 16 --mixed-refs --bframes 16 --b-adapt 2 --weightb --b-pyramid --direct auto --subme 9 --trellis 2 --partitions all --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim

------------------------------------------------------------

--level 4.1 --aud --nal-hrd --vbv-bufsize 25000 --vbv-maxrate 25000 --filter 0,0 --ref 16 --mixed-refs --bframes 16 --b-adapt 2 --weightb --b-pyramid --direct auto --subme 9 --trellis 2 --partitions all --8x8dct --me tesa --threads auto --thread-input --progress --no-psnr --no-ssim

Can someone tell me why the "superior" TESA produced a file much larger than the "inferior" UMH?

Below is the data from the two files produced as provided by MediaInfo

General
Complete name : C:\Users\Charles\Desktop\Test1.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 2.82 MiB
Duration : 13s 354ms
Overall bit rate : 1 769 Kbps
Encoded date : UTC 2009-06-03 06:07:50
Tagged date : UTC 2009-06-03 06:07:50

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 13s 346ms
Bit rate mode : Variable
Bit rate : 1 637 Kbps
Maximum bit rate : 4 205 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16/9
Frame rate mode : Constant
Frame rate : 29.970 fps
Standard : NTSC
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.158
Stream size : 2.60 MiB (92%)
Writing library : x264 core 67 r1162M f7bfcfa
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=crf / crf=18.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=25000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
Encoded date : UTC 2009-06-03 06:07:50
Tagged date : UTC 2009-06-03 06:07:50

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 13s 354ms
Bit rate mode : Variable
Bit rate : 128 Kbps
Maximum bit rate : 136 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 209 KiB (7%)
Language : English
Encoded date : UTC 2009-06-03 06:07:50
Tagged date : UTC 2009-06-03 06:07:50


-----------------------------------------------------------

General
Complete name : C:\Users\Charles\Desktop\Test2.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 2.88 MiB
Duration : 13s 354ms
Overall bit rate : 1 807 Kbps
Encoded date : UTC 2009-06-03 06:10:26
Tagged date : UTC 2009-06-03 06:10:26

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 13s 346ms
Bit rate mode : Variable
Bit rate : 1 674 Kbps
Maximum bit rate : 4 081 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16/9
Frame rate mode : Constant
Frame rate : 29.970 fps
Standard : NTSC
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.162
Stream size : 2.66 MiB (93%)
Writing library : x264 core 67 r1162M f7bfcfa
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=tesa / subme=9 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=crf / crf=18.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=25000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
Encoded date : UTC 2009-06-03 06:10:26
Tagged date : UTC 2009-06-03 06:10:26

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Codec ID : 40
Duration : 13s 354ms
Bit rate mode : Variable
Bit rate : 128 Kbps
Maximum bit rate : 136 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 209 KiB (7%)
Language : English
Encoded date : UTC 2009-06-03 06:10:26
Tagged date : UTC 2009-06-03 06:10:26

[J_Darnley]

Can someone tell me why the "superior" TESA produced a file much larger than the "inferior" UMH?

General
Complete name : C:\Users\Charles\Desktop\Test1.mp4
File size : 2.82 MiB
Duration : 13s 354ms
Overall bit rate : 1 769 Kbps

-----------------------------------------------------------

General
Complete name : C:\Users\Charles\Desktop\Test2.mp4
File size : 2.88 MiB
Duration : 13s 354ms
Overall bit rate : 1 807 Kbps

I would hardly call that "much larger". Anyway "better" settings do not have to produce smaller files when using crf. Crf is not magic which ensures precisely the same quality regardless of settings.

[nm]

On your test encodes what were your file sizes like though?
I showed the average bitrates, which tell that the variation in file sizes was less than 0.15% since I manually adjusted CRF to get similar bitrates (16 468 kB for the largest and 16444 kB for the smallest file). Other alternatives would be to encode in 2-pass mode and compare quality or match the quality of the encodes by changing the bitrate/CRF by trial&error and then compare file sizes. Visual quality comparisons are preferrable over metrics such as PSNR and SSIM. (I was too lazy to compare visually and I doubt I would have seen any difference between the encodes in this case. I also didn't change psy optimizations).

That's the interesting part, mainly I was using the increased R&B frames because I noticed a significant if not giant reduction in file sizes with no perceivable negative impact to quality.
Note what J_Darnley said about comparing settings at a fixed CRF. The smaller files could also have worse quality, in which case you can't say anything about the effect of your settings.

Perhaps the FPS is halved by the fact that your source is real life vs. mine being animation. I'll do more tests.
The speed impact of these parameters should be about the same regardless of the content.

[LeoRexTyrannus]

Ok Thank you NM that was informative.

I did an extremely long test encode last night and somehow my computer didnt' generate the MP4's, I was using MeGUI with a full episode extra off one of the discs with some real life content mixed with a little animation in it.

I used me_range=64 and me=umh, that encode lasted from 6:23:23 AM - 7:18:37 AM for a grand total of 54 minutes, 37 seconds.

I then used the same me_rang w/ me=tesa that encode lasted from 7:19:02 AM - 12:44:19 PM for a grand total of 299 minutes, 37 seconds

Now based on my previous tests and what my eyes can see..... for the insanely increased encoding time it isn't worth using TESA even if you're using high B Frames and Refs.

3x the encoding time for no noticable increase in quality? That's insane.

[Comatose]

Comatose said and I quote "but there is one big mistake about your settings. The PS3 don't support profile beyond 4.1, so you can't use 16 ref frames with HD contents ! And why is that optimal settings ? I may need more speed, or i may have a whole week to spent using --me tesa and merange 32. the point is that optimal settings aren't existing ! it depends on what you need."
That was not me, look again.

[LeoRexTyrannus]

My apologies Comatose, I guess it all ran together to me.

I still don't agree with anyones assertions here. me_range increases and ESA or TESA motion estimation seem to do extremely little for final quality while at the same time making an encode take immensely longer for little if any visible gain. I don't think I'll be using those settings even with more ref's and b-frame's as was my original stance, no one has proven to me that it's worth using higher me range or more thorough me patterns than Uneven Multi Hexagon.

As for R and B-Frames on my test clip 4 R&B took 38 seconds to encode, 8 took 47 seconds, 16 took 71 seconds. From that it only doubles at the highest end, there's no reason to use 4 when 8 takes a mere 9 seconds longer in my example, unless your encode was titanically long.

[Chengbin]

16 b and ref frames does next to nothing as well.

[Comatose]

The speed impact of these parameters should be about the same regardless of the content.
Try encoding a blackness video with no motion and a high motion video. The blackness video will go much, much faster.

Obviously it's exaggerated by the complete lack of any difference between frames, but there is a difference between different sources, which is most likely more pronounced in anime vs live action.

[nm]

Try encoding a blackness video with no motion and a high motion video. The blackness video will go much, much faster.
Sure it goes faster, but I was talking about the relative speed impact: 16 refs & b-frames compared to lower numbers. That factor is not influenced much by the video content. Well, to be exact, multiple references are fast when the video content is very simple, but b-adapt 2 is still slow:
$ x264 --crf 20 --ref 16 --bframes 16 --b-adapt 2 --mixed-refs --8x8dct --subme 9 --me umh --threads auto -o blank.264 --progress --frames 1000 /dev/zero 720x576
[...]
encoded 1000 frames, 36.61 fps, 5.32 kb/s


$ x264 --crf 20 --ref 3 --bframes 16 --b-adapt 2 --mixed-refs --8x8dct --subme 9 --me umh --threads auto -o blank.264 --progress --frames 1000 /dev/zero 720x576
[...]
encoded 1000 frames, 37.14 fps, 5.18 kb/s


$ x264 --crf 20 --ref 16 --bframes 3 --b-adapt 2 --mixed-refs --8x8dct --subme 9 --me umh --threads auto -o blank.264 --progress --frames 1000 /dev/zero 720x576
[...]
encoded 1000 frames, 77.43 fps, 5.32 kb/s


$ x264 --crf 20 --ref 3 --bframes 3 --b-adapt 2 --mixed-refs --8x8dct --subme 9 --me umh --threads auto -o blank.264 --progress --frames 1000 /dev/zero 720x576
[...]
encoded 1000 frames, 77.32 fps, 5.18 kb/s

[Comatose]

Fair enough, but it's still just the b-frames :P

Anyway, --bframes 16 --b-adapt 2 is stupid, everybody know that, party time!