x264 development

[nurbs]

With x264 r1330 32-bit from x264.nl I get lots of warnings when I try to encode anything. My cpu is an Atlon64 X2.
D:\Test>"C:\Programme\megui\tools\x264\x264.exe" -o "D:\Test\e7_error.mp4" "D:\Test\e7.avs"
avis [info]: 1280x720 @ 23.98 fps (1842 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.1
mp4 [info]: initial delay 1001 (scale 24000)
x264 [warning]: internal error (MV out of thread range)51
mb type: 17
mv: l0r0 (0,23374)
limit: 480
mb_xy: 36,15
completed: 600
x264 [warning]: recovering by using intra mode
x264 [warning]: internal error (MV out of thread range)28
mb type: 17
mv: l0r0 (0,23374)
limit: 480
mb_xy: 73,0
completed: 376
x264 [warning]: recovering by using intra mode
x264 [warning]: internal error (MV out of thread range):34
mb type: 17
mv: l0r0 (0,23374)
limit: 480
mb_xy: 30,0

edit:
with --threads 1 it works without warnings

edit2:
Seems like it doesn't work. There are no warnings or errors during encoding, but the clips show artifacts during playback. I tried current builds of MPC-HC (with DXVA) and ffdshow, so either non of them can correctly decode the clips or something went wrong during encoding. I posted a small sample on megaupload in case anyone wants to take a look. It's most noticeable at the end of the clip. http://www.megaupload.com/?d=28H1OHGH

@juGGaKNot:
I also get crashes like that. I think it's either --subme 10, --trellis 2 or --me tesa. I tried another clip with everything the same except --subme 9, --trellis 1 and --me umh and that worked. Haven't had the time to narrow it down.

[juGGaKNot]

I also get crashes like that. I think it's either --subme 10, --trellis 2 or --me tesa. I tried another clip with everything the same except --subme 9, --trellis 1 and --me umh and that worked. Haven't had the time to narrow it down.

subme 9 = crash with cmd :

encoded 1800 frames, 11.73 fps, 4220.12 kb/s
avis [info]: 1184x666 @ 30.00 fps (1800 frames)
x264 [warning]: b-pyramid + mb-tree is not supported
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.2
x264 [warning]: internal error (MV out of thread range):49
mb type: 17
mv: l0r0 (0,23374)
limit: 416
mb_xy: 2,21
completed: 632
x264 [warning]: recovering by using intra mode
[2.1%] 37/1800 frames, 2.08 fps, 4692.07 kb/s, eta 0:14:06

subme 10 just crash

subme 9 and trellis 0 crash

[MatLz]

No crashes for me but huge flickerings and wild macroblocks. But I experience same artifacts without weighted p, so it's maybe an other problem?

[jmartinr]

I've got displaced macroblocks as well with this:

"C:\Program Files\x264\x264.exe" "%%~fP" --pass 1 --preset veryslow --keyint %keyint% --bitrate %bitrate% --threads auto --thread-input --sar %sar% --stats "%%~dpnP.x264.stats" --output NUL

"C:\Program Files\x264\x264.exe" "%%~fP" --pass 2 --preset veryslow --keyint %keyint% --bitrate %bitrate% --threads auto --thread-input --sar %sar% --stats "%%~dpnP.x264.stats" --output "%%~dpnP.%x264cont%"

That's a quite ordinary commandline, I guess.

[thewebchat]

If you decode with CoreAVC, you will get very "interesting" results. I'm pretty sure this has been mentioned in the CoreAVC thread and on the page before.

[Forteen88]

Which h264-decoder works with weightp? CoreAVC 2.0 will fix it.

EDIT: @tph, Ok, thanks for the info

[tph]

Which h264-decoder works with weightp? CoreAVC 2.0 will fix it.
libavcodec

[MatLz]

Is there a place to get intermediary revisions?
X264.nl jumps since 1319 directly to 1330...

[Terranigma]

No crashes for me but huge flickerings and wild macroblocks. But I experience same artifacts without weighted p, so it's maybe an other problem?

Same here but only WITH weighted-p enabled, and guys, don't try to blame it on CoreAVC as i'm using the latest version of mpc-hc with ffdshow set as the decoder via libavcodec.

[juGGaKNot]

Patched build works fine ( rack 4.3.4, x264_win_zone_parse_fix_06.diff ), old mpc-hc with divx h264 decoder plays k

unpatched crashes

[Dark Shikari]

Can we all just agree to stop using GCC 4 and all the problems will be solved?

[nurbs]

According to x264.nl their 32-bit builds are compiled with gcc 3.4.6 and that's the build I'm having problems with.

[juGGaKNot]

Can we all just agree to stop using GCC 4 and all the problems will be solved?

x264.nl one causes the problems, rack's 4..... works

[Dark Shikari]

According to x264.nl their 32-bit builds are compiled with gcc 3.4.6 and that's the build I'm having problems with.I'm having no issues with 3.4 builds.

[Terranigma]

According to x264.nl their 32-bit builds are compiled with gcc 3.4.6 and that's the build I'm having problems with.

That's what i've used too.

[juGGaKNot]

http://mirror01.x264.nl/x264/revision1330/x264.exe

x264.exe --preset veryslow --level 3.2 --ref 5 --min-keyint 30 --keyint 300 --bframes 3 --b-pyramid normal --merange 32 --sar 1:1 --aud

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/th_1330error.png (http://s286.photobucket.com/albums/ll105/juGGaKNot4cs/?action=view&current=1330error.png)

gcc.exe (GCC) 4.3.4 (x86.core2.Komisar) :

avis [info]: 1184x666 @ 30.00 fps (1800 frames)
x264 [warning]: b-pyramid + mb-tree is not supported
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 3.2
x264 [info]: frame I:28 Avg QP:20.55 size: 72473
x264 [info]: frame P:770 Avg QP:24.87 size: 24371
x264 [info]: frame B:1002 Avg QP:28.20 size: 10837
x264 [info]: consecutive B-frames: 9.9% 32.5% 34.5% 23.0%
x264 [info]: mb I I16..4: 24.4% 0.0% 75.6%
x264 [info]: mb P I16..4: 34.7% 0.0% 0.0% P16..4: 43.3% 0.0% 0.0% 0.0% 0
.0% skip:22.0%
x264 [info]: mb B I16..4: 9.5% 0.0% 0.0% B16..8: 25.3% 0.0% 0.0% direct:
12.3% skip:52.9% L0:38.5% L1:43.7% BI:17.8%
x264 [info]: final ratefactor: 22.40
x264 [info]: direct mvs spatial:97.6% temporal:2.4%
x264 [info]: coded y,uvDC,uvAC intra: 56.2% 41.1% 11.1% inter: 23.5% 9.7% 0.6%
x264 [info]: i16 v,h,dc,p: 28% 27% 23% 23%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 24% 13% 6% 8% 6% 11% 7% 8%
x264 [info]: Weighted P-Frames: Y:10.4%
x264 [info]: kb/s:4220.44

encoded 1800 frames, 10.46 fps, 4220.44 kb/s
avis [info]: 1184x666 @ 30.00 fps (1800 frames)
x264 [warning]: b-pyramid + mb-tree is not supported
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 3.2
x264 [info]: frame I:28 Avg QP:21.71 size: 69265
x264 [info]: frame P:770 Avg QP:25.87 size: 23682
x264 [info]: frame B:1002 Avg QP:29.12 size: 12046
x264 [info]: consecutive B-frames: 9.9% 32.5% 34.5% 23.0%
x264 [info]: mb I I16..4: 12.9% 76.1% 11.0%
x264 [info]: mb P I16..4: 4.8% 21.1% 2.0% P16..4: 33.0% 10.7% 7.3% 0.2% 0
.2% skip:20.7%
x264 [info]: mb B I16..4: 0.7% 4.3% 0.6% B16..8: 34.7% 2.5% 2.6% direct:
9.7% skip:44.9% L0:50.5% L1:42.3% BI: 7.1%
x264 [info]: 8x8 transform intra:75.8% inter:83.5%
x264 [info]: direct mvs spatial:88.1% temporal:11.9%
x264 [info]: coded y,uvDC,uvAC intra: 70.1% 51.7% 15.0% inter: 27.9% 12.5% 1.1%
x264 [info]: i16 v,h,dc,p: 37% 17% 4% 41%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 11% 4% 8% 13% 11% 17% 10% 15%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 9% 4% 7% 16% 12% 18% 9% 14%
x264 [info]: Weighted P-Frames: Y:10.1%
x264 [info]: ref P L0: 50.9% 12.2% 18.4% 6.9% 5.6% 5.3% 0.6%
x264 [info]: ref B L0: 73.1% 12.6% 8.7% 5.6%
x264 [info]: kb/s:4299.33

encoded 1800 frames, 1.16 fps, 4299.33 kb/s
AVC-H264 import - frame size 1184 x 666 at 30.000 FPS
Import results: 1800 samples - Slices: 28 I 770 P 1002 B - 1 SEI - 21 IDR
IsoMedia import - track ID 1 - Audio (SR 44100 - 2 channels)
Saving C:\x264\Movie_2D\1.Movie_X264_2D.mp4: 0.500 secs Interleaving

X264 Encoding started at 06:46 PM and finished at 07:15 PM

Overall Encoding started at 06:46 PM and finished at 07:15 PM

[VFR maniac]

Rev1330 I compiled with 3.4.5 and 4.4.2 are bit identical, while x264.nl build (3.4.6) is difference from them.
I doubt that x264.nl has some problems.

[dvy]

bug ,bug ,bug ,r1330 have huge flickerings and wild blocks and huge artifacts .I very sure it is source code problem,not compiler problem.expert fixing as soon as possible.

[Dark Shikari]

Rev1330 I compile with 3.4.5 and 4.4.2 are bit identical, while x264.nl build (3.4.6) is difference from them.
I doubt that x264.nl has problems.If your two are bit-identical and x264.nl's is different, I suspect x264.nl has problems.

[Dark Shikari]

We can probably check whether a GCC is working or not via md5sum output.

crew_4cif.y4m (http://media.xiph.org/video/derf/y4m/crew_4cif.y4m)

x264 crew_4cif.y4m --threads 1 -o - | md5sum

c304074d579ff23d4e6b1dbe17d04528

(Note: using the latest revision that I just committed one minute ago.)

[dvy]

If your two are bit-identical and x264.nl's is different, I suspect x264.nl has problems.

I use git to pull r1330 source code,compile vc++ and gcc, encode three clip,all of encoded clip have problem.it must be source code problem.

[Dark Shikari]

I use git to pull r1330 source code,compile vc++ and gcc, encode three clip,all of encoded clip have problem.it must be source code problem.I have no issues here. Can you post a commandline or something else that I can replicate with?

Furthermore, are you on win32 or win64? I can't try to fix issues when nobody is giving me any useful information.

[dvy]

I have no issues here. Can you post a commandline or something else that I can replicate with?

Furthermore, are you on win32 or win64? I can't try to fix issues when nobody is giving me any useful information.

I use r1330 x264 win32 platform,x264 commandline:

pass 1:
x264.exe" --profile high --level 4.1 --preset slower --pass 1 --bitrate 4000 --stats "H:\Entertainment\Convert\ManU VS FC Seoul.stats" --thread-input --threads 1 --deblock -2:-2 --no-cabac --bframes 3 --b-adapt 2 --direct auto --b-bias 0 --scenecut 40 --ref 8 --deadzone-inter 17 --deadzone-intra 8 --rc-lookahead 80 --aq-mode 2 --aq-strength 0.7 --merange 16 --me umh --subme 9 --partitions all --trellis 0 --psy-rd 1.0:0 --no-fast-pskip --output NUL "H:\Entertainment\Convert\ManU VS FC Seoul.avs"

pass 2:
x264.exe" --profile high --level 4.1 --preset slower --pass 2 --bitrate 4000 --stats "H:\Entertainment\Convert\ManU VS FC Seoul.stats" --thread-input --threads 1 --deblock -2:-2 --no-cabac --bframes 3 --b-adapt 2 --direct auto --b-bias 0 --scenecut 40 --ref 8 --deadzone-inter 17 --deadzone-intra 8 --rc-lookahead 80 --aq-mode 2 --aq-strength 0.7 --merange 16 --me umh --subme 9 --partitions all --trellis 0 --psy-rd 1.0:0 --no-fast-pskip --aud --output "H:\Entertainment\Convert\ManU VS FC Seoul.264" "H:\Entertainment\Convert\ManU VS FC Seoul.avs"

before r1330 ,everything is OK,at today I pull r1330 ,problem appear.I compile r1330 in VS2008 and cygwin gcc 3.4,both have problem .

[Dark Shikari]

I can't replicate anything without a source sample either. Anyways, I've found one bug (looking for a fix atm...), so hopefully this might be the problem.

[dvy]

I can't replicate anything without a source sample either. Anyways, I've found one bug (looking for a fix atm...), so hopefully this might be the problem.

Need not replicate ,very huge flickerings and blocks and artifacts is absolutly true.it must be source code bug.expect fixing,x264 is very very good stuff.

[wyti]

When you're searching a bug, you need to be able to replicate the issue to spot WHERE it goes wrong, only knowing it fails somewhere don't help fixing it.

@DS don't know if it's too late but tested rev 1331 compiled with gcc 4.4.2 for win64 (core I7) and got the same md5sum than yours

[dvy]

When you're searching a bug, you need to be able to replicate the issue to spot WHERE it goes wrong, only knowing it fails somewhere don't help fixing it.


problem is commit between 2009-10-30 and today,before is OK.

[Terranigma]

problem is commit between 2009-10-30 and today,before is OK.

I gave Shikari a sample encode with the bug and my source input, and gave him the settings used to encode and he couldn't replicate the problem, so i'm thinking it could just be the builds (32-bit at least) at x264.nl

[kemuri-_9]

We can probably check whether a GCC is working or not via md5sum output.

crew_4cif.y4m (http://media.xiph.org/video/derf/y4m/crew_4cif.y4m)

x264 crew_4cif.y4m --threads 1 -o - | md5sum

c304074d579ff23d4e6b1dbe17d04528

(Note: using the latest revision that I just committed one minute ago.)

x264.nl's r1331 binary produces with the above commandline an md5 of

6430be78659b75068f19573fd3bad90f

which would indeed point to it being broken.

[Dark Shikari]

Here is my x264 build of r1331. (http://mirror05.x264.nl/Dark/force.php?file=./x264.exe)

If you find any problems with it, tell me.

[Dark Shikari]

OK, I am going insane. I've compiled with both gcc 3.4.4 and gcc 4.3.2 locally and I have been unable to replicate any bugs reported by anyone here.

What the hell is going on? :/

Edit: Linux x86_64 gcc 4.1.2 works.

[juGGaKNot]

Here is my x264 build of r1331. (http://mirror05.x264.nl/Dark/force.php?file=./x264.exe)

If you find any problems with it, tell me.

Works.

[kemuri-_9]

mingw 4.4.2, both x86 and x64 matched the md5 here.

Edit:
mingw 4.3.4 (official, not the prerelease variety), both x86 and x64 matched.

[MatLz]

Yes it works.
Don't know if it will help you to understand the bugs but I noticed the artifacts exponentially increased when I decreased motion estimation...like:
Tesa subme9 little flickering, not many wild macroblocks
Umh subme7 huge flickering lot of wild macroblocks
Dia subme2....hum...I thought the video could jump out of my screen...!

[dvy]

Here is my x264 build of r1331. (http://mirror05.x264.nl/Dark/force.php?file=./x264.exe)

If you find any problems with it, tell me.



Dark Shikari, I test your build ,your build and my build have same problem,screenshot below:it must be source code bug,and the bug must be commit between 2009-10-30 and today.

[Dark Shikari]

Dark Shikari, I test your build ,your build and my build have same problem,screenshot below:it must be source code bug,and the bug must be commit between 2009-10-30 and today.I need a source sample to replicate the problem.

[jmartinr]

Here is my x264 build of r1331. (http://mirror05.x264.nl/Dark/force.php?file=./x264.exe)

If you find any problems with it, tell me.

Works. Previous problems happened with x264.nl 1330 build.

[IgorC]

I need a source sample to replicate the problem.
Edited: There is no bug on foreman sample with your build but it is here with x264.nl's build (2pass)

x264.exe --slow-firstpass --aq-mode 2 --rc-lookahead 60 --mbtree --threads 5 --pass 1 --stats "cx264_stat.log" --qcomp 0.6 --bframes 3 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 5 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 380 --no-fast-pskip --me umh --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t.mp4 1.avs --psnr --ssim

x264.exe --aq-mode 2 --mbtree --rc-lookahead 60 --threads 5 --pass 3 --stats "cx264_stat.log" --qcomp 0.6 --bframes 3 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 5 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 380 --no-fast-pskip --me umh --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t2.mp4 1.avs --psnr --ssim

pause

[VFR maniac]

We can probably check whether a GCC is working or not via md5sum output.

crew_4cif.y4m (http://media.xiph.org/video/derf/y4m/crew_4cif.y4m)

x264 crew_4cif.y4m --threads 1 -o - | md5sum

c304074d579ff23d4e6b1dbe17d04528

(Note: using the latest revision that I just committed one minute ago.)


OK. GCC 4.4.2 and 3.4.5 matches the md5.
x264.nl's doesn't match, and the md5 is
aa68827555eb4eab05de2d0c82bbaee7

[Dark Shikari]

It's bug on foreman sample (2pass)

x264.exe --slow-firstpass --aq-mode 2 --rc-lookahead 60 --mbtree --threads 5 --pass 1 --stats "cx264_stat.log" --qcomp 0.6 --bframes 3 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 5 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 380 --no-fast-pskip --me umh --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t.mp4 1.avs --psnr --ssim

x264.exe --aq-mode 2 --mbtree --rc-lookahead 60 --threads 5 --pass 3 --stats "cx264_stat.log" --qcomp 0.6 --bframes 3 --b-adapt 2 --weightb --subme 10 --keyint 300 --ref 5 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --bitrate 380 --no-fast-pskip --me umh --merange 16 --deblock 0:0 --psy-rd 0.2:0.0 -o t2.mp4 1.avs --psnr --ssim

pauseI can't replicate any issue here, unless I'm blind, using foreman CIF. JM agrees there's no problem (at least there's no decoder/encoder mismatch).

[kieranrk]

GCC 4.4.0 mingw:

$ x264 crew_4cif.y4m --threads 1 -o - | md5sum
yuv4mpeg: 704x576@60/1fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:4 Avg QP:24.19 size: 37151
x264 [info]: frame P:326 Avg QP:26.30 size: 12931
x264 [info]: frame B:270 Avg QP:27.92 size: 5425
x264 [info]: consecutive B-frames: 9.4% 90.6% 0.0% 0.0%
x264 [info]: mb I I16..4: 6.6% 72.7% 20.7%
x264 [info]: mb P I16..4: 1.0% 7.2% 1.5% P16..4: 47.4% 21.7% 11.6% 0.0% 0
.0% skip: 9.5%
x264 [info]: mb B I16..4: 0.7% 2.5% 0.8% B16..8: 54.1% 1.7% 2.6% direct:
7.1% skip:30.6% L0:36.3% L1:55.9% BI: 7.8%
x264 [info]: 8x8 transform intra:71.4% inter:71.3%
x264 [info]: coded y,uvDC,uvAC intra: 73.1% 75.0% 43.8% inter: 36.6% 40.7% 2.3%
x264 [info]: i16 v,h,dc,p: 54% 16% 4% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 11% 15% 6% 11% 12% 8% 9% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 29% 13% 14% 6% 10% 10% 7% 7% 5%
x264 [info]: Weighted P-Frames: Y:8.6%
x264 [info]: ref P L0: 55.8% 10.1% 28.7% 3.8% 1.5%
x264 [info]: ref B L0: 90.7% 9.3%
x264 [info]: kb/s:4663.00

encoded 600 frames, 9.95 fps, 4663.00 kb/s
d0d5486178c3fb782da5c0e51dbb7c95 *-

Same with --no-asm

[burfadel]

Well, I used the x264.exe 1331 from x264.nl, same problem with the flickering blocks as others have described.

Command line used is:
--keyint 400 --ref 5 --rc-lookahead 50 --nr 900 --bframes 5 --b-adapt 2 --b-pyramid normal --direct auto --subme 10 --trellis 2 --psy-rd 1:0.6 --partitions all --me umh --aq-mode 2

[Raere]

Well, I used the x264.exe 1331 from x264.nl, same problem with the flickering blocks as others have described.

Command line used is:
--keyint 400 --ref 5 --rc-lookahead 50 --nr 900 --bframes 5 --b-adapt 2 --b-pyramid normal --direct auto --subme 10 --trellis 2 --psy-rd 1:0.6 --partitions all --me umh --aq-mode 2

Same problem here - I used 3 different decoders, and all had the same flickering blocks (only about 3 in my 60 second clip)

[Dark Shikari]

It's already well-established that x264.nl's build is broken and jarod doesn't seem to feel like fixing it.

I still can't replicate anything.

[yuvi]

Everyone who is compiling x264 and getting wrong results: does http://pastebin.com/m52baaee5 not fix it?

Note that this is *not* a real solution, I'm just curious if there's anything going on other than emms reordering.

[Dark Shikari]

No problem with gcc 4.3.4 on Linux either.

[nurbs]

I noticed in the log that the value in the weighted p-frame line varies a lot with the number of threads. For instance I got 6.1% with one thread and 16.5% with three threads all other settings the same. I tried different sources and it seems to happen all the time.

edit: that is with the r1330 build from rack04 on 32-bit windows

[gizzin]

i got darks build, see if i can reproduce the flickering, I also got it on a earlier encode but didnt think much of it.

[Dark Shikari]

Confirmed: it's fprofiled that's broken (with Jarod's 3.4.6 build). Regular compilation still works fine.

[Xavius]

Confirmed: it's fprofiled that's broken (with Jarod's 3.4.6 build). Regular compilation still works fine.

Here is my x264 build of r1331. (http://mirror05.x264.nl/Dark/force.php?file=./x264.exe)

so, is this ok or not?