Has anyone used X264 to produce a replicated BD title?

[tyee]

Still can't download, all I get is this url

http://yyhpsq.blu.livefilestore.com/y1po0jl8826qLY4azx-WbrsbDeznY-Yw3PAuSsBAKsMNt2dz4_g6bbr5cRAgqxGlGT3zy50y465uoNzalB6BbgiGQ/Island_1080p24_lag_51.7z.021?download

with a blank page looking at me. Both in FF and IE. Strange. Even creating a windows live ID and sign in, still the same!

[imcold]

I can't get the archives open. I've tried winrar, 7-zip, renaming the extensions.

You have to combine the files into one first, then decode.

[Lyris]

Just to keep this thread on topic:

Lyris, so what do you plan to use? x264 at level 4.0, or Mainconcept Reference?Whichever is proved to verify successfully. Hopefully x264.

[multimediaman]

Extracted using CLI
7z e Island_1080p24_lag_51.7z.001
No problem at all

Quite bad banding in the source
http://img149.imageshack.us/i/shotl.png/

It was a bit tricky to get lagarith working on Linux but wine wine, avisynth, av2yuv.exe solved the problem.

[CruNcher]

Thats the little drawback as Ben said its 8 bit not a 10 bit DPX Source :(

[yau]

It was a bit tricky to get lagarith working on Linux but wine wine, avisynth, av2yuv.exe solved the problem.

It seems that Lagarith decoding is coming to FFmpeg, and therefore also to MPlayer. It already works if you apply these patches (http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/074177.html) (minus the FFmpeg stuff) and add this to your MPlayer codec.conf:


videocodec fflagarith
info "FFmpeg Lagarith"
status working
fourcc LAGS
driver ffmpeg
dll lagarith
out YV12


MPlayer however seems to have problems with the audio; I extracted it using -dumpaudio and converted it using Audacity (the format seems to be PCM 24 bit, signed, little endian, 48000 Hz, 6 channels).

[Biggiesized]

No problem there.
Do a checksum then. I already posted the correct checksum.

Highlight all 45 parts and then select the checksum option in 7-zip.

[Audionut]

Yeah my checksum doesn't match. Next problem is that I am getting the same problem as tyee.

Just a blank page after trying to download again.

[benwaggoner]

The page is opening fine for me.

Someone who has been able to download it is welcome to reencode and post in a better way than I did. I was on my way to the airport, and did it the quickest way I thought of.

Anyway, I'm looking foward to some BD-compliant samples with it! I'll try to get the Match Point source available soon.

I also have 4:2:2 10-bit source from 35mm telecine for that "Lady Washington" shoot which I've been meaning to finish for a couple of years now. That'd be a good 6 minutes long. Hard to imagine when I'd have a free week to do a good job on it though; certainly not before October with IBC coming up.

[dvdboy]

It is obvious that encoded stream have buffer underflows. Sinece x264 VBV sistem isn't stable and NAL HRD aslo isn't stable, you can try with new lookahead VBV or if you use maybe to try to downgrade to older x264 to see is there difference.

Aslo you miss --aud in your comand line, maybe is that catch?

Still having issues. My command line looks like this:

program --profile high --pass 2 --bitrate 20000 --stats ".stats" --level 4 --keyint 24 --min-keyint 2 --ref 4 --b-adapt 2 --direct auto --deblock -1:-1 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 24000 --qcomp 0.5 --me umh --thread-input --interlaced --output "output" "input" --mvrange 511 --nal-hrd --aud --sar 1:1

I'm using MeGUI as a front end.

2009-08-20T08:14:34Z|ERROR|MUX_SN_E_TS_UNDERFLOW_ERR|F:\x264 Test\01.00.0000\Output\MUX\BDROM\DB\BDMV\STREAM/00002.m2ts|0|Buffer underflows|TSWrapper.dll::CTSWrapper::ProcThreadMain::Video buffer underflows. - |

I'm running build 1183, which I believe is the most recent from this topic:

http://forum.doom9.org/showthread.php?t=89979

What is everyone else running to get files that mux?

I'll try a CBR encode and see if that works.

:thanks:

[nm]

program --profile high --pass 2 --bitrate 20000 --stats ".stats" --level 4 --keyint 24 --min-keyint 2 --ref 4 --b-adapt 2 --direct auto --deblock -1:-1 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 24000 --qcomp 0.5 --me umh --thread-input --interlaced --output "output" "input" --mvrange 511 --nal-hrd --aud --sar 1:1
Perhaps the same parameters without --interlaced would work better, so try on a progressive video?

I'm running build 1183, which I believe is the most recent from this topic:
r1217 is the latest. Patched builds are announced in this thread: http://forum.doom9.org/showthread.php?t=130364

[Lyris]

Hey everyone,

Turns out that my dissatisfaction with the Netblender Dostudio Encoder is due to an error. Support contacted me directly and are looking at it. In other words, the results I was getting definitely weren't deemed "good enough" by Netblender. I look forward to reevaluating it.

[Audionut]

The page is opening fine for me.

Same here. It was only when clicking the download link that the problem arose. Its working for me now though and it turns out I must have had a corrupt part. I got it extracted.

Thanks Ben.

[bautschi]

Concerning the underflows with ScenaristBD 5.1.2, I don't have that software. My question therefore is, are there possibilities to check encodings for such errors? Does x264 tell me while encoding? mkvmerge?
For me it also raises the problem of what can I do to check if my encodings have some kind of errors that I have never even heard of.

I was thinking of using x264 for my regular dvb-s recordings (PAL 576i) and with 720x576 I need interlaced accoring to wikipedia, as 576p is not supported.

After researching vbv underflows ( I found some good explanation for mpeg2, but the principle hopefully apllies ) I tried some settings:

all 2 pass:
--vbv-maxrate 15000 --vbv-init 0.999 --vbv-bufsize 1000 --bitrate 15000
x264 [warning]: VBV buffer size too small, using 1800 kbit and
encoder/set.c:614: x264_sei_buffering_period_write: Assertion `( buffer_fill_final * 90000. / ( buffer_rate ) ) < pow( 2,
sps->vui.nal_hrd_parameters.i_initial_cpb_removal_delay_length )' failed.
Aborted

--vbv-maxrate 15000 --vbv-init 0.999 --vbv-bufsize 1000 --bitrate 5000 --- same

--vbv-maxrate 15000 --vbv-init 0.999 --vbv-bufsize 1500 --bitrate 5000 --- x264 [warning]: VBV buffer size too small, using 1800 kbit
encoded 368 frames, 7.09 fps, 4985.78 kb/s

As I had --min-keyint 24 --keyint 24, how can almost a second with average of 4985.78 kb/s fit with vbv-bufsize 1800? Does the decoder not need at least information from one I-frame to the next ( and even more, when a frame uses a reference from outside of the gop) ? That should be be more than in the buffer... .

As I most obviously don't understand something here, my main concern is how to check for problems. Knowing that there is a problem is better than being blind.

Mkvmerge gave no errors when merging with ac3 sound and and vlc played everything all right (Linux).

I was using x264-snapshot-20090819-2245 with x264_hrd_pd_interlace.16.diff.

complete cl:

ffmpeg -top -1 -i $infile -f rawvideo - 2>x264-ffmpeg.log | x264 $options --pass 1 --bitrate $bitrate -o out.mkv - 720x576
ffmpeg -top -1 -i $infile -f rawvideo - 2>x264-ffmpeg.log | x264 $options --pass 2 --bitrate $bitrate -o out.mkv - 720x576

$options: --profile high --tune film --slow-firstpass --level 4 --aud --min-keyint 24 --keyint 24 --bframes 3 --b-adapt 2 --ref 9 --deblock -1:-1 --subme 10 --interlaced --vbv-maxrate 15000 --vbv-init 0.999 --vbv-bufsize 1500

Hope this was not too much info ... my first action in a forum in years... .

Greetings,
bautschi

[Dark Shikari]

x264 will never violate the VBV restrictions you set without telling you. If it doesn't tell you, it didn't violate them.

[bautschi]

thank you.

[Guest]

x264 will never violate the VBV restrictions you set without telling you. If it doesn't tell you, it didn't violate them. Unless you care about little things like AUDs, etc., that you don't allow for.

[Dark Shikari]

Unless you care about little things like AUDs, etc., that you don't allow for.AUDs aren't part of the video coding layer (VCL) as far as I recall, which is what x264's VBV covers. It is not NAL VBV.

(Speaking of which, I still don't understand why Trahald is trying to patch x264 with a NAL-HRD patch despite the VBV being VCL...)

[Guest]

In real decoders the NALU stream is buffered, so while what you say is technically correct, there is the possibility to underflow on a real system even if the VCL VBV is fine. Am I wrong about that?

[Dark Shikari]

In real decoders the NALU stream is buffered, so while what you say is technically correct, there is the possibility to underflow on a real system even if the VCL VBV is fine. Am I wrong about that?Of course--any system that requires NAL HRD clearly requires NAL VBV for exactly the same reason, so only one isn't going to cut it.

[Trahald]

the nal hrd patch adds aud sei etc to the buffer calculation (well if i coded it right it does, and thats not a certainty.)

[Trahald]

btw.. id be more than happy to shift-del the hrd patch if someone in dev codes up something acceptable. until then, broken or not, its all we have.

[Dark Shikari]

the nal hrd patch adds aud sei etc to the buffer calculation (well if i coded it right it does, and thats not a certainty.)btw.. id be more than happy to shift-del the hrd patch if someone in dev codes up something acceptable. until then, broken or not, its all we have.Delete it? Are you crazy? How about commit it?

If you can show that it properly converts x264's VBV model to NAL-based and writes correct HRD information, there's no reason not to commit it.

Also, get back on IRC, you have stuff to do ;)

[Jumpyshoes]

http://shimapan.users.sourceforge.net/island/

Here's a mirror.

[Revgen]

http://shimapan.users.sourceforge.net/island/

Here's a mirror.

The avi file stopped downloading at 1.0gb. Does sourceforge have a download limit for single files?

[Revgen]

Ben,

Are you absolutely sure this is original footage?

Around the 1210 to 1218 frames, Ewan MacGregor has a "blur block" on the left side of his face.

http://img43.imageshack.us/img43/8996/islandblotchpng001217.th.png (http://img43.imageshack.us/i/islandblotchpng001217.png/)

The above image is frame 1217.

[DeeGee]

That doesn't look like compression artifact. Looks like they blurred something intentionally from his face?

[Lyris]

I speculated on this a few pages back, it looks like compositing work (perhaps adding the freckle?) that hasn't been grain-matched. In any case, there's no reason to doubt the authenticity of the source.

[Bigmango]

if you use x264 as encoder then don't use B-pyramid because can broke DBP, but B-Pyramid is generaly alowed thing (Sonic Scenarist use it but automaticly decrase ref by one)

I have read in several places and wikis around the web that while this was a problem with older x264 versions, it is now fixed in the newer versions - it is now constant based on ref.

So, what is the truth behind this? Does B-pyramid still break some player compatibility or not?

[Chengbin]

I have read in several places and wikis around the web that while this was a problem with older x264 versions, it is now fixed in the newer versions - it is now constant based on ref.

So, what is the truth behind this? Does B-pyramid still break some player compatibility or not?

4 ref frames=good
3 ref frames + b-pyramid=good
4 ref frames + b-pyramid=not good.

[Bigmango]

4 ref frames=good
3 ref frames + b-pyramid=good
4 ref frames + b-pyramid=not good.

Ok, thanks.

What is the better suggestion quality wise: "4 ref frames" or "3 ref frames + b-pyramid" ?

[popper]

what is the point of using more than ref=3 today anyway ?, is there really any quality to be gained in your generic SD (PIP) or HD live action footage.

[shon3i]

4 ref frames=good
3 ref frames + b-pyramid=good
4 ref frames + b-pyramid=not good.
Sorry but b-pyramid in x264 are not good at all, because almost always break DBP. 4 ref frames + b-pyramid is impossible combination, while 3 ref frames + b-pyramid should be fine but with normal b-pyramid which x264 dosen't have. 4ref's can be aslo unsafe in x264 only because can aslo break DBP (from earlier testing) So 3refs are only safe now with current x264 builds, until devs fix things.

So, what is the truth behind this? Does B-pyramid still break some player compatibility or not? Yea, still is broken even in new version.

[CruNcher]

what is the point of using more than ref=3 today anyway ?, is there really any quality to be gained in your generic SD (PIP) or HD live action footage.

mostly not but people generally believe that higher numbers in OPSNR or SSIM have a big major effect on their viewing experience and the more the better ;)
Creating mass of content that not all of the current Device Generation is able to playback, though essentially it's not a bad thing it brings manufactures under pressure to deliver the performance from their Hardware user expect to play their "Home Made" Content on :)
In the Standalone area we already hit that mostly next will be the low power Mobile area which still struggles with what the consumers expect (and imho not all the complexity user put in their encodes is really always necessary but they are used to it already and the industry needs to comply). It will be really interesting to see how this might could push again lower complexity (Old Generation Codecs) once more as their complexity is pretty much playable on every Device that's gonna come out so the need of trans-coding is virtually gone for those, H.264 didn't reach that yet and most probably will take another Year end of 2010 till that goal will be reached.

So you can say we reached a Transcoding free consumer world for ASP and VC-1 now (but not everywhere used like in Sat Broadcast), though H.264 will take another year in that :)

[dvdboy]

Unfortunately, I'm still not having much luck - now using a 23.976fps file to rule out possible interlace compatibilities.

My MeGui configuration line looks like this:

program --profile high --level 4 --preset fast --pass 2 --bitrate 18000 --stats ".stats" --thread-input --deblock -1:-1 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 1 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 23000 --qcomp 0.5 --me dia --subme 2 --partitions none --trellis 0 --no-mixed-refs --mvrange 511 --nal-hrd --aud --sar 1:1 --output "output" "input"

I downloaded jeeb's build 1222 and placed the x264.exe file into the tools directory of MeGUI, overwriting the existing x264.exe.

I'm assuming I'm missing something fundamentally basic here - I even knocked 1Mbps off the Max Bitrate hoping to give an extra room for error, but I'm still getting the same Buffer Underflow error in Scenarist.

Any suggestions?

:thanks:

[shon3i]

You can try to reduce vbv-buffer to 29000 or even to 24000 or less. Aslo can you cut 50 mb sample and post here to see where is problem. Aslo you can use tools like Elecard Buffer Analyser to see where underflow occur.

[kemuri-_9]

since mb-tree and vbv-lookahead are used in that command line,
the problem could likely be related to this (http://forum.doom9.org/showthread.php?p=1317951#post1317951)

[Dark Shikari]

since mb-tree and vbv-lookahead are used in that command line,
the problem could likely be related to this (http://forum.doom9.org/showthread.php?p=1317951#post1317951)It's not related unless x264 prints a "VBV buffer underflow" message.

[benwaggoner]

...and as promised for testing this scenario, here's 7zip Lagarith YV12 segments of Match Point.

A rather more typcial trailer than the insanely fast cutting, high grain, and constantly moving camera of "The Island." But it's chock full of fades.

http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/Match%20Point

[Audionut]

Can someone please provide a checksum.
I'm having problems extracting again.

[LoRd_MuldeR]

...and as promised for testing this scenario, here's 7zip Lagarith YV12 segments of Match Point.

A rather more typcial trailer than the insanely fast cutting, high grain, and constantly moving camera of "The Island." But it's chock full of fades.

http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/Match%20Point

Is there an automated way to download all those files? Downloading 38 files by hand isn't fun ;)

Unfortunately the overview page that shows all files doesn't exhibit proper download URL's, so DTA and friends can't help here...

Can't you ask Xiph to put it on their http://media.xiph.org/ (http://media.xiph.org/video/derf/) server or at least put it on a service like Rapidshare ???

[Lyris]

Can anyone here share the secrets for encoding compliant Secondary Video streams?

All I have so far is that the frame rate has to match the primary video, and since we're using AVC, the secondary video must be AVC also. And the max bit rate can't go above 8mbps, but this is talking heads stuff in SD resolution, so 2mbps should do it fine...

Can anyone fill me in on the VBV buffer size? Number of B frames? Keyframe interval?

[dvdboy]

OK, I'm in the process of uploading two clips to my skydrive account.

1 is The Island trailer that Ben posted, encoded with x264 build 1222. This muxes well in Scenarist 5.1.3.
Download x264 encode her --> http://cid-4574e83941533037.skydrive.live.com/browse.aspx/.Public/The%20Island%20-%20x264%20-%20BD

2 is a short clip from a German H.264 broadcast that I have parsed into AVISynth using DGAVCIndex, created a Lagarith YV12 avi file with VirtuaDub and the parsed that into MeGUI using an AVISynth script. This does not mux in Scenarist 5.1.3, giving me a buffer underflow error. This has been the file I have been trying to encode with at all manner of settings.

At this time I can't understand why one AVS source file should work, and another should not - both encode without errors.

The MeGUI config line for The Island is:

program --profile high --level 4 --preset fast --pass 2 --bitrate 18000 --stats ".stats" --slow-firstpass --thread-input --deblock -1:-1 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 1 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 24000 --qcomp 0.5 --subme 2 --partitions all --trellis 0 --no-mixed-refs --mvrange 511 --nal-hrd --aud --sar 1:1 --output "output" "input"

The MeGUI config line for AVC_TEST is:

program --profile high --level 4 --preset fast --pass 2 --bitrate 18000 --stats ".stats" --slow-firstpass --thread-input --deblock -1:-1 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 1 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 24000 --qcomp 0.5 --subme 2 --partitions all --trellis 0 --no-mixed-refs --mvrange 511 --nal-hrd --aud --sar 1:1 --output "output" "input"

In the end, it didn't matter if I dropped the max buffer size or max bitrates as the above encode for the Island worked fine, but nothing worked for the other file.

I'm assuming that for an x264 setting, the above is pretty 'basic' as I'm seeing compression artifacts over the green opening slate - I'll try automated 3 pass to see if that makes any difference, otherwise what do people suggest? Stoopid n00b question, but whenever I've done a 3 pass with MeGui before it always asks me to overwrite the 2nd pass with the 3rd pass - is this correct? Is there a way to out the 2 passes seperately? Would I ever need to do that?

Many Thanks

DVD-BOY

[benwaggoner]

Is there an automated way to download all those files? Downloading 38 files by hand isn't fun ;)
Sorry. I did it the way that was easiest for me, not for you :).

Can't you ask Xiph to put it on their http://media.xiph.org/ (http://media.xiph.org/video/derf/) server or at least put it on a service like Rapidshare ???
I think it's fine to post it where you like. Dreamworks provided it under terms where any encoded version of it can be freely used for compression tests and other demos. I just can't share the actual DPX files out.

[benwaggoner]

I'm assuming that for an x264 setting, the above is pretty 'basic' as I'm seeing compression artifacts over the green opening slate - I'll try automated 3 pass to see if that makes any difference, otherwise what do people suggest?
Oh, and as for that, the slate is pretty noisy, and in a very codec-annoying way. I thought about rendering out a clean new one, but heck, this is for codec testing :).

[LoRd_MuldeR]

I think it's fine to post it where you like. Dreamworks provided it under terms where any encoded version of it can be freely used for compression tests and other demos. I just can't share the actual DPX files out.

I was hoping that you could upload it to a better place. Preferably a place where it can be downloaded in one piece, so I could run the download over night :p

With my 128 kbit/s connection (upstream) it would take far too long to upload a file of that size :(

BTW: I downloaded the first three parts - just for test. And both, 7-Zip and WinRAR, refuse to open the archive with "unspecified error".

At least with RAR you can open multi-volume archives, even if you don't have all volumes (yet). So is anything wrong with my download or is that normal?

[multimediaman]

With ffv1+flac in mkv that trailer size shrinks to 1.7 GB ;)

[benwaggoner]

With ffv1+flac in mkv that trailer size shrinks to 1.7 GB ;)
Feel free :).

[shon3i]

@dvdboy, did x264 show VBV underflow during encode? since you use MeGUI for encoding check the log

[dvdboy]

@dvdboy, did x264 show VBV underflow during encode? since you use MeGUI for encoding check the log

I was ready to report back that it hadn't, when I noticed this:

[Information] Log
-[Information] Versions
--[NoImage] MeGUI Version : 0.3.1.1053
--[NoImage] OS : Windows XP Professional x86 SP2 (5.1.131072.2600)
--[NoImage] Latest .Net Framework installed
-[Information] Hardware
--[NoImage] CPU : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
-[Information] Log for job18 (video, SOURCE_lag_YV12.avs -> )
--[Information] [25/08/2009 23:28:57] Started handling job
--[Information] [25/08/2009 23:28:57] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --profile high --level 4 --preset fast --pass 1 --bitrate 18000 --stats "F:\WORKING_FILES\LAGARITH_SOURCE\small_test.stats" --thread-input --deblock -1:-1 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 1 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 24000 --qcomp 0.5 --me dia --subme 2 --partitions none --trellis 0 --no-mixed-refs --mvrange 511 --nal-hrd --aud --sar 1:1 --output NUL "F:\WORKING_FILES\LAGARITH_SOURCE\SOURCE_lag_YV12.avs"
--[Information] [25/08/2009 23:28:58] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1920x1080 @ 23.98 fps (193 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [warning]: VBV bitrate (24000) > level limit (20000)
---[NoImage] x264 [warning]: VBV buffer (30000) > level limit (25000)
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: profile Main, level 4.0
---[NoImage]
---[NoImage] x264 [info]: slice I:11 Avg QP:13.67 size:138864
---[NoImage] x264 [info]: slice P:58 Avg QP:15.22 size:113580
---[NoImage] x264 [info]: slice B:124 Avg QP:16.75 size: 73611
---[NoImage] x264 [info]: consecutive B-frames: 2.7% 6.6% 37.9% 52.7%
---[NoImage] x264 [info]: mb I I16..4: 65.8% 0.0% 34.2%
---[NoImage] x264 [info]: mb P I16..4: 53.1% 0.0% 0.0% P16..4: 29.0% 0.0% 0.0% 0.0% 0.0% skip:17.9%
---[NoImage] x264 [info]: mb B I16..4: 19.6% 0.0% 0.0% B16..8: 28.0% 0.0% 0.0% direct:26.4% skip:26.0% L0:32.8% L1:22.1% BI:45.1%
---[NoImage] x264 [info]: direct mvs spatial:97.6% temporal:2.4%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra:75.4% 91.1% 79.5% inter:36.9% 42.8% 9.4%
---[NoImage] x264 [info]: kb/s:17136.4
---[NoImage] encoded 193 frames, 5.90 fps, 17136.50 kb/s
--[Information] [25/08/2009 23:29:31] Postprocessing
---[Information] Deleting intermediate files
--[Information] [25/08/2009 23:29:31] Job completed
-[Information] Log for job19 (video, SOURCE_lag_YV12.avs -> small_test.264)
--[Information] [25/08/2009 23:29:31] Started handling job
--[Information] [25/08/2009 23:29:31] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --profile high --level 4 --preset fast --pass 3 --bitrate 18000 --stats "F:\WORKING_FILES\LAGARITH_SOURCE\small_test.stats" --thread-input --deblock -1:-1 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 1 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 24000 --qcomp 0.5 --subme 2 --partitions all --trellis 0 --no-mixed-refs --mvrange 511 --nal-hrd --aud --sar 1:1 --aud --output "F:\WORKING_FILES\LAGARITH_SOURCE\small_test.264" "F:\WORKING_FILES\LAGARITH_SOURCE\SOURCE_lag_YV12.avs"
--[Information] [25/08/2009 23:29:31] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1920x1080 @ 23.98 fps (193 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: profile High, level 4.0
---[NoImage]
---[NoImage] x264 [info]: slice I:11 Avg QP:14.06 size:132101
---[NoImage] x264 [info]: slice P:58 Avg QP:15.03 size:126728
---[NoImage] x264 [info]: slice B:124 Avg QP:16.61 size: 76492
---[NoImage] x264 [info]: consecutive B-frames: 2.7% 6.6% 37.9% 52.7%
---[NoImage] x264 [info]: mb I I16..4: 56.3% 19.6% 24.1%
---[NoImage] x264 [info]: mb P I16..4: 29.3% 24.7% 7.7% P16..4: 12.2% 4.3% 2.9% 0.6% 0.5% skip:17.6%
---[NoImage] x264 [info]: mb B I16..4: 19.3% 0.0% 0.0% B16..8: 27.1% 2.6% 2.1% direct:23.4% skip:25.6% L0:31.7% L1:21.6% BI:46.7%
---[NoImage] x264 [info]: 8x8 transform intra:23.3% inter:14.4%
---[NoImage] x264 [info]: direct mvs spatial:85.5% temporal:14.5%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra:76.5% 91.5% 79.3% inter:35.5% 42.8% 9.8%
---[NoImage] x264 [info]: kb/s:18175.5
---[NoImage] encoded 193 frames, 8.41 fps, 18175.54 kb/s
--[Information] Final statistics
---[NoImage] Video Bitrate Desired: 18000 kbit/s
---[NoImage] Video Bitrate Obtained (approximate): 18175 kbit/s
--[Information] [25/08/2009 23:29:54] Postprocessing
---[Information] Deleting intermediate files
--[Information] [25/08/2009 23:29:54] Job completed
-[Information] Log for job20 (video, SOURCE_lag_YV12.avs -> small_test.264)
--[Information] [25/08/2009 23:29:54] Started handling job
--[Information] [25/08/2009 23:29:58] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --profile high --level 4 --preset fast --pass 3 --bitrate 18000 --stats "F:\WORKING_FILES\LAGARITH_SOURCE\small_test.stats" --thread-input --deblock -1:-1 --keyint 24 --min-keyint 2 --b-adapt 2 --direct auto --ref 1 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 24000 --qcomp 0.5 --subme 2 --partitions all --trellis 0 --no-mixed-refs --mvrange 511 --nal-hrd --aud --sar 1:1 --aud --output "F:\WORKING_FILES\LAGARITH_SOURCE\small_test.264" "F:\WORKING_FILES\LAGARITH_SOURCE\SOURCE_lag_YV12.avs"
--[Information] [25/08/2009 23:29:58] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1920x1080 @ 23.98 fps (193 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: profile High, level 4.0
---[NoImage]
---[NoImage] x264 [info]: slice I:11 Avg QP:14.07 size:131778
---[NoImage] x264 [info]: slice P:58 Avg QP:15.03 size:126953
---[NoImage] x264 [info]: slice B:124 Avg QP:16.58 size: 76980
---[NoImage] x264 [info]: consecutive B-frames: 2.7% 6.6% 37.9% 52.7%
---[NoImage] x264 [info]: mb I I16..4: 56.5% 20.0% 23.5%
---[NoImage] x264 [info]: mb P I16..4: 29.4% 24.9% 7.4% P16..4: 12.2% 4.3% 3.0% 0.6% 0.5% skip:17.7%
---[NoImage] x264 [info]: mb B I16..4: 19.4% 0.0% 0.0% B16..8: 27.2% 2.5% 2.0% direct:23.4% skip:25.5% L0:32.0% L1:21.3% BI:46.7%
---[NoImage] x264 [info]: 8x8 transform intra:23.5% inter:14.4%
---[NoImage] x264 [info]: direct mvs spatial:84.7% temporal:15.3%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra:76.7% 91.6% 79.5% inter:35.7% 43.0% 9.9%
---[NoImage] x264 [info]: kb/s:18245.0
---[NoImage] encoded 193 frames, 8.25 fps, 18245.07 kb/s
--[Information] Final statistics
---[NoImage] Video Bitrate Desired: 18000 kbit/s
---[NoImage] Video Bitrate Obtained (approximate): 18245 kbit/s
--[Information] [25/08/2009 23:30:21] Postprocessing
---[Information] Deleting intermediate files
----[Information] [25/08/2009 23:30:21] Successfully deleted F:\WORKING_FILES\LAGARITH_SOURCE\small_test.stats
--[Information] [25/08/2009 23:30:21] Job completed


So does x264 believe the buffer / bitrate limits to be different to what was posted earlier in this thread, or did I misread your earlier post:

http://forum.doom9.org/showpost.php?p=1315154&postcount=106

...tbc