x264 cli bugreports

[Doom9]

This thread is for x264.exe bugeports only. VfW users please go here (http://forum.doom9.org/showthread.php?t=108569)

[foxyshadis]

x264 won't output stats in crf mode even if told to. More feature request than bug. I guess I should have checked here before asking for it in Megui!

[ChronoCross]

x264 won't output stats in crf mode even if told to. More feature request than bug. I guess I should have checked here before asking for it in Megui!

what kind of stats are you talking about? Are you talking about Time, fps, bitrate?

[foxyshadis]

Sorry, I meant --stats "x.stats" for use if the crf is unsatisfactory and a second pass needs to be run at a higher bitrate.

[GodofaGap]

Do you have "--pass 1" in your commandline?

[foxyshadis]

No, and it works with it. That's why I was so confused, since I was sure it'd been working last week! Thanks.

[akupenguin]

Well, then you didn't tell it to output stats.
"--stats" just specifies a filename, and is not required (there is a default name). You also need a --pass 1/2/3 to tell it what to do with the statsfile.

[IgorC]

Note of informative character.

There was an AQ patch aplied for revs 466 and higher.
AQ from Sharktooth old build (380-400) wasn't at state of art but somehow brings better quality at (very) low bitrate.
New unofficial AQ patch of 466 doesn't do even half of that.
Some guys are still compiling new rev + AQ patch for test only.

[hpn]

AQ from Sharktooth old build (380-400) wasn't at state of art but somehow brings better quality at (very) low bitrate. New unofficial AQ patch of 466 doesn't do even half of that.

Looking at the source both AQ patches (398 and 466) seem almost identical. Akupenguin just replaced "h->mb.pic.i_stride[x]" with "FENC_STRIDE" (whatever that means) and aligned the new patch offsets with a most recent 466 revision, so at first I thought they were only cosmetic changes. But I just did 2 tests with both patches and got different encodes - the 398 encode was identical to an encode without --aq-strength and --aq-sensitivity at all (a phenomenon already discussed here), while the 466 produced a lower PSRN encode, but with better looking flat backgrounds (to my eyes). I'm still unsure which patch "is better", 398 or 466, or what sets of --aq-strength and --aq-sensitivity options really make difference and in what cases. It's obvious that AQ needs some thorough analysis by the devs in the future, that's why it's not in the SVN, so use AQ for nothing but tests only. I just posted both 398 and 466 AQ builds here (http://mujweb.cz/www/x264/)

[mindphuk]

Hi I already shot this to the x264-devel mailinglist and got an answer there. Unfortunately I could not do much with the answer, because it was technically to special for me.
Maybe here someone can help me:
------------------
Original message:
------------------
I am trying to encode different movies to h264 using ffmpeg and x264.
The system where the encoding happens, is a 64bit Gentoo linux (stage
3).
I tried different parameters of ffmpeg but can not get rid of the grev
fog in black areas of the videos. The problem appears only on some
frames and lasts different times. It seems that it depends on the GOP
setting: When I set GOP to high (300 or more), the problem apears only
some times but always on the same input files and the same time.
ffmpeg shows an output of the library telling something about an
overflow.

I will attach some screenshots of the problem and a logfile.

Greetings
G.K.


GOP size of 18

user ~> ffmpeg -y -i Speedball2_Trailer3.mov -vcodec h264 -b 7000k -bf 3 -g 18 -s 1280x720 -acodec mp3 -ab 96k Speedball2_Trailer3.avi
FFmpeg version SVN-r9361, Copyright (c) 2000-2007 Fabrice Bellard, et al.
configuration: --enable-libxvid --enable-libmp3lame --enable-libfaac --enable-gpl --enable-libx264 --enable-libfaad --enable-shared
libavutil version: 49.4.0
libavcodec version: 51.40.4
libavformat version: 51.12.1
built on Jun 19 2007 10:33:31, gcc: 4.1.1 (Gentoo 4.1.1-r3)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x2ac7d7afc040]negative ctts, ignoring
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Speedball2_Trailer3.mov':
Duration: 00:01:53.0, start: 0.000000, bitrate: 8215 kb/s
Stream #0.0(eng): Audio: mpeg4aac, 48000 Hz, stereo
Stream #0.1(eng): Video: h264, yuv420p, 1280x720, 29.01 fps(r)
Output #0, avi, to 'Speedball2_Trailer3.avi':
Stream #0.0: Video: libx264, yuv420p, 1280x720, q=2-31, 7000 kb/s, 29.01 fps(c)
Stream #0.1: Audio: libmp3lame, 48000 Hz, stereo, 96 kb/s
Stream mapping:
Stream #0.1 -> #0.0
Stream #0.0 -> #0.1
[libx264 @ 0x2ac7d7fcb790]using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow!
Press [q] to stop encoding
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377
frame= 10 fps= 0 q=4.0 size= 15kB time=0.2 bitrate= 607.8kbits/s
frame= 20 fps= 20 q=4.0 size= 20kB time=0.6 bitrate= 291.2kbits/s
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377
frame= 27 fps= 17 q=2.0 size= 110kB time=0.8 bitrate=1133.2kbits/s
frame= 32 fps= 16 q=4.0 size= 243kB time=1.0 bitrate=2064.4kbits/s
(...)
frame= 229 fps= 13 q=6.0 size= 7151kB time=7.8 bitrate=7553.6kbits/s
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377
frame= 236 fps= 13 q=4.0 size= 7179kB time=8.0 bitrate=7354.3kbits/s
(...)
frame= 255 fps= 13 q=2.0 size= 7212kB time=8.7 bitrate=6828.8kbits/s
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4377
frame= 262 fps= 13 q=4.0 size= 7277kB time=8.9 bitrate=6703.5kbits/s
frame= 269 fps= 13 q=2.0 size= 7402kB time=9.1 bitrate=6638.8kbits/s
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4219
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4219
frame= 276 fps= 13 q=4.0 size= 7580kB time=9.4 bitrate=6623.1kbits/s
(...)
frame= 289 fps= 13 q=4.0 size= 8072kB time=9.8 bitrate=6731.7kbits/s
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4141
[libx264 @ 0x2ac7d7fcb790]OVERFLOW levelcode=4141
frame= 293 fps= 13 q=3.0 size= 8342kB time=10.0 bitrate=6860.5kbits/s
frame= 299 fps= 13 q=6.0 size= 8635kB time=10.2 bitrate=6957.1kbits/s
frame= 304 fps= 13 q=7.0 size= 8928kB time=10.3 bitrate=7073.6kbits/s
(...)
no more errors here...
(...)
frame= 3280 fps= 8 q=-1.0 Lsize= 94184kB time=113.0 bitrate=6826.9kbits/s
video:92660kB audio:1325kB global headers:0kB muxing overhead 0.211337%
[libx264 @ 0x2ac7d7fcb790]slice I:186 Avg QP:20.54 size: 51168
[libx264 @ 0x2ac7d7fcb790]slice P:912 Avg QP:21.22 size: 41287
[libx264 @ 0x2ac7d7fcb790]slice B:2182 Avg QP:23.47 size: 21864
[libx264 @ 0x2ac7d7fcb790]mb I I16..4: 54.4% 0.0% 45.6%
[libx264 @ 0x2ac7d7fcb790]mb P I16..4: 50.0% 0.0% 0.0% P16..4: 26.8% 0.0% 0.0% 0.0% 0.0% skip:23.2%
[libx264 @ 0x2ac7d7fcb790]mb B I16..4: 22.2% 0.0% 0.0% B16..8: 42.0% 0.0% 0.0% direct: 3.5% skip:32.3%
[libx264 @ 0x2ac7d7fcb790]final ratefactor: 19.80
[libx264 @ 0x2ac7d7fcb790]SSIM Mean Y:0.9796557
[libx264 @ 0x2ac7d7fcb790]kb/s:6714.0

Same video with GOP size of 500:

FFmpeg version SVN-r9361, Copyright (c) 2000-2007 Fabrice Bellard, et al.
configuration: --enable-libxvid --enable-libmp3lame --enable-libfaac --enable-gpl --enable-libx264 --enable-libfaad --enable-shared
libavutil version: 49.4.0
libavcodec version: 51.40.4
libavformat version: 51.12.1
built on Jun 19 2007 10:33:31, gcc: 4.1.1 (Gentoo 4.1.1-r3)
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x2b2e462d5040]negative ctts, ignoring
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Speedball2_Trailer3.mov':
Duration: 00:01:53.0, start: 0.000000, bitrate: 8215 kb/s
Stream #0.0(eng): Audio: mpeg4aac, 48000 Hz, stereo
Stream #0.1(eng): Video: h264, yuv420p, 1280x720, 29.01 fps(r)
Output #0, avi, to 'Speedball2_Trailer3.avi':
Stream #0.0: Video: libx264, yuv420p, 1280x720, q=2-31, 7000 kb/s, 29.01 fps(c)
Stream #0.1: Audio: libmp3lame, 48000 Hz, stereo, 96 kb/s
Stream mapping:
Stream #0.1 -> #0.0
Stream #0.0 -> #0.1
[libx264 @ 0x2b2e467a4790]using cpu capabilities: MMX MMXEXT SSE SSE2 3DNow!
Press [q] to stop encoding
[libx264 @ 0x2b2e467a4790]OVERFLOW levelcode=4377
[libx264 @ 0x2b2e467a4790]OVERFLOW levelcode=4377
frame= 11 fps= 0 q=4.0 size= 16kB time=0.2 bitrate= 531.6kbits/s
(...)
no more errors here
(...)
video:92413kB audio:1325kB global headers:0kB muxing overhead 0.211776%
[libx264 @ 0x2b2e467a4790]slice I:7 Avg QP:20.43 size: 44850
[libx264 @ 0x2b2e467a4790]slice P:824 Avg QP:21.02 size: 44524
[libx264 @ 0x2b2e467a4790]slice B:2449 Avg QP:22.98 size: 23531
[libx264 @ 0x2b2e467a4790]mb I I16..4: 54.0% 0.0% 46.0%
[libx264 @ 0x2b2e467a4790]mb P I16..4: 54.3% 0.0% 0.0% P16..4: 24.3% 0.0% 0.0% 0.0% 0.0% skip:21.4%
[libx264 @ 0x2b2e467a4790]mb B I16..4: 22.7% 0.0% 0.0% B16..8: 42.8% 0.0% 0.0% direct: 3.8% skip:30.8%
[libx264 @ 0x2b2e467a4790]final ratefactor: 19.50
[libx264 @ 0x2b2e467a4790]SSIM Mean Y:0.9798082
[libx264 @ 0x2b2e467a4790]kb/s:6696.5

While GOP below 10 produces a lot of errors...

------
Reply:
------

When encoding CAVLC in Baseline or Main profile, there is a limit on the
size of any one DCT coefficient. This limit can only be reached with very
low QP or with extreme quantization matrices, so it shouldn't normally be
a problem, but ffmpeg has lousy defaults (such as min QP=2) which allow
such extreme cases.
And even though larger values are allowed in High profile (it needs them
to represent higher sample depth), I haven't implemented that in x264.
There is no direct relation between GOP size and overflow, though I-frames
are lower QP than P-frames and I-blocks are more likely to contain large
coefficients than P-blocks.

(pick any one of the following)
What you can do about it without modifying any source code:
Enable CABAC.
Set min QP to something reasonable (like x264's default 10).

What you can do about it with modifying source code:
Add codec-specific defaults in ffmpeg so that h264 doesn't default to
insane settings.
Make x264 encode that coefficient using High profile's larger level_code,
resulting in a syntactically valid stream but violating profile
constraints.
Make x264 re-encode the macroblock with a higher QP.
Make x264 re-decode the macroblock so that the reconstructed picture
matches the bitstream; there will still be an artifact but it will be
localized to a few blocks and fixed in the next frame.

[nm]

What you can do about it without modifying any source code:
Enable CABAC.
Set min QP to something reasonable (like x264's default 10).
You were suggested to use ffmpeg parameters -coder 1 -qmin 10
To get an encode with reasonable quality instead of trash, you should also tweak other parameters. Take a look at Robert Swain's FFmpeg x264 encoding guide (http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/).

[MasterNobody]

I found that x264 produces different files for my sample file when using next options:
x264.exe -B 800 --8x8dct -A p8x8,i8x8,i4x4 --me umh --subme 6 --trellis 2 --threads 5 --quiet --no-psnr --no-ssim -o output.264 test.aviI think that this bug somehow connected with use of multithreading. I suggest that it is somewhere in encoder\analyse.c x264_mb_analyse_init function but I am not sure. For testing I attached archive with my samle file and cmd-file for automation (it produces 100 files with my options).

[imcold]

It may be because using threads leads to non-deterministic encoding, so it's rather a feature.

[Sagekilla]

It may be because using threads leads to non-deterministic encoding, so it's rather a feature.

Especially with that many threads.. If you're encoding at sub-HD resolutions on a dual core, you'll run into that kind of problem. Unless you actually have more than 2 cores I'd advise against using that many threads.

[check]

No, x264 should still be deterministic with multiple threads. It is only not when you set --non-deterministic.

[MasterNobody]

As check rightly said it must be deterministic indifferently how much threads it use if not using --non-deterministic option. If you add --non-deterministic to my options all files will be different, but without it only some rare files are different (that is why I create 100 files) due to some bug (it is not proposed behavior surely).

[imcold]

I see... sorry, my bad.

[squid_80]

The matroska writer seems to leak small amounts of memory. I made some small changes to matroska.c:static void mk_destroyContexts(mk_Writer *w) {
mk_Context *cur, *next;

for (cur = w->freelist; cur; cur = next) {
next = cur->next;
free(cur->data);
free(cur);
}

for (cur = w->actlist; cur; cur = next) {
next = cur->next;
free(cur->data);
free(cur);
}

for (cur = w->frame; cur; cur = next) {
next = cur->next;
free(cur->data);
free(cur);
}

for (cur = w->root; cur; cur = next) {
next = cur->next;
free(cur->data);
free(cur);
}

w->freelist = w->actlist = w->root = w->frame = NULL;
} which seems to have fixed it. I didn't really spend much time on it though, should probably be checked more closely.

[kemuri-_9]

Hey, I updated to the newest rev of x264 (r886), and i'm coming across some problems when running it after compilation in VC9.

It constantly throws exceptions when trying to run it with asm optimizations.
However, when i turn off asm it runs just fine.
So has there been a regression in the asm code to be incompatible with VC? since the precompiled mingw one on the site still runs fine...

---

in the VC debugger it prints off
movaps xmm0,xmmword ptr [esi+ecx]
for
Unhandled exception at 0x004373a2 in x264.exe: 0xC0000005: Access violation reading location 0x00000000.

---
Running on an AMD Athlon 64 X2 4200+ (Manchester) on XP x64
detected ASM opts (when enabled) are MMX2 and SSE2Slow

[Dark Shikari]

So has there been a regression in the asm code to be incompatible with VC? Yes, SSE2 deblocking causes a crash with any compiler that doesn't correctly preserve stack alignment.

[kemuri-_9]

Well, thanks for that information, looks like I'll have to start getting familiar with mingw to compile x264....

[Underground78]

I think there is something strange with last builds :

E:\test>x264 --pass 1 --bitrate 500 --stats "rev899.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --threads auto --thread-input --progress --no-psnr --output NUL "1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (2271 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:22 Avg QP:12.66 size: 93186:00:00
x264 [info]: slice P:961 Avg QP:13.12 size: 74215
x264 [info]: slice B:1288 Avg QP:14.75 size: 35506
x264 [info]: mb I I16..4: 11.2% 0.0% 88.8%
x264 [info]: mb P I16..4: 17.5% 0.0% 0.0% P16..4: 81.8% 0.0% 0.0% 0.0% 0.0% skip: 0.7%
x264 [info]: mb B I16..4: 1.7% 0.0% 0.0% B16..8: 54.0% 0.0% 0.0% direct:40.6% skip: 3.7%
x264 [info]: final ratefactor: -1.#J
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: SSIM Mean Y:0.9921801
x264 [info]: kb/s:10489.0

encoded 2271 frames, 57.93 fps, 10489.13 kb/s

with revision 889 I have this for the same source :

E:\test>x264_889 --pass 1 --bitrate 500 --stats "rev889.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --threads auto --thread-input --progress --no-psnr --output NUL "1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (2271 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:22 Avg QP:32.91 size: 11528:00:00
x264 [info]: slice P:969 Avg QP:35.95 size: 3602
x264 [info]: slice B:1280 Avg QP:37.05 size: 830
x264 [info]: mb I I16..4: 52.0% 0.0% 48.0%
x264 [info]: mb P I16..4: 15.6% 0.0% 0.0% P16..4: 44.5% 0.0% 0.0% 0.0% 0.0% skip:39.9%
x264 [info]: mb B I16..4: 0.6% 0.0% 0.0% B16..8: 16.1% 0.0% 0.0% direct: 3.4% skip:79.9%
x264 [info]: final ratefactor: 31.72
x264 [info]: direct mvs spatial:86.6% temporal:13.4%
x264 [info]: SSIM Mean Y:0.8997162
x264 [info]: kb/s:423.3

encoded 2271 frames, 89.06 fps, 423.40 kb/s

Both builds are from x264.nl ... :scared:

[Dark Shikari]

:confused:

If you disable AQ, does the problem still occur? Does the problem occur with unpatched builds?

[Underground78]

:confused:

If you disable AQ, does the problem still occur?

Yes ...

Does the problem occur with unpatched builds?

Yes, tests were made with unpatched builds ...

[Dark Shikari]

Tested, works just fine here.x264 [info]: final ratefactor: -1.#JLooks like something is generating a floating point exception in ratecontrol. That would definitely cause the problem...

... any chance you could post an output stream, and try running it with --no-asm?

[Underground78]

Hum I will test with --no-asm, but output stream may be a little too big because of high bitrate ... I will test with a smaller sample.

If it helps, I could say that the bug appear in one of this revisions :

commit 16b8f79bb6825053b6dd0eebb1d24c1bdf112fbb r895
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Wed Jul 2 10:43:57 2008 -0600

Fix bug in adaptive quantization
In some cases adaptive quantization did not correctly calculate the variance.
Bug reported by MasterNobody

commit 3440cf193fc13e558d2c6b98024d59e95a7b2774 r894
Author: Loren Merritt <pengvado@akuvian.org>
Date: Sun Jun 29 00:00:03 2008 -0600

lowres_init asm
rounding is changed for asm convenience. this makes the c version slower, but there's no way around that if all the implementations are to have the same results.

commit 1c8f807054a0308482d53d4c58ba1d5f5d2ae263 r893
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Tue Jul 1 23:42:39 2008 -0600

Optimizations and cosmetics in macroblock.c
If an i4x4 dct block has no coefficients, don't bother with dequant/zigzag/idct. Not useful for larger sizes because the odds of an empty block are much lower.
Cosmetics in i16x16 to be more consistent with other similar functions.
Add an SSD threshold for chroma in probe_skip to improve speed and minimize time spent on chroma skip analysis.
Rename lambda arrays to lambda_tab for consistency.

[Underground78]

Ok, here a test with a smaller sample (note that with a 500 frames sample, the bug doesn't seem to appear) :

E:\film>x264 --pass 1 --bitrate 500 --stats "asm.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --threads auto --thread-input --progress --no-psnr --output "asm.264" "1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:12 Avg QP:12.66 size: 74475:00:00
x264 [info]: slice P:542 Avg QP:12.75 size: 60999
x264 [info]: slice B:447 Avg QP:14.26 size: 26072
x264 [info]: mb I I16..4: 15.1% 0.0% 84.9%
x264 [info]: mb P I16..4: 27.6% 0.0% 0.0% P16..4: 65.7% 0.0% 0.0% 0.0% 0.0% skip: 6.6%
x264 [info]: mb B I16..4: 3.8% 0.0% 0.0% B16..8: 43.2% 0.0% 0.0% direct:28.8% skip:24.2%
x264 [info]: final ratefactor: -1.#J
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: SSIM Mean Y:0.9930855
x264 [info]: kb/s:9112.7

encoded 1001 frames, 60.26 fps, 9112.89 kb/s

I've uploaded asm.264 (http://www.mediafire.com/?1lkjyymsnef) and asm.stats (http://www.mediafire.com/?uz141xyxtyi) ...

Without asm, the bug seems to disappear :

E:\film>x264 --pass 1 --bitrate 500 --stats "no-asm.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --no-asm --threads auto --thread-input --progress --no-psnr --output "no-asm.264" "1x01-p1.avs"

avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: none!
x264 [info]: slice I:12 Avg QP:30.99 size: 11819:00:00
x264 [info]: slice P:542 Avg QP:33.32 size: 4207
x264 [info]: slice B:447 Avg QP:35.89 size: 861
x264 [info]: mb I I16..4: 47.3% 0.0% 52.7%
x264 [info]: mb P I16..4: 23.5% 0.0% 0.0% P16..4: 36.7% 0.0% 0.0% 0.0% 0.0% skip:39.8%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 15.4% 0.0% 0.0% direct: 2.9% skip:80.5%
x264 [info]: final ratefactor: 31.95
x264 [info]: direct mvs spatial:94.6% temporal:5.4%
x264 [info]: SSIM Mean Y:0.9236085
x264 [info]: kb/s:560.7

encoded 1001 frames, 29.47 fps, 560.97 kb/s

[Dark Shikari]

I'm going to take a wild guess and say that the problem is the lowres_asm, and that when it runs using the MMX version, the FPU isn't re-initialized correctly afterwards (because we never had any MMX code this early in the program before).

The problem is that I can't duplicate it here even when disabling SSE assembly (and using only MMX).

[Underground78]

If you want me to do some tests, I would be happy to help ...

[Dark Shikari]

Sure, test time.

Download these builds (http://www.mediafire.com/?l1fbtgimwmx).

1. Test x264_old.exe. Does it exhibit the bug? If it doesn't, stop.
2. If it does exhibit the bug, test x264_new.exe. Does it exhibit the bug?

[squid_80]

The problem is that I can't duplicate it here even when disabling SSE assembly (and using only MMX).
Perhaps your machine is using SSE2 for floating point operations and doesn't give a crap about the FPU state?

[Dark Shikari]

Perhaps your machine is using SSE2 for floating point operations and doesn't give a crap about the FPU state?Nope, it won't do that unless you compile with a -march that allows SSE.

[jeffy]

x264 [info]: using cpu capabilities: MMX2 SSE2Slow

@Dark Shikari: could the error be originating from SSE2Slow?

I downloaded the file from the Mediafire and used the following script:
AVCSource("asm.dga")

C:\Program Files\megui\tools\x264>x264 --version
x264 0.60.895M 16b8f79

C:\Program Files\megui\tools\x264>x264 --pass 1 --bitrate 500 --stats "no-asm.s
ats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1 --analyse no
e --me dia --no-asm --threads 2 --thread-input --progress --no-psnr --output "n
-asm.264" "c.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: none!
x264 [info]: slice I:12 Avg QP:30.86 size: 11873:00:00
x264 [info]: slice P:538 Avg QP:33.20 size: 4229
x264 [info]: slice B:451 Avg QP:35.21 size: 861
x264 [info]: mb I I16..4: 47.0% 0.0% 53.0%
x264 [info]: mb P I16..4: 23.8% 0.0% 0.0% P16..4: 37.1% 0.0% 0.0% 0.0%
.0% skip:39.0%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 15.4% 0.0% 0.0% direct
2.9% skip:80.5%
x264 [info]: final ratefactor: 31.87
x264 [info]: direct mvs spatial:95.1% temporal:4.9%
x264 [info]: SSIM Mean Y:0.9258877
x264 [info]: kb/s:560.6

encoded 1001 frames, 28.88 fps, 560.80 kb/s

C:\Program Files\megui\tools\x264>x264 --pass 1 --bitrate 500 --stats "asm.stat
" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1 --analyse none
-me dia --threads 2 --thread-input --progress --no-psnr --output "asm.264" "c.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 PHADD SSE4 Cache64
x264 [info]: slice I:12 Avg QP:30.86 size: 11873:00:00
x264 [info]: slice P:538 Avg QP:33.20 size: 4229
x264 [info]: slice B:451 Avg QP:35.21 size: 861
x264 [info]: mb I I16..4: 47.0% 0.0% 53.0%
x264 [info]: mb P I16..4: 23.8% 0.0% 0.0% P16..4: 37.1% 0.0% 0.0% 0.0%
.0% skip:39.0%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 15.4% 0.0% 0.0% direct
2.9% skip:80.5%
x264 [info]: final ratefactor: 31.87
x264 [info]: direct mvs spatial:95.1% temporal:4.9%
x264 [info]: SSIM Mean Y:0.9258878
x264 [info]: kb/s:560.6

encoded 1001 frames, 78.03 fps, 560.80 kb/s

[Underground78]

Sure, test time.

Download these builds (http://www.mediafire.com/?l1fbtgimwmx).

1. Test x264_old.exe. Does it exhibit the bug? If it doesn't, stop.
2. If it does exhibit the bug, test x264_new.exe. Does it exhibit the bug?

x264_old.exe doesn't seem to exhibit the bug :

E:\film>x264_old --pass 1 --bitrate 500 --stats "x264_old.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --no-asm --threads auto --thread-input --progress --no-psnr --output "x264_old.264" "1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: none!
x264 [info]: slice I:10 Avg QP:30.26 size: 11348:00:00
x264 [info]: slice P:543 Avg QP:33.20 size: 4243
x264 [info]: slice B:448 Avg QP:35.50 size: 866
x264 [info]: mb I I16..4: 50.2% 0.0% 49.8%
x264 [info]: mb P I16..4: 23.6% 0.0% 0.0% P16..4: 37.0% 0.0% 0.0% 0.0% 0.0% skip:39.4%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 15.2% 0.0% 0.0% direct: 3.0% skip:80.6%
x264 [info]: final ratefactor: 31.89
x264 [info]: direct mvs spatial:94.6% temporal:5.4%
x264 [info]: SSIM Mean Y:0.9242392
x264 [info]: kb/s:560.5

encoded 1001 frames, 16.00 fps, 560.69 kb/s

[jeffy]

x264_old.exe doesn't seem to exhibit the bug :

E:\film>x264_old --pass 1 --bitrate 500 --stats "x264_old.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --no-asm --threads auto --thread-input --progress --no-psnr --output "x264_old.264" "1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: none!
x264 [info]: slice I:10 Avg QP:30.26 size: 11348:00:00
x264 [info]: slice P:543 Avg QP:33.20 size: 4243
x264 [info]: slice B:448 Avg QP:35.50 size: 866
x264 [info]: mb I I16..4: 50.2% 0.0% 49.8%
x264 [info]: mb P I16..4: 23.6% 0.0% 0.0% P16..4: 37.0% 0.0% 0.0% 0.0% 0.0% skip:39.4%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 15.2% 0.0% 0.0% direct: 3.0% skip:80.6%
x264 [info]: final ratefactor: 31.89
x264 [info]: direct mvs spatial:94.6% temporal:5.4%
x264 [info]: SSIM Mean Y:0.9242392
x264 [info]: kb/s:560.5

encoded 1001 frames, 16.00 fps, 560.69 kb/s

No wonder...

[Underground78]

Arg, my bad ! I will redo the tests ... :eek:

Edit : Hum, finally it doesn't seem to change anything, the bug doesn't seem to appear with x264_old.exe :

E:\film>x264_old --pass 1 --bitrate 500 --stats "x264_old.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --threads auto --thread-input --progress --no-psnr --output "x264_old.264" "1x01-p1.avs"

avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:10 Avg QP:30.81 size: 11034:00:00
x264 [info]: slice P:544 Avg QP:33.20 size: 4240
x264 [info]: slice B:447 Avg QP:35.72 size: 865
x264 [info]: mb I I16..4: 50.9% 0.0% 49.1%
x264 [info]: mb P I16..4: 23.5% 0.0% 0.0% P16..4: 37.0% 0.0% 0.0% 0.0% 0.0% skip:39.5%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 15.2% 0.0% 0.0% direct: 3.0% skip:80.6%
x264 [info]: final ratefactor: 31.89
x264 [info]: direct mvs spatial:94.9% temporal:5.1%
x264 [info]: SSIM Mean Y:0.9241641
x264 [info]: kb/s:560.2

encoded 1001 frames, 48.16 fps, 560.40 kb/s

[Dark Shikari]

Both x264_new and x264_old are my latest dev builds (one with an emms after the frame_init_lowres).

Since you don't get any problems with x264_old, there's a few possibilities:

1. Jarod's compiler sucks.
2. It relates to threads--my build doesn't have threads. Try disabling threads on jarod's builds and see if the problem goes away.

[Underground78]

2. It relates to threads--my build doesn't have threads. Try disabling threads on jarod's builds and see if the problem goes away.

Yes, it does disappear with --threads 1 ...

[Dark Shikari]

Yes, it does disappear with --threads 1 ...Try adding --asm SSE2 to the commandline on a build/commandline which otherwise breaks. Does the problem still occur?

[Underground78]

It seems that the bug doesn't occur if I add --asm SSE2 to the command line ...

E:\film>x264 --pass 1 --bitrate 500 --stats "threads-auto-asm-SSE2.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --asm SSE2 --threads auto --thread-input --progress --no-psnr --no-ssim --output "threads-auto-asm-SSE2.mkv" "1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2
x264 [info]: slice I:12 Avg QP:30.99 size: 11820:00:00
x264 [info]: slice P:542 Avg QP:33.31 size: 4208
x264 [info]: slice B:447 Avg QP:35.87 size: 861
x264 [info]: mb I I16..4: 47.3% 0.0% 52.7%
x264 [info]: mb P I16..4: 23.5% 0.0% 0.0% P16..4: 36.7% 0.0% 0.0% 0.0% 0.0% skip:39.8%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 15.5% 0.0% 0.0% direct: 2.9% skip:80.5%
x264 [info]: final ratefactor: 31.94
x264 [info]: direct mvs spatial:94.9% temporal:5.1%
x264 [info]: kb/s:560.9

encoded 1001 frames, 77.55 fps, 561.11 kb/s

[Dark Shikari]

Ding ding ding, we have a winner!

I'm going to guess its related to how frame_init_lowres interacts with ratecontrol in threaded mode.

If this is true, then the following changes will both solve the problem:

1. Disable frame_init_lowres asm (but don't disable anything else).

2. Add x264_emms() after the call to frame_init_lowres asm.

My build environment doesn't support threads, so I'll have to find someone to make you a few builds to test.

[Underground78]

My build environment doesn't support threads, so I'll have to find someone to make you a few builds to test.

I can do a build with threads support if you give me a patch to apply on GIT source code ...

[Dark Shikari]

I can do a build with threads support if you give me a patch to apply on GIT source code ...For idea 2 above, find the following code in encoder/encoder.c:

if( h->frames.b_have_lowres )
x264_frame_init_lowres( h, fenc );

Add, after it (on the next line) x264_emms();

For idea 1 above, find the following code in common/x86/mc-c.c:
pf->frame_init_lowres_core = x264_frame_init_lowres_core_mmxext;
pf->frame_init_lowres_core = x264_frame_init_lowres_core_cache32_mmxext;
pf->frame_init_lowres_core = x264_frame_init_lowres_core_cache32_mmxext;

Comment these out or remove them.

Test with no modifications, with just idea 1, and with just idea 2, and see if any of them resolve the issue.

[J_Darnley]

Here you go. 7-zip archive contains two builds with threads of the two ideas.
http://users.telenet.be/darnley/x264-lowres-ideas.7z

Dark_Shikari, you posted two identical lines. Is that correct? It does appear twice in mc-c.c for cacheline 32 and 64.

[Dark Shikari]

Here you go. 7-zip archive contains two builds with threads of the two ideas.
http://users.telenet.be/darnley/x264-lowres-ideas.7z

Dark_Shikari, you posted two identical lines. Is that correct? It does appear twice in mc-c.c for cacheline 32 and 64.Yes, that was correct.

It needs to be three builds, so that a comparison can be made with a normal build to see if that one is broken too.

[J_Darnley]

Ah, ok. I'll re-upload the archive. But I can say that for a first pass target of 500 the two ideas now give 515 instead of ~20000.
[EDIT] Three build archive uploaded.

[Underground78]

Sorry J_Darnley I've already made my test builds when you've posted but I was answering a phone call ... :o

Test builds gcc 3.4.5 fprofiled : Test builds (http://www.mediafire.com/?1njdjy1ti2y) ...

Default build :

E:\film>x264-default.exe --pass 1 --bitrate 500 --stats "default.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "default.mkv" "1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:12 Avg QP:12.66 size: 74475:00:00
x264 [info]: slice P:542 Avg QP:12.75 size: 60999
x264 [info]: slice B:447 Avg QP:14.26 size: 26072
x264 [info]: mb I I16..4: 15.1% 0.0% 84.9%
x264 [info]: mb P I16..4: 27.6% 0.0% 0.0% P16..4: 65.7% 0.0% 0.0% 0.0% 0.0% skip: 6.6%
x264 [info]: mb B I16..4: 3.8% 0.0% 0.0% B16..8: 43.2% 0.0% 0.0% direct:28.8% skip:24.2%
x264 [info]: final ratefactor: -1.#J
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: kb/s:9112.7

encoded 1001 frames, 58.29 fps, 9112.89 kb/s

Idea 1 :

E:\film>x264-idea-1.exe --pass 1 --bitrate 500 --stats "idea-1.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "idea-1.mkv" "1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:12 Avg QP:30.99 size: 11820:00:00
x264 [info]: slice P:542 Avg QP:33.31 size: 4208
x264 [info]: slice B:447 Avg QP:35.87 size: 861
x264 [info]: mb I I16..4: 47.3% 0.0% 52.7%
x264 [info]: mb P I16..4: 23.5% 0.0% 0.0% P16..4: 36.7% 0.0% 0.0% 0.0% 0.0% skip:39.8%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 15.5% 0.0% 0.0% direct: 2.9% skip:80.5%
x264 [info]: final ratefactor: 31.94
x264 [info]: direct mvs spatial:94.9% temporal:5.1%
x264 [info]: kb/s:560.9

encoded 1001 frames, 87.76 fps, 561.11 kb/s

Idea 2 :

E:\film>x264-idea-2.exe --pass 1 --bitrate 500 --stats "idea-2.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "idea-2.mkv" "
1x01-p1.avs"
avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:12 Avg QP:30.99 size: 11820:00:00
x264 [info]: slice P:542 Avg QP:33.31 size: 4208
x264 [info]: slice B:447 Avg QP:35.87 size: 861
x264 [info]: mb I I16..4: 47.3% 0.0% 52.7%
x264 [info]: mb P I16..4: 23.5% 0.0% 0.0% P16..4: 36.7% 0.0% 0.0% 0.0% 0
.0% skip:39.8%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 15.5% 0.0% 0.0% direct:
2.9% skip:80.5%
x264 [info]: final ratefactor: 31.94
x264 [info]: direct mvs spatial:94.9% temporal:5.1%
x264 [info]: kb/s:560.9

encoded 1001 frames, 90.10 fps, 561.11 kb/s

Both ideas 1 and 2 seem to work to fix the bug ...

[Dark Shikari]

Hopefully resolved (http://git.videolan.org/?p=x264.git;a=commit;h=a9af9425820cfba99ae4b378c33c4fee4e99b2ce).

[Underground78]

It works :

E:\film>x264-fixed --pass 1 --bitrate 500 --stats "fixed.stats" --bframes 16 --b-pyramid --direct auto --filter 0:0 --subme 1
--analyse none --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "fixed.mkv" "1x01-p1.avs"

avis [info]: 704x528 @ 25.00 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:12 Avg QP:30.99 size: 11820:00:00
x264 [info]: slice P:542 Avg QP:33.31 size: 4208
x264 [info]: slice B:447 Avg QP:35.87 size: 861
x264 [info]: mb I I16..4: 47.3% 0.0% 52.7%
x264 [info]: mb P I16..4: 23.5% 0.0% 0.0% P16..4: 36.7% 0.0% 0.0% 0.0% 0.0% skip:39.8%
x264 [info]: mb B I16..4: 1.2% 0.0% 0.0% B16..8: 15.5% 0.0% 0.0% direct: 2.9% skip:80.5%
x264 [info]: final ratefactor: 31.94
x264 [info]: direct mvs spatial:94.9% temporal:5.1%
x264 [info]: kb/s:560.9

encoded 1001 frames, 91.65 fps, 561.11 kb/s

Thank you very much ! :)

[garbii]

I had to reverted to a x264 version from 2008 04 08 ... The one I was using right now was from 2008:12:30. The difference is ubntu jaunty vs ubuntu intrepid :P


Anyway new x264 has a worse CRF mode... although crf 22 gave me the old crf 20 quality, the size is actually larger ...
The settings for both encodes are the same with a difference that with the new one I removed bime and brdo from command line and instead use subme 7. (which is due to x264 api changes)

Old crf=20
minami-ke 08 size 42 MB
gundam 00 s2 20 size 80 MB

new crf=22
minami-ke 08 size 56 MB
gundam 00 s2 20 size 84 MB

Munto 05
old = 54 mb
new=70 mb

Now the difference on the same files shows that new crf mode is less efficient then the old one... So I consider this a bug since new version provides the same quality but with a lot larger files .