x264 development

[Adub]

No, he is an AMD fanboy.
Shucks, does anyone know where we can get patched ssse3 builds?

[Romario]

Electria-chan : SSE4 has been renamed SSSE3. So ChronoCross is right.

Noo, SSE3 is SSE3, SSE4 is future instruction set designed for Penryn arhitecture (45 nm shrink of Core 2 Duo and Core 2 Quad).

[Manao]

Romario : count the number of Ss and check on the internet. But don't confuse users anymore than necessary when you're wrong - and wrong you are. MMX < SSE < SSE2 < SSE3 < SSSE3 < SSE4, and SSE4 doesn't yet exist, period.

[Adub]

Okay, now that that has been settled, does anyone know if their will be other ssse3 builds besides the two provided by our good man Cef? I am hoping for the patches that Sharktooth usually includes as well.

[Bigmango]

Hi,

I made x264 ssse3 builds since i couldn't find any, sharing if anyone interested
http://cef.neuf.fr/x264/x264_x86_r637.7z
http://cef.neuf.fr/x264/x264_x64_r637.7z

Wow thanks !!

Please keep them coming ;)

[Cef]

Please keep them coming ;)
Here goes
x264_x86_r644.7z (http://cef.neuf.fr/x264/x264_x86_r644.7z)
x264_x64_r644.7z (http://cef.neuf.fr/x264/x264_x64_r644.7z)
and source (http://cef.neuf.fr/x264/x264_src_r644.7z)

Okay, now that that has been settled, does anyone know if their will be other ssse3 builds besides the two provided by our good man Cef? I am hoping for the patches that Sharktooth usually includes as well.

I guess I could add them, if he doesn't mind.

[Adub]

That would be great!

Edit: Although, now that I think about it, are the patches really necessary? I mean a majority of them have already been incorporated into x264. Does anyone know if the patches compiled by Sharktooth actually make that big of a difference in quality?


Thanks a lot Cef, and know that you are always appreciated here.

[foxyshadis]

The signature patch is trivial, to increase MeGUI compatibility iirc, but the AQ patch is quite important to a lot of people.

An SSSE3 build will only make sense on x64, since the SSSE3 code is only currently enabled there. For optimizing the C code, well, it's not worth a special compile just to print the options list with SSSE3.

[Cef]

I enabled ssse3 in 32bit too, basically copy/paste with few passing parameters change. Except for x264_pixel_sa8d_8x8_ssse3/x264_pixel_sa8d_16x16_ssse3, which use way too many xmm registers to be converted to 32bit.

[Adub]

Thanks alot Cef!
I have yet to use your latest build, but your older one actually fixed a problem I was having with the previous X264 builds. And I think (it may have been my imagination) it was 2 fps faster.
Double thanks!

[Cef]

np at all. I made r644 builds with aq patch, just take previous links and replace 640 with 644. Both my 32 and 64bit builds are faster than anything I could find, on my core 2 duo. So if you have a C2D it's probably not your imagination. I think we're off-topic though, sorry about the spam >.<

[foxyshadis]

Nah, it's on-topic enough for a development thread. If you enabled all the satd & quant functions, did you submit a patch to akupenguin or the list? I'm sure he'd commit it. (You can edit new links into your old posts, if you want to, btw.)

[Cef]

did you submit a patch to akupenguin or the list?
Do you mean x264-devel (http://www.videolan.org/developers/lists.html) ? Quant changed in rev642 and is both 32 and 64bit now anyway, I could do that for satd I guess.

[Adub]

Yeah, I am using a core 2 duo, and I can definetly see a slight speed increase. I am downloading you latest build now.

[squid_80]

The 64-bit build doesn't run at all, it crashes immediately on startup. Did you check the code to see if it was win64 compatible?

[Cef]

which one? 644 runs just fine here. There was a bug in previous builds, coming from you actually :p movdqa rsp+16 with stack misaligned in x264_pixel_ssim_end4_sse2. Btw much props for your work on win64 asm :thanks:

[Bigmango]

The 645 build from x264.nl crashes every time after about 5 frames. Does anyone have the same experience ?

I am back to Cef's 644 build.

[LoRd_MuldeR]

Maybe it's related to this?
http://forum.doom9.org/showthread.php?p=979857#post979857

[Bigmango]

Maybe it's related to this?
http://forum.doom9.org/showthread.php?p=979857#post979857

Hmmm... I don't know. I am having this problem with the CLI version; the crash happens with the official x264.nl 645 exe.

But Cef's 644 exe works fine, both are using sse2... :confused:

[akupenguin]

The crash (http://forum.doom9.org/showthread.php?p=979857#post979857) is due to a bug in gcc. Cef built a win64 version, so he can't have been using gcc.

[Bigmango]

The crash (http://forum.doom9.org/showthread.php?p=979857#post979857) is due to a bug in gcc. Cef built a win64 version, so he can't have been using gcc.

Ok, thx for the info.

Btw, I am using Cef's x86 version.

[LoRd_MuldeR]

Bigmango, try Gruntster's rev645 build with the new fix included:
http://www.razorbyte.com.au/x264

[Bigmango]

Bigmango, try Gruntster's rev645 build with the new fix included:
http://www.razorbyte.com.au/x264

Oh, it's the lib; so I can try avidemux again :)

:thanks:

[squid_80]

which one? 644 runs just fine here. There was a bug in previous builds, coming from you actually :p movdqa rsp+16 with stack misaligned in x264_pixel_ssim_end4_sse2. Btw much props for your work on win64 asm :thanks:
I had r637, it was crashing in exactly that spot. 644 runs good. Not sure how I came up with [rsp+16] which presumably would never have worked.
Also the handle leak I was getting when using multiple threads seems to be gone; did you do something to fix it, has pthreads been updated since I made a build, or did the problem just mysteriously go away?

[bob0r]

When the patch is applied to the svn, i will remove the notes and everything should be ok again.

So hopefully in the next revision its all ok again.

Keep testing, using and reporting! :thanks:

[Cef]

Not sure how I came up with [rsp+16] which presumably would never have worked.
Maybe you never noticed it, with my usual settings the bug wasn't triggered, I happened to find it while running x264 with no options for a quick test.

Also the handle leak I was getting when using multiple threads seems to be gone; did you do something to fix it, has pthreads been updated since I made a build, or did the problem just mysteriously go away?
Actually it's not using pthread, just some #define's falling back on win32 threads, cause I had trouble getting pthread to work, but now I got it to work, please check x264_x64_r645.7z (http://cef.neuf.fr/x264/x264_x64_r645.7z)

[squid_80]

Can't open that .7z file: winrar 3.62 reports unknown format or damaged. Same with 7-zip 4.44 beta.

[Cef]

Sorry about that, try again.

[squid_80]

Got it, shows the same handle leak that I was seeing with before. :(

[Cef]

I think I found the problem, some inline asm in ptw32_InterlockedCompareExchange.c was ignored when compiling pthread for amd64. Should be gone now : x264_x64_r648 (http://cef.neuf.fr/x264/x264_x64_r648.7z)

[Terranigma]

I hope it works. x264, for me, seems to have been b0rken after revision 644 :(

---
Nope, doesn't even start up. =/

[Adub]

Cef, are you going to do a x86 build?

[Terranigma]

yes cef, when you do builds, could you do an x86 build as well? :D

[Bigmango]

I hope it works. x264, for me, seems to have been b0rken after revision 644 :(

---
Nope, doesn't even start up. =/

The latest 648 build works great for me. It seems the problem was fixed since build 646.

Did you try it ?

Here:
http://x264.nl/
http://mirror01.x264.nl/x264/revision648/x264.exe

[Terranigma]

The latest 648 build works great for me. It seems the problem was fixed since build 646.

Did you try it ?

Here:
http://x264.nl/
http://mirror01.x264.nl/x264/revision648/x264.exe


It works, but unfortunately I can't use adaptive quantization for dark scenes. Perhaps the commandline for aq changed? :confused:
I've made profiles using aq. =P


Anyways, i'd like to say that It seems x264's now twice as fast as before :D

[burfadel]

Adaptive quantisation is only an experimental patch apparently! The builds at x264.nl are pure svn builds. Although adaptive quantiser is experimental I find it works very well! it mustn't be quite ready though...

You have to search for the adaptive quantiser builds. Sharktooth makes them but he doesn't always have the time to stay updated, he's still with revision 635. CEF on this thread actually has the latest adaptive quantiser build... rev 645 for x86 and rev 648 for x64. Both work great! I'm sure he'll put up a rev 648 for x86 at some stage as people have asked him for it... He did a good job of implementing SSSE3 instructions! :)

It works, but unfortunately I can't use adaptive quantization for dark scenes. Perhaps the commandline for aq changed? :confused:
I've made profiles using aq. =P


Anyways, i'd like to say that It seems x264's now twice as fast as before :D

[Terranigma]

Thanks burfadel for the prompt reply. Look like i'll have to look forward to a build by cef :cool:

[Selur]

What about the one here:
http://forum.doom9.org/showpost.php?p=980523&postcount=130

[Terranigma]

that's for x64.

[Selur]

oh, you are right overlooked that sorry :)

[Romario]

About SSE3 implementation in recent x264 builds, can someone explain to me what parts of the code is changed?

Speed-ups?

[Manao]

SSS3, and, yes, it results in speed up.

[akupenguin]

There are only 2 places I found where SSSE3 could be used: satd uses PABS, and quantization uses PSIGN and PABS.
PHADD/PHSUB looked interesting, and they do reduce the code size, but at least on a current Core2 they're so much slower than PADD/PSUB that it's faster to transpose, column sum, transpose than to row sum.

[Manao]

Did you do deblocking already ? Or do you consider it not as important (speedwise) in an encoder as in a decoder.

[akupenguin]

Both: I didn't see anything in deblocking that would change, and there's already several deblocking optimizations in ffmpeg that I haven't bothered to port. Deblocking spends more time in C code (computing the filter strengths) than in asm (munging pixels).
There are some absolute value computations, but they can't be done with PABS because the intermediate signed value would take 9 bits, whereas the current code can get away without ever unpacking the pixels from 8 bits.

The horizontal 6tap filter would benefit from PALIGNR, but then it would probably benefit even more from SSE2 (currently it's only MMX). And again that's not in the inner loop when encoding.

[Cef]

Cef, are you going to do a x86 build?
Sorry, focused on this handle leakage which was 64-bit specific then I been busy till now. x264_x86_r648.7z (http://cef.neuf.fr/x264/x264_x86_r648.7z)

[Terranigma]

Sorry, focused on this handle leakage which was 64-bit specific then I been busy till now. x264_x86_r648.7z (http://cef.neuf.fr/x264/x264_x86_r648.7z)

Thanks a lot Cef. :devil:

[akapuma]

Sorry, focused on this handle leakage which was 64-bit specific then I been busy till now. x264_x86_r648.7z (http://cef.neuf.fr/x264/x264_x86_r648.7z)
Thank you very much.

Best regards

akapuma

[Bigmango]

Sorry, focused on this handle leakage which was 64-bit specific then I been busy till now. x264_x86_r648.7z (http://cef.neuf.fr/x264/x264_x86_r648.7z)

Your link does not work ?


Multiple Choices
The document name you requested (/x264/x264_x86_r648.7z) could not be found on this server. However, we found documents with names similar to the one you requested.

Available documents:

* /x264/x264_x86_r640.7z (mistyped character)
* /x264/x264_x86_r644.7z (mistyped character)
* /x264/x264_x86_r645.7z (mistyped character)

[burfadel]

Works for me! he must have fixed the link :)

Thanks Cef for making these builds, its much appreciated!