x264 development

[Dark Shikari]

so, is this ok or not?It should be; it isn't fprofiled. I was talking about jarod's build.

[wyti]

Strange, i got the same md5 checksum than yours, but i build my x264 (x64) fprofiled (and without gpac support but i don't know if it can do something)

[bob0r]

x264.nl users, redownload a fresh 'make' copy for now.
You might not even notice any speed difference! Let us know!

[Xavius]

Dark Shikari's x264 rev.1331 is about 672 kb
x264.nl version, rev.1331 is about 991 kb (I'm talking about the very latest, fixed, version)

same sources... more than 200 kb difference in size.
Why there is this difference?

[Dark Shikari]

Dark Shikari's x264 rev.1331 is about 672 kb
x264.nl version, rev.1331 is about 991 kb (I'm talking about the very latest, fixed, version)

same sources... more than 200 kb difference in size.
Why there is this difference?gpac.

[allak]

DS version is compiled without MP4 support, I'd say the difference is from the GPAC library.

[nurbs]

I did some tests with the current r1331 from x264.nl. I tested with the default settings only specifying the number of threads manually from 1 to 5. On my samples I got something like Weighted P-Frames: Y:5.8% for one thread and Weighted P-Frames: Y:16.5% for 2 or more threads. With all of the samples I tested the number was much higher when multiple threads were used.
So, is that a problem?

edit: post 666 :devil:

[Chikuzen]

Does --weightp 2 have problems in play back with DXVA?
I encountered such a phenomenon.
http://forum.doom9.org/attachment.php?attachmentid=10472&stc=1&d=1258095131
http://forum.doom9.org/attachment.php?attachmentid=10473&stc=1&d=1258095191
http://forum.doom9.org/attachment.php?attachmentid=10474&stc=1&d=1258095240

I uploaded all(sourcefile,scripts and binary) to mediafire (http://www.mediafire.com/?mjdm1n1mgoy).

My environment:
Binary:x264.nl r1332(x86)
Player:MPC-HC r1301(x86)
Decoder:MPC VIDEO DECODER(DXVA)/Microsoft DVD-DTV Decoder(DXVA)/ffdshow-tryouts r3130
OS:Windows7pro(x64)
Graphic card:Radeon HD3850+ccc9.9

This phenomenon was generated in FlashPlayer10.

[schoeppchen]

Is there any chance that x264.exe will support encoding on the gpu (e.g. via DXVA)?

[LoRd_MuldeR]

Is there any chance that x264.exe will support encoding on the gpu (e.g. via DXVA)?

If at all, it would use CUDA, OpenCL or even DirectX 11 ComputeShaders to exploit the GPU. But not DXVA, as DXVA is for playback/decoding.

However GPU encoding support in x264 is extremely unlikely to happen (at least not in the near future) for the reasons that have been explained dozens of times :search:

[Assassinator]

Is it just me, or is anyone else having sporadic freezes with the newer versions of x264 since weightp was introduced?

So pretty much what happens is x264 just freezes, with CPU usage at 0. It happens around once every few hours of encoding, is random (the same encode can freeze this time, but work next time), is not location dependent (can freeze at the start of an encode, or at the end) and doesn't seem to be settings dependent either (it happens with both my watch-and-delete PSP encodes with really fast settings, and my slow 4fps encodes. One thing in common is that every encode used weightp... I'm current running some encodes without, but it'll be a while until I can confirm any results).

It may sound to you like a problem on my side (and I'm not denying the possibility), but I don't remember any pre-weightp builds ever freezing like that, and I haven't changed my system configuration in quite a long time. Tried both x264.nl's and JEEB's builds, 1332 and 1336, 32bit, so it isn't a problem with a particular build being bad (unless all of them are miscompiled... :\). Going to try that ICC build that was posted today sometime later.

CPU: AMD Phenom 9550. OS: Windows 7 64bit. Encoding with x264 directly, not through any GUI. Sorry I can't provide much other more useful information at the moment.

[akupenguin]

@Assassinator
Not just you. Debugging it is currently deputized to Saintdev since he seems to be able to reproduce it much more consistently than I can.

[detmek]

I started using new builds with weightp after I reinstaled Win XP SP3. I thougth it is Windows problem or Avisynth problem because I am using MT libraries made by JD.
I tried to convert one AVC file using 2-pass mode. The first time it stoped on first pass. Second time, it stoped on second pass.
I replaced DGAVCSource with DSS2 and it finished convesion. x264 build was 1331. I didn't test again.

[burfadel]

Yeah the crashes are pretty random, its related to x264 and not the encoding chain. I just encoded one file that got to 99.7 before it just stopped encoding like outlined about!

[SledgeHammer_999]

I can confirm exactly what Assassinator said. Random freezes. Sometimes it finishes the SAME encode sometimes it freezes(well megui still displays 0.xxFPS). I am using 2-pass mode. For me only rev1318 works. Every rev till 1336 doesn't. (I haven't tested 1319).

[JohannesL]

I can confirm exactly what Assassinator said. Random freezes. Sometimes it finishes the SAME encode sometimes it freezes(well megui still displays 0.xxFPS). I am using 2-pass mode. For me only rev1318 works. Every rev till 1336 doesn't. (I haven't tested 1319).
You should currently not use MeGUI for x264 encoding, especially not for bug reporting.

[detmek]

You should currently not use MeGUI for x264 encoding, especially not for bug reporting.

Why not? MeGUI is just a GUI for other applications. I'm using it to create AVS script. And MeGUI only generates command line for x264. Other then that, conversion process is completely independent from MeGUI, right? If generated command line is wrong, x264 wont start at all.
Other then using MeGUI to create avs file, I started conversion process using manually created bat file. And I still got same problem as Assassinator.
My avs script contained avcsource and bicubic resize.
x264 command line was like: --tune film --bitrate 888 --pass 2 --me umh --level 4.0 --vbv-maxrate 20000 --vbv-bufsize 25000 --b-adapt 2.

[SledgeHammer_999]

You should currently not use MeGUI for x264 encoding, especially not for bug reporting.

why?

I just feed it an avisynth script and choose the encoding options myself. I just use it to queue encodes.

[moviefan]

I have had freezes as well, just for the record, and I started the encoding purely from the command line.

[Dark Shikari]

Use r1318 until we have fixed all the issues with HEAD.

Do we need a "stable revision marker" or something?

[juGGaKNot]

Use r1318 until we have fixed all the issues with HEAD.

Do we need a "stable revision marker" or something?

Yes but you always find old bugs so ... yes

[Audionut]

My own build has been working fine for me on numerous encodes.

http://rapidshare.com/files/304464362/x264.exe

Revision 1331

[me7]

I did ~20 fine encodes with 1332 from x264.nl. It seems to depend more on your OS and/or source then the compile.

[prOnorama]

Use r1318 until we have fixed all the issues with HEAD.

Do we need a "stable revision marker" or something?

Yes a "stable revision marker" would be nice for the less tech savvy like me. Also maybe GUI developers will like it, I bet they have a hard time keeping up wiith with the rapid pace of x264 development anyway. Meanwhile the techheads here can sort out the bugs when new features are added to x264 like after r1318.

[burfadel]

Without the time to do testing, it seems lower res videos (512,384) don't freeze whereas higher res video sources do?

[Assassinator]

Without the time to do testing, it seems lower res videos (512,384) don't freeze whereas higher res video sources do?

Sure they do. I use a script to batch convert large quantities of videos to PSP (480x272 or ???x272 if not 16:9), and I've gotten quite a few freezes. And no, it's not the script's fault, all that does is extract subtitle streams, generate avs scripts, and set up encodes.

It's probably just that larger videos take more processing, so are more likely to freeze up before completion than smaller vids.




As Dark Shikari said, if anyone's particularly worried about it, just use the older versions that don't freeze.

[Dark Shikari]

Bug [probably] found. Fix [probably] incoming.

[juGGaKNot]

x264 [info]: Weighted P-Frames: Y:4.9% with aq-mode 0
x264 [info]: Weighted P-Frames: Y:11.2% with aq-mode 2

Is this normal ?

[dylanza]

x264 [info]: Weighted P-Frames: Y:4.9% with aq-mode 0
x264 [info]: Weighted P-Frames: Y:11.2% with aq-mode 2

Is this normal ?

No, that seems wrong. Do you have the command line and a source to test with? Are you on r1342?
Maybe its another bug.

[juGGaKNot]

No, that seems wrong. Do you have the command line and a source to test with? Are you on r1342?
Maybe its another bug.

1342 jeeb 4.3.4 32 bit

AVIsource("C:\x264\movie.avi")
Crop(0, height%2, -width%2, 0)
ConvertToYV12()

--preset veryslow --level 3.2 --ref 5 --min-keyint fps --keyint fpsx10 --bframes 3 --merange 32 --aq-mode 0 --sar 1:1 --aud

128k net, can't upload, 1280x800 30 fps

[detmek]

1342 x264.nl 32-bit build works fine on my test clip with --preset medium --aq-mode 0 and 2.
Weigthp Y:2.5%.

[Boolsheet]

I think something's wrong with JEEB's latest builds. The checksums of imk's ICC builds and my own (mingw with gcc 3.4.5) are the same but all 3 JEEB builds get something different. And it's not fprofile this time, at least not for the gcc 3.4.5 version.

[JEEB]

Looking into it as we speak, have been a bit busy with looking at several scripts made for building a toolchain. Having trouble with building GCC 4.5 for testing and 4.3.X as well as 4.4.X for daily building :3 (all give different errors atm). To make all clear this stuff is being done on a completely different msys/mingw environment, the one I use for daily building I haven't touched for quite some time (touching as in adding/removing libraries/binaries).

Switching to a newer Komisar mingw toolchain version is possible for the moment until I get my own toolchain going.

EDIT:

Cannot reproduce this with foreman on the patched 32bit build when compared as well to a build done with the newest 4.5 gcc version (a completely different msys/mingw setup used as well):

jeeb@PATCHOULI ~/ownapps/x264
$ x264-old-32bit.exe --preset slower --aq-mode 2 foreman_cif.y4m -o foreman_old
_aq2.mkv
yuv4mpeg: 352x288@30000/1001fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cac
e64
x264 [info]: profile High, level 2.1
x264 [info]: frame I:2 Avg QP:21.15 size: 26827
x264 [info]: frame P:134 Avg QP:24.01 size: 4128
x264 [info]: frame B:164 Avg QP:28.51 size: 755
x264 [info]: consecutive B-frames: 12.4% 28.9% 41.3% 17.4%
x264 [info]: mb I I16..4: 3.7% 40.5% 55.8%
x264 [info]: mb P I16..4: 0.2% 1.6% 0.8% P16..4: 46.4% 20.9% 19.0% 1.1%
.8% skip: 9.2%
x264 [info]: mb B I16..4: 0.0% 0.2% 0.1% B16..8: 47.9% 3.6% 4.0% direct
3.5% skip:40.6% L0:45.2% L1:45.6% BI: 9.2%
x264 [info]: 8x8 transform intra:56.4% inter:52.2%
x264 [info]: direct mvs spatial:97.0% temporal:3.0%
x264 [info]: coded y,uvDC,uvAC intra: 90.0% 84.5% 54.5% inter: 22.6% 17.3% 2.9%
x264 [info]: i16 v,h,dc,p: 48% 16% 3% 33%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 9% 3% 7% 20% 16% 17% 9% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 11% 5% 7% 19% 13% 15% 9% 12%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 56.6% 8.4% 17.6% 4.1% 3.0% 2.8% 3.1% 2.0% 2.4% 0
0%
x264 [info]: ref B L0: 69.0% 10.8% 7.5% 3.9% 3.2% 2.8% 2.8%
x264 [info]: kb/s:583.91

encoded 300 frames, 18.04 fps, 583.91 kb/s

jeeb@PATCHOULI ~/ownapps/x264
$ x264-old-32bit.exe --preset slower --aq-mode 0 foreman_cif.y4m -o foreman_old
_aq0.mkv
yuv4mpeg: 352x288@30000/1001fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cac
e64
x264 [info]: profile High, level 2.1
x264 [info]: frame I:2 Avg QP:20.98 size: 27695
x264 [info]: frame P:134 Avg QP:23.89 size: 4623
x264 [info]: frame B:164 Avg QP:28.00 size: 947
x264 [info]: consecutive B-frames: 12.4% 28.9% 41.3% 17.4%
x264 [info]: mb I I16..4: 3.9% 33.6% 62.5%
x264 [info]: mb P I16..4: 0.2% 1.5% 1.0% P16..4: 43.5% 19.5% 18.9% 1.6%
.3% skip:12.6%
x264 [info]: mb B I16..4: 0.0% 0.2% 0.1% B16..8: 44.6% 4.6% 5.0% direct
4.3% skip:41.1% L0:43.9% L1:43.3% BI:12.8%
x264 [info]: 8x8 transform intra:48.7% inter:49.5%
x264 [info]: direct mvs spatial:98.8% temporal:1.2%
x264 [info]: coded y,uvDC,uvAC intra: 88.2% 82.5% 58.2% inter: 24.7% 17.3% 4.1%
x264 [info]: i16 v,h,dc,p: 34% 25% 5% 36%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 9% 3% 8% 19% 16% 16% 8% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 12% 5% 7% 19% 12% 15% 8% 12%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 55.5% 8.1% 18.1% 4.2% 3.3% 2.9% 3.3% 2.1% 2.5% 0
0%
x264 [info]: ref B L0: 69.2% 11.2% 7.3% 3.7% 3.0% 2.8% 2.8%
x264 [info]: kb/s:663.44

encoded 300 frames, 17.88 fps, 663.44 kb/s

jeeb@PATCHOULI ~/ownapps/x264
$ x264-new-32bit.exe --preset slower --aq-mode 2 foreman_cif.y4m -o foreman_new
_aq2.mkv
yuv4mpeg: 352x288@30000/1001fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cac
e64
x264 [info]: profile High, level 2.1
x264 [info]: frame I:2 Avg QP:21.15 size: 26820
x264 [info]: frame P:134 Avg QP:24.01 size: 4128
x264 [info]: frame B:164 Avg QP:28.51 size: 755
x264 [info]: consecutive B-frames: 12.4% 28.9% 41.3% 17.4%
x264 [info]: mb I I16..4: 3.7% 40.5% 55.8%
x264 [info]: mb P I16..4: 0.2% 1.6% 0.8% P16..4: 46.4% 20.9% 19.0% 1.1%
.8% skip: 9.2%
x264 [info]: mb B I16..4: 0.0% 0.2% 0.1% B16..8: 47.9% 3.6% 4.0% direct
3.5% skip:40.6% L0:45.2% L1:45.6% BI: 9.2%
x264 [info]: 8x8 transform intra:56.4% inter:52.2%
x264 [info]: direct mvs spatial:97.0% temporal:3.0%
x264 [info]: coded y,uvDC,uvAC intra: 90.0% 84.5% 54.5% inter: 22.6% 17.3% 2.9%
x264 [info]: i16 v,h,dc,p: 48% 16% 3% 33%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 9% 3% 7% 20% 16% 17% 9% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 11% 5% 7% 19% 13% 15% 9% 12%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 56.6% 8.4% 17.6% 4.1% 3.0% 2.8% 3.1% 2.0% 2.4% 0
0%
x264 [info]: ref B L0: 69.0% 10.8% 7.5% 3.9% 3.2% 2.8% 2.8%
x264 [info]: kb/s:583.90

encoded 300 frames, 18.22 fps, 583.90 kb/s

jeeb@PATCHOULI ~/ownapps/x264
$ x264-new-32bit.exe --preset slower --aq-mode 0 foreman_cif.y4m -o foreman_new
_aq0.mkv
yuv4mpeg: 352x288@30000/1001fps, 128:117
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cac
e64
x264 [info]: profile High, level 2.1
x264 [info]: frame I:2 Avg QP:20.98 size: 27688
x264 [info]: frame P:134 Avg QP:23.89 size: 4623
x264 [info]: frame B:164 Avg QP:28.00 size: 947
x264 [info]: consecutive B-frames: 12.4% 28.9% 41.3% 17.4%
x264 [info]: mb I I16..4: 3.9% 33.6% 62.5%
x264 [info]: mb P I16..4: 0.2% 1.5% 1.0% P16..4: 43.5% 19.5% 18.9% 1.6%
.3% skip:12.6%
x264 [info]: mb B I16..4: 0.0% 0.2% 0.1% B16..8: 44.6% 4.6% 5.0% direct
4.3% skip:41.1% L0:43.9% L1:43.3% BI:12.8%
x264 [info]: 8x8 transform intra:48.7% inter:49.5%
x264 [info]: direct mvs spatial:98.8% temporal:1.2%
x264 [info]: coded y,uvDC,uvAC intra: 88.2% 82.5% 58.2% inter: 24.7% 17.3% 4.1%
x264 [info]: i16 v,h,dc,p: 34% 25% 5% 36%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 9% 3% 8% 19% 16% 16% 8% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 12% 5% 7% 19% 12% 15% 8% 12%
x264 [info]: Weighted P-Frames: Y:1.5%
x264 [info]: ref P L0: 55.5% 8.1% 18.1% 4.2% 3.3% 2.9% 3.3% 2.1% 2.5% 0
0%
x264 [info]: ref B L0: 69.2% 11.2% 7.3% 3.7% 3.0% 2.8% 2.8%
x264 [info]: kb/s:663.42

encoded 300 frames, 18.30 fps, 663.42 kb/s


Will try with the 1280x720 sample I've got with the settings the original reporter used.

EDIT2:

Did not reproduce with the, granted, short saisoku.y4m that utilizes weightp.


jeeb@PATCHOULI ~/ownapps/x264
$ x264-old-32bit.exe --preset veryslow --bframes 3 --ref 5 --aq-mode 0 --sar 1:
1 --aud saisoku.y4m -o saisoku-old-aq0.mkv
yuv4mpeg: 1280x720@24/1fps, 1:1
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:26.81 size: 9273
x264 [info]: frame P:53 Avg QP:28.47 size: 10545
x264 [info]: frame B:45 Avg QP:28.95 size: 5880
x264 [info]: consecutive B-frames: 21.4% 44.9% 21.4% 12.2%
x264 [info]: mb I I16..4: 63.8% 35.7% 0.5%
x264 [info]: mb P I16..4: 21.8% 12.2% 0.3% P16..4: 42.0% 4.1% 3.2% 0.0% 0
.0% skip:16.2%
x264 [info]: mb B I16..4: 2.8% 1.7% 0.0% B16..8: 36.0% 0.8% 1.0% direct:
6.9% skip:50.7% L0:53.4% L1:41.6% BI: 5.0%
x264 [info]: 8x8 transform intra:35.8% inter:96.3%
x264 [info]: direct mvs spatial:95.6% temporal:4.4%
x264 [info]: coded y,uvDC,uvAC intra: 18.4% 36.3% 6.0% inter: 11.8% 22.3% 1.3%
x264 [info]: i16 v,h,dc,p: 13% 21% 8% 58%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 13% 14% 9% 10% 9% 14% 10% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 25% 11% 4% 9% 7% 11% 6% 12%
x264 [info]: Weighted P-Frames: Y:34.0%
x264 [info]: ref P L0: 34.6% 14.0% 25.3% 8.0% 5.2% 8.4% 4.6%
x264 [info]: ref B L0: 70.8% 13.5% 9.7% 6.0%
x264 [info]: kb/s:1618.28

encoded 101 frames, 2.08 fps, 1618.28 kb/s

jeeb@PATCHOULI ~/ownapps/x264
$ x264-old-32bit.exe --preset veryslow --bframes 3 --ref 5 --aq-mode 2 --sar 1:
1 --aud saisoku.y4m -o saisoku-old-aq2.mkv
yuv4mpeg: 1280x720@24/1fps, 1:1
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:27.41 size: 8649
x264 [info]: frame P:53 Avg QP:29.82 size: 9181
x264 [info]: frame B:45 Avg QP:30.80 size: 4869
x264 [info]: consecutive B-frames: 21.4% 44.9% 21.4% 12.2%
x264 [info]: mb I I16..4: 65.9% 33.9% 0.2%
x264 [info]: mb P I16..4: 21.2% 11.9% 0.2% P16..4: 44.0% 3.5% 3.3% 0.0% 0
.0% skip:16.0%
x264 [info]: mb B I16..4: 2.6% 1.6% 0.0% B16..8: 36.8% 0.4% 0.7% direct:
5.2% skip:52.6% L0:54.1% L1:42.3% BI: 3.6%
x264 [info]: 8x8 transform intra:35.7% inter:97.4%
x264 [info]: direct mvs spatial:95.6% temporal:4.4%
x264 [info]: coded y,uvDC,uvAC intra: 16.9% 35.1% 4.4% inter: 9.3% 19.8% 0.6%
x264 [info]: i16 v,h,dc,p: 13% 21% 8% 58%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 12% 13% 9% 11% 9% 15% 10% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 22% 10% 5% 11% 9% 12% 6% 12%
x264 [info]: Weighted P-Frames: Y:34.0%
x264 [info]: ref P L0: 35.0% 13.9% 24.9% 7.6% 5.4% 8.6% 4.6%
x264 [info]: ref B L0: 70.2% 13.6% 10.6% 5.5%
x264 [info]: kb/s:1390.87

encoded 101 frames, 2.56 fps, 1390.87 kb/s

[me7]

Revision 1369 just crashed on me for the second time. I started encoding the video with 1360 earlier today and after I saw 1369 with mbtree+b-pyramid support I restarted the encode and added "--b-pyramid normal" to my parameters. Because both crashes took place earlier then the progress I made during my 1360 encode and I still use the same source file and avs script I would guess that x264 is to blame.
Both crashes were 'silent' with no error messages from x264, I was just informed by Windows that x264.exe has crashed.

settings
x264.exe --rc-lookahead 60 --merange 24 --crf 19.0 --ref 8 --bframes 6 --b-adapt 2
--b-pyramid normal --direct auto --subme 10 --trellis 2 --partitions all --me umh --tune film
--threads auto --thread-input --output "output.mp4" "input.avs"

script
FFVideoSource("C:\enc\F1_T2_Video - .mkv")
crop( 0, 142, 0, -140)
Spline36Resize(1280,532)

[Selur]

@me7: might be a gcc problem,... run 'x264 --version' to check which gcc version was used and if it's an '(experimental)'-one try another build which uses e.g. gcc 4.3.

[Amefurashi]

Referring to the latest rev(1369)

Don't know if it's a bug or something, but if you don't specify "strict" or "normal" in b-pyramid option, an error occurs:

x264.exe --pass 1 --bitrate 3863 --stats "test.stats" --level 4.1 --keyint 240
--min-keyint 24 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-adapt 2 --weightb
--weightp 2 --direct auto --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 1.0:0
--partitions all --8x8dct --vbv-bufsize 50000 --vbv-maxrate 50000 --me tesa
--merange 32 --threads auto --thread-input --aq-strength 1.0 --no-dct-decimate
--rc-lookahead 60 --output NUL test.avs
x264 [error]: invalid argument: b-pyramid = --b-adapt

Please note that the "invalid argument" error occurs with any parameter put after --b-pyramid (I think x264 doesn't have a default option so it goes searching for a sub-parameter).

Regards,
AF

[Limit]

r1369 is crashing here with a segmentation fault. I'm running Ubuntu 9.10 x64 and using the standard Ubuntu GCC (Ubuntu 4.4.1-4ubuntu8) to compile x264 myself (no patches).

Input comes from Avisynth+avs2yuv with the following commandline (I'm using a self-made script to generate the cmd).

wine avs2yuv.exe andro.avs - | x264 - --stdin y4m -o andro.264 --sar 16/15 --threads auto --thread-input
--non-deterministic --crf 20 --threads auto --ssim --min-keyint 100 --keyint 500 --scenecut 80 --b-adapt 2
--bframes 6 --ref 3 --b-pyramid normal --me umh --subme 7 --merange 16 --partitions i8x8,p8x8,b8x8,i4x4
--trellis 1 --aq-mode 2 --aq-strength 1.000000 --psy-rd 1.000000:0.200000 --rc-lookahead 80 --nr 0 --direct auto
--qpmin 10 --qpmax 42 --vbv-bufsize 9000 --vbv-maxrate 3000

dmesg delivers the following lines after the crashes (I tested it 3 times):
x264[25644]: segfault at 7f761d87e22e ip 0000000000481a6e sp 00007f7612892098 error 4 in x264[400000+aa000]
x264[22732]: segfault at 7f2df0059147 ip 0000000000481a6a sp 00007f2df112c098 error 4 in x264[400000+aa000]
x264[32266]: segfault at 7f2e3c94ad9c ip 0000000000481a6e sp 00007f2e3da1d098 error 4 in x264[400000+aa000]

[Update] The non-fprofiled version seems to run without any problems.
[Update2] It happend again, but this time with the non-fprofiled version.

[LoRd_MuldeR]

Referring to the latest rev(1369)

Don't know if it's a bug or something, but if you don't specify "strict" or "normal" in b-pyramid option, an error occurs:

x264.exe --pass 1 --bitrate 3863 --stats "test.stats" --level 4.1 --keyint 240
--min-keyint 24 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-adapt 2 --weightb
--weightp 2 --direct auto --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 1.0:0
--partitions all --8x8dct --vbv-bufsize 50000 --vbv-maxrate 50000 --me tesa
--merange 32 --threads auto --thread-input --aq-strength 1.0 --no-dct-decimate
--rc-lookahead 60 --output NUL test.avs
x264 [error]: invalid argument: b-pyramid = --b-adapt

Please note that the "invalid argument" error occurs with any parameter put after --b-pyramid (I think x264 doesn't have a default option so it goes searching for a sub-parameter).

Regards,
AF

Of course writing "--b-pyramid" without a (valid) argument results in error, because that parameter does require exactly one argument. So if you write "(...) --b-pyramid --b-adapt 2 (...)", then "--b-adapt" is treated as the parameter for the preceding "--b-pyramid" command. Which of course isn't a valid value. Thus the error message. Also you'd get a lonesome "2" in the middle of nowhere...

[me7]

@me7: might be a gcc problem,... run 'x264 --version' to check which gcc version was used and if it's an '(experimental)'-one try another build which uses e.g. gcc 4.3.

It's the 'official' 32-bit build from x264.nl
C:\>x264 --version
x264 0.80.1369 ec8e586
built on Dec 9 2009, gcc: 3.4.6

[LoRd_MuldeR]

I got a crash with r1369 as well, last night. Didn't have time to reproduce or investigate. But will try to do so as soon as I return back home...

[Amefurashi]

Of course writing "--b-pyramid" without a (valid) argument results in error, because that parameter does require exactly one argument. So if you write "(...) --b-pyramid --b-adapt 2 (...)", then "--b-adapt" is treated as the parameter for the preceding "--b-pyramid" command. Which of course isn't a valid value. Thus the error message. Also you'd get a lonesome "2" in the middle of nowhere...

IIRC "older" builds of x264 (prior to mb-tree implementation) didn't need to specify an argument in b-pyramid. I must be mistaken.

:thanks:

[LoRd_MuldeR]

commit e2659dbdc0aed2d2cd4f6538faddf370e7740ada r1296
Author: Lamont Alston <wewk584@gmail.com>
Date: Mon Oct 12 23:32:16 2009 -0700

Make B-pyramid spec-compliant
The rules of the specification with regard to picture buffering for pyramid coding are widely ignored.
x264's b-pyramid implementation, despite being practically identical to that proposed by the original paper, was technically not compliant.
Now it is.
Two modes are now available:
1) strict b-pyramid, while worse for compression, follows the rule mandated by Blu-ray (no P-frames can reference B-frames)
2) normal b-pyramid, which is like the old mode except fully compliant.
This patch also adds MMCO support (necessary for compliant pyramid in some cases).
MB-tree still doesn't support b-pyramid (but will soon).

See:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=blobdiff;f=x264.c;h=fc4e44f1739bca18e898dea385d8545f45ff47d3;hp=a440ab7f7b18d1ae4956d4b402e9c148ad07f1d7;hb=e2659dbdc0aed2d2cd4f6538faddf370e7740ada;hpb=b826fd5475a5e883f85e26cbf9d2c0acf5efcbd6

[MatLz]

r1369
No crashes, but I experience flickerings(again:D)

[me7]

It crashed again, Windows was "looking for a solution" and offered me to try to debug it with Visual Studio. Apparently the crash is caused by an unhandled win32 exception.

[[DB-FR] Nikko]

No problem with this version (r1369). I used these parameters for the first and second pass :

--pass 1 --bitrate 1000 --stats "analyses.stats" --level 4.1 --keyint 240 --min-keyint 24 --ref 9
--no-fast-pskip --bframes 16 --b-adapt 2 --b-pyramid normal --direct auto --deblock 1:1 --rc-lookahead 100
--subme 10 --trellis 2 --psy-rd 0.6:0 --partitions p8x8,b8x8,i4x4,i8x8 --qpmin 1 --ipratio 1.1 --pbratio 1.1
--vbv-bufsize 5000 --vbv-maxrate 5000 --me umh --thread-input --aq-mode 2 --psnr --ssim

Encode perfectly :)

Im on Windows Xp, and have Intel Core Duo proc..

[Rarsix]

It crashed and when i tried again, i got another problem :|

http://i664.photobucket.com/albums/vv2/Rarsix/abc-5.jpg

here is my setting

--profile high --level 4.1 --pass 2 --bitrate 1270 --stats ".stats" --thread-input --deblock 0:1 --keyint 240 --min-keyint 24 --bframes 6 --b-adapt 2 --b-pyramid normal --scenecut 50 --ref 9 --qpmin 8 --qpstep 16 --rc-lookahead 50 --merange 32 --me umh --direct auto --subme 10 --partitions all --trellis 2 --no-fast-pskip --psy-rd 1.00:0.40

[Jiyuu]

i was sure you were asked this all the time so i did a search for "cuda 3.0" and "fermi" but couldn't find anything.
not too long ago the specs of fermi were released(here's a link to one review on it http://www.anandtech.com/video/showdoc.aspx?i=3651 ) and from what i understood of them it made GPGPU much simpler then it is today.
now, i remember that when cuda first came out the one of the main issues raised in regards to using it in x264 was high latencies, and difficult\inefficient coding while actually using cuda, from the review i got the impression that cuda 3\fermi made coding for it a lot more flexible and similar to coding for a normal CPU, as well a lowered price for access to it.
so i wanted to see if this is likely to change anything in regards for implementing this in future versions of x264, and generally if you guys think those changes could be useful.

[Esurnir]

It crashed and when i tried again, i got another problem :|

http://i664.photobucket.com/albums/vv2/Rarsix/abc-5.jpg

here is my setting

What's your decoder?

[MatLz]

r1373
mbtree+bpyramid -> flickerings
Only mbtree -> flickerings
Only bpyramid -> good

Same results with different patched builds

[LoRd_MuldeR]

The same procedure as every year:

Provide the shortest possible unprocessed sample to re-produce the problem and tell us your complete commandline.