The new B-frame decision (--bframes 16 and you)

[vmrsss]

Hi again

1) I just added a line to the stats summary you get at the end of every encode, so try out the algorithm and see how many you get.

There is one extra value in the stats, eg for --bframes 16 I get:

x264 [info]: consecutive B-frames: 63.3% 4.1% 6.9% 6.9% 13.3% 3.9% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 1.5%

Can you please explain the 17th number?

In this case this tells me that about 95% of the B-frames occurs in sequences of length at most 5. Does this mean that forcing --bframes 5 carries corresponding to adding (0.05 * total number of B-frames) P-or I-frames? Another way to look at this is that the expected length of a B-frame sequence is 2.104, which may indicate that your previous suggestion --bframes 3 is sensible.

[Dark Shikari]

Can you please explain the 17th number?They're 0 to 16 B-frames, not 1 to 17.

[LoRd_MuldeR]

But why 16 consecutive b-frames were used in 1.5% cases, when 6-14 consecutive b-frames were used almost never?

[Dark Shikari]

But why 16 consecutive b-frames were used in 1.5% cases, when 6-14 consecutive b-frames were used almost never?There was clearly some sort of case where "more B-frames == better," according to the algorithm, and it capped at 16.

This could be, for example, at a completely static image.

[Ranguvar]

There was clearly some sort of case where "more B-frames == better," according to the algorithm, and it capped at 16.

This could be, for example, at a completely static image.
Would it be possible to set an option so that for speed purposes, there cannot be more consecutive b-frames than a set amount, as it is now, but x264 can use up to 16 b-frames in places it detects as the quoted text, like completely static images? Would the speed hit be worth the space saved by using more b-frames?

[Dark Shikari]

Would it be possible to set an option so that for speed purposes, there cannot be more consecutive b-frames than a set amount, as it is now, but x264 can use up to 16 b-frames in places it detects as the quoted text, like completely static images? Would the speed hit be worth the space saved by using more b-frames?More useful might be an extension to the current slicetype trellis method, as suggested by Manao, to cull paths that are not likely to be useful.

[LoRd_MuldeR]

I doubt that the "shortest way" algorithm can check 16 b-frames without having checked all the intermediate numbers as well...

[vmrsss]

They're 0 to 16 B-frames, not 1 to 17.

uh? sequence of 0 B-frames? From the code it appears clear that --counting from 0 to 15 -- the ith number is the proportion of B-frames occurring in sequences of length exactly i+1.

So is the 16th number the number of B-frames which would end up being in sequences longer than 16 if that weren't ruled out by the --bframes 16 option?

[LoRd_MuldeR]

Of course you can use a "sequence of 0 B-frames". Sometimes using only P-frames might be cheaper...

[vmrsss]

There was clearly some sort of case where "more B-frames == better," according to the algorithm, and it capped at 16.

This could be, for example, at a completely static image.

I suppose that may be that this feature starts with a relatively long sequence of non-scrolling titles where the frames are almost entirely black...

[vmrsss]

Of course you can use a "sequence of 0 B-frames". Sometimes using only P-frames might be cheaper...

yes, I understand that; but it wouldn't appear in the stats, as then you could count as many sequences of zero B-frames as you want between any two consecutive P-frames.

Also, do not forget that the stats does not give you the number of sequences of length k, but the number of **frames** in those sequences. And there are zero B-frames in sequences of length 0... (This is based on glimpsing at encoder.c)

[vmrsss]

I doubt that the "shortest way" algorithm can check 16 b-frames without having checked all the intermediate numbers as well...

that's right, it's dynamic programming.

[akupenguin]

Also, do not forget that the stats does not give you the number of sequences of length k, but the number of **frames** in those sequences. And there are zero B-frames in sequences of length 0... (This is based on glimpsing at encoder.c)
It counts the number P+B frames in a sequence of some Bs followed by one P.
I doubt that the "shortest way" algorithm can check 16 b-frames without having checked all the intermediate numbers as well...
Sure it can. We can lop out whatever edges we want from the graph. If I thought it was useful, I could test only 0 and 16 B-frames.
When/if we optimize pre-motion-search to merge the efforts of searching the same ref list in different versions of the frame, *then* it won't much cpu-time to ignore intermediate numbers. But that's independent of the dynamic programming part of the algorithm, and is rather part of the computation of the cost metric.

[skystrife]

Maybe I'm just doing it horribly wrong, but I'm consistently getting crashes when testing with --b-adapt 2.

r920 + psyRDO + hrd + progress indication.

Source: one of my fprofile samples, a 1080p sample of a crowd running (200 frames).

Command:

x264.920.modified.02.exe --pass 1 --bitrate 10000 --stats test.stats --ref 16 --mixed-refs --bframes 16 --b-adapt 2 --b-pyramid --b-rdo --bime --weightb --direct auto --filter 1,1 --subme 7 --trellis 2 --partitions all --8x8dct --me umh --merange 24 --aq-strength 1.2 --threads 6 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output NUL crowd.avs

Crashes at 65%-ish. It hangs there for a while at 25% cpu usage, and then suddenly quits when it moves on the next frame.

If I run the same command with --b-adapt 1, it completes successfully: no crash, no hanging.

Not quite sure what's going on here... maybe it's just not happy with one of the other patches...

[Dark Shikari]

It could also be a bug in the algorithm. Its certainly not bug-free, I would think, though it should be relatively easy to debug given the fact that it uses strings to represent paths.

[wyti]

skystrife Can you upload your build with psyRDO hrd etc....
I really want to test this patch, but now i do all my encodes with psy-RDO, and it will be easier for me to compare with a patched version.
I know it's unstable, but for testing, it's a good thing no ?

[skystrife]

skystrife Can you upload your build with psyRDO hrd etc....
I really want to test this patch, but now i do all my encodes with psy-RDO, and it will be easier for me to compare with a patched version.
I know it's unstable, but for testing, it's a good thing no ?

Sure.

Here you go (http://forum.doom9.org/showthread.php?p=1163720#post1163720).

[LoRd_MuldeR]

What am I doing wrong? :confused:

LoRd_MuldeR@MULDER_NEU /c/downloads/x264_git
$ git clone git://git.videolan.org/x264.git
remote: Generating pack...
remote: Done counting 6479 objects.
remote: Deltifying 6479 objects...
remote: 100% (6479/6479) done
remote: Total 6479 (delta 5149), reused 168 (delta 123)
Receiving objects: 100% (6479/6479), 1.60 MiB | 237 KiB/s, done.
Resolving deltas: 100% (5149/5149), done.
Initialized empty Git repository in c:/downloads/x264_git/x264/.git/
Initialize x264/.git

LoRd_MuldeR@MULDER_NEU /c/downloads/x264_git
$ cd x264

LoRd_MuldeR@MULDER_NEU /c/downloads/x264_git/x264
$ patch -p1 < ../b-frames.diff
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.

LoRd_MuldeR@MULDER_NEU /c/downloads/x264_git/x264
$ patch -p1 < ../x264-psyrd-0.5.diff
patching file `common/common.c'
patching file `common/common.h'
patching file `encoder/analyse.c'
patching file `encoder/encoder.c'
patching file `encoder/rdo.c'
patching file `x264.c'
patching file `x264.h'

LoRd_MuldeR@MULDER_NEU /c/downloads/x264_git/x264
$

[Conquerist]

So I tested the build posted here (http://forum.doom9.org/showthread.php?p=1163149#post1163149), and found some peculiar results. I encoded a ~10 minute animation clip (the short film Kigeki). Even though it's animated, there's lots of artificial grain and dust to make it look like old film.

--b-adapt 2 gave me a lower PSNR and for some reason seemed to favor 15 consecutive B-frames. Because of the grain, this might be the "extreme case" like 300.

Here is the command line:
x264.920.new.bframes.decision.01.exe --pass 2 --bitrate 2000 --stats ".stats" --b-adapt 1/2 --ref 5 --mixed-refs --bframes 16 --b-pyramid
--b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input
--progress --output "badapt1/2.mp4" "kigeki.avs"and here's the logs--b-adapt 1
x264 [info]: consecutive B-frames: 21.4% 23.8% 10.1% 12.1% 13.5% 14.1% 0.4% 0.3% 0.0% 0.2% 0.1% 0.0% 0.1% 0.3% 0.0% 0.0% 3.7%
x264 [info]: PSNR Mean Y:49.011 U:53.972 V:53.690 Avg:49.835 Global:48.842 kb/s:2002.42

--b-adapt 2:
x264 [info]: consecutive B-frames: 2.6% 7.6% 5.2% 32.8% 4.7% 2.7% 1.2% 1.0% 0.4% 1.1% 0.5% 0.8% 1.5% 1.4% 0.0% 33.1% 3.3%
x264 [info]: PSNR Mean Y:48.752 U:53.800 V:53.521 Avg:49.619 Global:48.496 kb/s:2001.27

A 1000 frame low-motion clip from 300 never used more than 3 consecutive B-frames with the old method, while --b-adapt 2 used 15 consecutive B-frames 63.0% (but strangely never 16 consecutive ones) of the time, so this is probably the same "extreme case".

Edit: I already may have found a rather nasty bug in it, so don't complain just yetIs that bug related to this?

[Dark Shikari]

1. Here's the working patch (not changed since previously posted) (http://pastebin.com/f7f9b7323).
2. I'm working on the issue described above ;)

[LoRd_MuldeR]

Yup, that one does work :)

Here is the result from a live music ("rock am ring" festival) video clip:
x264 [info]: consecutive B-frames: 0,3% 9,7% 18,7% 26,6% 5,7% 6,2% 0,4% 0,1% 0,3% 0,1% 0,5% 1,5% 2,0% 1,6% 0,0% 26,2%

And yes, it slow: The CPU usage on my Quadcore dropped from ~99% to 45-75% ...

[Sagittaire]

Little test on HPII trailer:


|--------------|---------|---------|---------|---------|---------|
| Codec | PProc | Bitrate | Size | OPSNR | SSIM 2 |
|--------------|---------|---------|---------|---------|---------|
| DivX6 ASP | PP4 | 446 | 6757 | 39.85 | 65.02 |
| XviD ASP | PP4 | 446 | 6756 | 39.66 | 64.33 |
| LAVC ASP | PP4 | 447 | 6775 | 39.71 | 63.82 |
| Ateme AVC | PP0 | 446 | 6746 | 41.21 | 72.10 |
| x264 AVC | PP0 | 447 | 6760 | 41.50 | 73.07 |
| Elecard AVC | PP0 | 446 | 6745 | 41.22 | 71.89 |
| VP7 | PP2 | 446 | 6760 | 40.84 | 70.05 |
| VC1 | PP1 | 446 | 6746 | 40.27 | 66.87 |
| RV10 | HF2 | 446 | 6743 | 39.84 | 64.60 |
| DivX3 | PP4 | 447 | 6771 | 38.70 | 58.56 |
|--------------|---------|---------|---------|---------|---------|
| DivX6 ASP | PP4 | 896 | 13493 | 42.78 | 77.99 |
| XviD ASP | PP4 | 896 | 13489 | 42.66 | 77.96 |
| LAVC ASP | PP4 | 897 | 13528 | 42.77 | 77.77 |
| Ateme AVC | PP0 | 896 | 13495 | 43.75 | 81.59 |
| x264 AVC | PP0 | 896 | 13509 | 44.10 | 82.44 |
| Elecard AVC | PP0 | 896 | 13481 | 43.71 | 81.13 |
| VP7 | PP2 | 897 | 13534 | 43.34 | 80.02 |
| VC1 | PP1 | 896 | 13510 | 43.06 | 78.75 |
| RV10 | HF2 | 896 | 13493 | 42.77 | 77.72 |
| DivX3 | PP4 | 896 | 13508 | 41.84 | 74.40 |
|--------------|---------|---------|---------|---------|---------|
SSIM 0: Lumimask Off
SSIM 1: Lumimask On (Original Lumimask)
SSIM 2: Lumimask On (One2Tech Patch)

[LoRd_MuldeR]

Sample encoded at CRF=22

Method Max. B-Frames Size

Fast 16 4.631.020
Trellis 3 4.417.454
Trellis 5 4.303.896
Trellis 8 4.153.670
Trellis 10 4.049.532
Trellis 12 3.951.452
Trellis 16 3.797.840

Here is my sample:
http://mplayer.somestuff.org/misc/compare.7z

[Soichiro]

Sample encoded at CRF=22

Method Max. B-Frames Size

Fast 16 4.631.020
Trellis 3 4.417.454
Trellis 5 4.303.896
Trellis 8 4.153.670
Trellis 10 4.049.532
Trellis 12 3.951.452
Trellis 16 3.797.840

Interesting results. It seems that this patch will have a much greater benefit at lower bitrates then, judging from these stats.

Though I'm surprised that even 3 bframes with the new patch beat out 16 bframes with the old version. I assume this was a live action source and not animated, correct? The old version rarely used more than 3 bframes in a row with live action, while the new version seems to favor bframes in almost every circumstances (though that may be a bug, judging from multiple people getting huge numbers of 15-bframe sequences).

[burfadel]

A significant improvement even at 3 :) interesting that the improvement is consistent right up to 16, did the output quality remain the same? I know PSNR etc isn't exact, but was wondering whether at 16 the PSNR and SSIM were lower than that at say 8, just out of interest (owing that the filesize is smaller) :). If it is truly as good as the above table shows, hopefully DS can do some of his magic and reduce some of that speed loss!

[LoRd_MuldeR]

There is a visual difference, but I cannot say which one looks better yet. I'll upload a sample...

[skystrife]

Just an update on my issue. I just tested using bob0r's build to verify that it wasn't a confliction with the other patches, and it's not. However, it still crashed on me in the same spot as my build did. It appears to be an issue outside of x264, though, as adding SetMemoryMax(128) to the top of the script fixed the crash.

Though it's odd that a script consisting of only imagesource() and converttoyv12() would manage to make x264 hit its max address space...

Either way, it's probably related to avisynth on my end, so I would probably say that the patch itself is working.

EDIT: with my plugins folder empty it still crashes, so it's not related to autoloading... odd.

[LoRd_MuldeR]

Okay, I have added my sample to the previous post. Frame-by-frame comparison "Fast" vs. "Trellis" B-Frame decision method, using max. 16 B-Frames.

*click* (http://forum.doom9.org/showpost.php?p=1163990&postcount=73)

[Sharktooth]

h264 in avi...... aaaaargh....
the new b-frames decision loks better to me, less blocky backgrounds and slighrly sharper image (edit: after several views, i actually take the latter back).

[LoRd_MuldeR]

h264 in avi...... aaaaargh....

That is FFv1 in AVI :p

I decoded both encodes with FFmpegSource(), interleaved them in Avisynth and encoded everything with VirtualDub/ffdshow...

[Sharktooth]

oh... my bad. i thought you used lossless h.264 for the final encode.

[vmrsss]

It counts the number P+B frames in a sequence of some Bs followed by one P.

OK, thanks. Let's me test if I got it now:


x264 [info]: consecutive B-frames: 63.3% 4.1% 6.9% 6.9% 13.3% 3.9% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 1.5%


(1) the percentage refers to the total number of P+B frames in the encode

(2) the first number counts the number of PP sequences (0 B-frames), so it says that 63.3% of P+B frames occur as the second P in PP sequences

(3) the second number says that 4.1% of P+B frames occur (as the 2nd and 3rd element) in sequences PBP

(4) and so on till the 16th number.

Would it not be interesting --if possible-- to report how often a sequence BB... was terminated for having hit the --bframes limit? As a measure of how useful it may be to increase the --bframes parameter...

[akupenguin]

Would it not be interesting --if possible-- to report how often a sequence BB... was terminated for having hit the --bframes limit? As a measure of how useful it may be to increase the --bframes parameter...
The only way to know that is to run the algorithm for N+1 bframes, at which point the cpu-time is wasted if you don't actually use N+1 when it's chosen.

[skystrife]

Ok, I've done some more testing and I'm back to believing there's something in the patch. (For reference, I'm running a machine with 8GB of memory, so I think it has something to do with x264 running itself out of address space?)

http://forum.doom9.org/showthread.php?p=1158428#post1158428

I grabbed the referenced "sneak peak" and verified that it does in fact clamp to 1GB of memory usage (went on a video seeking spree in AvsP and watch the task manager).

So, I figured that this would solve my crashing error in the new patched x264. Well... not so much. x264 crashes (just your standard "x264 has stopped working," so I don't get any helpful info) after hitting a little over 1.3GB of memory.

I'm out of ideas, and it's weird that I'm the only one reporting this error.

Running the same command line (except with --b-adapt 1) with the same exact build completes perfectly fine, with memory usage peaking at about 1.35GB... more than what the --b-adapt 2 pass crashes at.

o_O

[check]

What is your input? Are you using a multithreaded avisynth modification?

[woah!]

i ran a full encode from 1080p POtC bluray to a 1280x720p bluray compatable dvd+rdl with these settings exactly the same for 1st and 2nd pass...

--b-adapt 2 --deadzone-inter 6 --deadzone-intra 6 -t 0 --aq-strength 1.0 -f -4:-3 --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 38000 --qcomp 0.5 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --mvrange 511 --aud --nal-hrd --sar 1:1


seems 1st pass was 11.67fps and 2nd pass was 16.3fps. but the result was very good for an avg bitrate of 6600.. no crashes on 206070 frames encoded...

[Sharktooth]

that's quite normal. D_S already said the b-frames decisions are made in the first pass.

[Comatose]

I don't think he was complaining, just providing input :P

[skystrife]

What is your input? Are you using a multithreaded avisynth modification?

Input is:


imagesource("pathtoimages\%05d.png", start=07410, end=07609)
converttoyv12()

No, I am not using any MT modification. I am NOW using AviSynth 2.58, but the same thing happens in AviSynth 2.57 (and earlier in this version too, interestingly enough).

Does anyone else have an absurdly large amount of ram (>= 4GB) in a machine that can test this? I think that is the cause of this, but I suppose I could be wrong. *shrug*

[burfadel]

Well running x264 from www.x264.tk and from skystrife there seems to be random crashes, although not frequent. This is the first build that has done that from my knowledge. I went away on 12 July, and at that time x264 seemed to be working fine! Its hard to test for too, its very random, and is not frequent. Encoding a lot of stuff that was on tv from when I was way, it happens only once every few shows or movies (it could go 10 hours without crashing or crash in 5 hours). If you run it again it encodes through the show where it crashed before.

Here are the options used:

--crf 24 --keyint 450 --ref 5 --mixed-refs --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --partitions all --8x8dct --trellis 2 --me umh --threads 4 --progress --thread-input --no-psnr --no-ssim

I'd like to point out that I am not using the b-frames patch, just the psy-rdo patch from the above mentioned builds. I though I'd mention it here since others are having crashes, which may be unrelated to the b-frames patch itself! With the above options, the RAM usage at 640x352 settles off at 1.5GB, which seems higher than previous x264 builds.

I'm running 4GB of RAM on Vista x64.

[Manao]

LoRd_Mulder : by your test methodology, using -b 16 --b-adapt 0 would yield even better results. Filesize alone means nothing

[Dark Shikari]

... and I found the bug that was causing long strings of 15/16 B-frames where there shouldn't be.

Fix will come up in a bit.

(Turned out the bug was in akupenguin's code) :p

[LoRd_MuldeR]

LoRd_Mulder : by your test methodology, using -b 16 --b-adapt 0 would yield even better results. Filesize alone means nothing

Sure. But a significant smaller file that looks at least as good as the reference (maybe even better) does mean something :)

[Sharktooth]

... and I found the bug that was causing long strings of 15/16 B-frames where there shouldn't be.

Fix will come up in a bit.

(Turned out the bug was in akupenguin's code) :p
now, it's only a matter of speed.
if you find a way to optimize the algo speed, then it can be used as default.

[akupenguin]

Sure. But a significant smaller file that looks at least as good as the reference (maybe even better) does mean something :)
No, really it doesn't. How good is your intuition of what a 5% bitrate difference is supposed to look like? If it's only "maybe" better, then do you know that it would have been out of he realm of maybe and beyond your error bounds if they had been encoded at the same bitrate?

There are only two valid comparisons: same bitrate and compare quality, or same quality and compare bitrate. And the latter only works with objective quality metrics, since psy quality isn't precise enough.
You can get lucky and find a case where encode B has both lower bitrate and higher quality than encode A, but then you can't quantify the amount of gain, so please don't post any numbers.

[LoRd_MuldeR]

No, really it doesn't. How good is your intuition of what a 5% bitrate difference is supposed to look like?

Well, if I visually compare the two files and the smaller file actually looks better (or equal at least), then I think this is definitely a good thing :)

Also I didn't claim that those "numbers" mean anything. I tested the new method with CRF, because that's how I'm gonna use it. And I post my results for discussion.

20% smaller file at same CRF definitely is an interesting observation, whether it means anything for judging the new method or not...


Doing a 2-Pass encode now ;)

[LoRd_MuldeR]

Running a 2-Pass encode I got this at 90% of the second pass:

*********** EXCEPTION **************
Registers:
EAX: 00000004 EBX: 00000003 ECX: 7D61F5ED EDX: 01120001 ESI: 77BA2C95
EDI: 00000000 ESP: 00228948 EBP: 00228C88 EIP: 77BC6B3E EFlags: 00000246

Exception Code: EXCEPTION_BREAKPOINT (80000003)
Exception Flags: 00000000

Origin:
C:\WINDOWS\syswow64\msvcrt.dll(assert+0x26B3E) [0x77BC6B3E]
*********** EXCEPTION **************

*********** BACKTRACE **************
Frame 0: D:\Avidemux 2.4.3\avidemux2_gtk.exe(Z16exceptionHandlerP17_EXCEPTION_RECORDPvP8_CONTEXTS1_+0x12B90E) [0x0052B90E]
Frame 1: C:\WINDOWS\system32\ntdll.dll(RtlRaiseStatus+0x1EC2A) [0x7D61EC2A]
Frame 2: C:\WINDOWS\system32\ntdll.dll(RtlRaiseStatus+0x1EBFB) [0x7D61EBFB]
Frame 3: C:\WINDOWS\system32\ntdll.dll(KiUserExceptionDispatcher+0x1EA36) [0x7D61EA36]
Frame 4: D:\Avidemux 2.4.3\libx264.dll(x264_slicetype_analyse+0x8F58) [0x6FC88F58]
*********** BACKTRACE **************

Edit: Same settings but b_adapt=1 will run through just fine. May this be related to the mentioned bug?

[Dark Shikari]

New patch (http://pastebin.com/m2a557e16)

Changes:

1. Bugfixes
2. Remove pyramid-specific code, it didn't seem useful
3. Precalculate intra cost once per frame instead of per slicetype call; can increase or reduce speed for --b-adapt 1 (depending on which phase the moon is in) and always increases speed on --b-adapt 2.
4. Add --weightb code; use --weightb on your first pass now. In a quick test, this greatly improved x264's detection and reaction to fades.

[LoRd_MuldeR]

Thanks for the new patch, but I still get the same crash, using 2-Pass mode:
*********** EXCEPTION **************
Registers:
EAX: 00000004 EBX: 00000003 ECX: 7D61F5ED EDX: 01460001 ESI: 77BA2C95
EDI: 00000000 ESP: 0022A278 EBP: 0022A5B8 EIP: 77BC6B3E EFlags: 00000246

Exception Code: EXCEPTION_BREAKPOINT (80000003)
Exception Flags: 00000000

Origin:
C:\WINDOWS\syswow64\msvcrt.dll(assert+0x26B3E) [0x77BC6B3E]
*********** EXCEPTION **************

*********** BACKTRACE **************
Frame 0: d:\Avidemux 2.4.3\avidemux2_gtk.exe(Z16exceptionHandlerP17_EXCEPTION_RECORDPvP8_CONTEXTS1_+0x12B90E) [0x0052B90E]
Frame 1: C:\WINDOWS\system32\ntdll.dll(RtlRaiseStatus+0x1EC2A) [0x7D61EC2A]
Frame 2: C:\WINDOWS\system32\ntdll.dll(RtlRaiseStatus+0x1EBFB) [0x7D61EBFB]
Frame 3: C:\WINDOWS\system32\ntdll.dll(KiUserExceptionDispatcher+0x1EA36) [0x7D61EA36]
Frame 4: d:\Avidemux 2.4.3\libx264.dll(x264_slicetype_analyse+0x8EB8) [0x6FC88EB8]
*********** BACKTRACE **************

There seems to be no problem for CRF mode though...

[Dark Shikari]

That "exception" report is utterly useless; I can't derive any useful information from it. How about a gdb backtrace on a build with --enable-debug?