libx264 GIT builds

[Nik]

stupid question:
there now are options to enable/disable weighted p-frame det. and MB tree in Avidemux if I get it right
what advantages are there using the files above?
I think with core i7 I don\'t need any of them and just use the files that come avidemux?

[DarkZell666]

Avidemux isn\'t re-released each time there\'s a x264 update (same goes for all libraries used), so you\'ll still use the builds provided here to keep libx264 up-to-date.

Actually, there\'s still QPRD (subme=10), as well as psy-trellis missing. IIRC MuldeR sets psy-trellis to 0.15 instead of 0.0 in his builds as well

[LoRd_MuldeR]

stupid question:
there now are options to enable/disable weighted p-frame det. and MB tree in Avidemux if I get it right
what advantages are there using the files above?

Those builds are fprofiled, I don\'t think Gruntster\'s builds are. And I enabled CPU-specific optimizations!

Also I use some unofficial patches. Yes, now MB-Tree and RC Lookahead can be configured from within Avidemux.

But I use more custom patches, such as my \"print_params\" and \"fast_firstpass\" patch

Last but not least, as stated by DarkZell666, x264 is updated frequently and I try to keep my builds up to date.

BTW: Weighted P-Prediction can NOT be configured in Avidemux yet. Or did I miss that

I think with core i7 I don\'t need any of them and just use the files that come avidemux?

AFAIK there are no CPU-specific optimizations for Nehalem (Core i7/i5) in GCC yet.

So from what we have available at the moment, the Core2 optimized builds should work best on the Core i7/i5.

At least they should perform better than the \"generic\" builds

That said, the influence of compiler optimizations is relatively small, as most important code is ASM anyway.

But any small speed-up we can get \"for free\" does matter, right?

[LoRd_MuldeR]

libx264 SVN-r1352 with Weighted P-Frame Prediction:
[list=*]

• libx264-r1352, MinGW GCC 4.4.2, optimized for Core 2[/*]
  
• libx264-r1352, MinGW GCC 4.4.2, optimized for K10[/*]
  
• libx264-r1352, MinGW GCC 4.4.2, optimized for Pentium III[/*]
  
• libx264-r1352, MinGW GCC 4.4.2, without ASM (slow!)[/*]
  

______________________________________________________


libx264 SVN-r1352 without Weighted P-Frame Prediction:
[list=*]

• libx264-r1352, MinGW GCC 4.4.2, optimized for Core 2[/*]
  
• libx264-r1352, MinGW GCC 4.4.2, optimized for K10[/*]
  
• libx264-r1352, MinGW GCC 4.4.2, optimized for Pentium III[/*]
  
• libx264-r1352, MinGW GCC 4.4.2, without ASM (slow!)[/*]
  

______________________________________________________


These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5567 or later now!

This revision contains even more bugfixes and massive speed-up for Weighted-P Prediction.
Note that Avidemux now offers options for MB-Tree RC, Psy RDO and RC Lookahead.

[Brazil]

Actually, there\'s still QPRD (subme=10), as well as psy-trellis missing.

And AQ mode too

[Nik]

@Lord_Mulder: \"BTW: Weighted P-Prediction can NOT be configured in Avidemux yet. Or did I miss that \"

I mixed it up with the \"weighted prediction for p-frames\" checkbox ^^;

alright, then I keep using the core2 file
in a different thread I asked about the performance on core i7, since there\'s little to no gain from multithreading.
Does this result from the missing CPU-specific optimizations in GCC you mentioned?

thanks ^^

[LoRd_MuldeR]

in a different thread I asked about the performance on core i7, since there\'s little to no gain from multithreading.

What??? x264 is scales extremely well on multiple cores!

Therefore any additional core (even those \"logical\" cores introduces through Hyperthreading) will boost the x264 speed.

Also the changes in the Nehalem architecture (Core i7/i5) are extremely beneficial for x264 as well

\"Overall, the changes in Nehalem are extremely beneficial to x264 and have led to an enormous overall performance increase. Furthermore, since the primary speed increase is in SIMD, the more assembly code we write, the more of a boost Nehalem gets over previous processors.\" - http://x264dev.multimedia.cx/?p=51

Does this result from the missing CPU-specific optimizations in GCC you mentioned?

As said before, the compiler optimizations only have a relatively small influence on the overall performance, as (1) compiler optimizations only affect the plain C code in x264 and (2) compiler optimizations still aren\'t anywhere near the performance of a good hand-optimized Assembler code. Most (all?) performance-critical code in x264 already is hand-optimized Assembler code. Also the x264 developers have optimized x264 especially for the Nehalem architecture, even before you could buy a Core i7 in the stores. However CPU-specific compiler optimizations for Core i7 are available in Intel\'s C compiler. ICL provides some speed up for x264 compared to GCC, but it\'s NOT that dramatic! Compiler optimizations simply can\'t do magic...

[Nik]

ah hmm, odd
no idea if this here is the place to talk about, but:

I see only 50% used of every core (since HT lists twice the cores in taskman).
I was told that there seems to be no gain from HT.
But running different programs to utilize the CPU I see up to 99% usage.
encoding with x264 50% (very seldom more than 50%)
encoding with xvid around 30% cpu usage.
the thread about it is somewhere in the dev-2.5-branch, no idea who told me that atm

[LoRd_MuldeR]

I see only 50% used of every core (since HT lists twice the cores in taskman).
I was told that there seems to be no gain from HT.

50% CPU usage on a CPU with Hyperthreading equals 100% CPU usage on a Non-Hyperthreading CPU.

So even if you see \"only\" 50% CPU usage on your Core i7, the encoding speed will still be much faster than on a Core2 at 100% CPU usage (with the same number of physical cores), because x264 runs generally faster on Core i7.

Furthermore, if the CPU usage doesn\'t exceed 50%, there obviously is some bottleneck, probably in the decoder and/or the filters you use. x264 cannot encode faster than input data is passed to it! It\'s also possible that the single-threaded part in x264 becomes the bottleneck, if you use \"fast\" encoder settings. This won\'t happen with \"slow\" settings. Note that with my builds the first pass of a 2-Pass encode will use \"turbo\" (very fast) settings, so it\'s likely to see low CPU usage in the first pass. Just wait for the second pass. Or, if you use CRF, use slower settings...

encoding with xvid around 30% cpu usage.

Xvid\'s multi-threading implementation is crappy. And development of Xvid is pretty much dead...

[LoRd_MuldeR]

libx264 SVN-r1360:
[list=*]

• libx264-r1360, MinGW GCC 4.4.2, optimized for Core 2[/*]
  
• libx264-r1360, MinGW GCC 4.4.2, optimized for K10[/*]
  
• libx264-r1360, MinGW GCC 4.4.2, optimized for Pentium III[/*]
  
• libx264-r1360, MinGW GCC 4.4.2, without ASM (slow!)[/*]
  

These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 or later now!

[cbike]

libx264 SVN-r1360:

Oops! (404)
We can\'t find the page you\'re looking for. Check out our FAQ or forums for help. Or maybe you should try heading home.

[LoRd_MuldeR]

libx264 SVN-r1360:

Oops! (404)
We can\'t find the page you\'re looking for. Check out our FAQ or forums for help. Or maybe you should try heading home.

Yes, DropBox has disabled public download for my account. They say: Too much traffic :rolleyes:

Well, I know it\'s a free service and I can\'t complain. But if they say \"no limit on traffic\", I\'d expect they keep their promise.

I will re-upload the files somewhere else, as soon as I get back home...

[LoRd_MuldeR]

libx264 SVN-r1360:
[list=*]

• libx264-r1360, MinGW GCC 4.4.2, optimized for Core 2[/*]
  
• libx264-r1360, MinGW GCC 4.4.2, optimized for K10[/*]
  
• libx264-r1360, MinGW GCC 4.4.2, optimized for Pentium III[/*]
  
• libx264-r1360, MinGW GCC 4.4.2, without ASM (slow!)[/*]
  

These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 or later now!

Re-uploaded, as the previous mirror, DropBox, is not available anymore. They disabled my account.
Reason: Too much traffic.

[LoRd_MuldeR]

libx264 SVN-r1369:
[list=*]

• libx264-r1369, MinGW GCC 4.4.2, optimized for Core 2[/*]
  
• libx264-r1369, MinGW GCC 4.4.2, optimized for K10[/*]
  
• libx264-r1369, MinGW GCC 4.4.2, optimized for Pentium III[/*]
  
• libx264-r1369, MinGW GCC 4.4.2, without ASM (slow!)[/*]
  

These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 or later now!

MB-Tree + B-Pyramid works now! Also slice-based threading is back (optionally), but cannot be used with Avidemux yet - that\'s not a big loss, as it\'s less efficient than the \"normal\" frame-based threading anyway.

[LoRd_MuldeR]

libx264 SVN-r1373:
[list=*]

• libx264-r1373, MinGW GCC 4.4.2, optimized for Core 2[/*]
  
• libx264-r1373, MinGW GCC 4.4.2, optimized for K10[/*]
  
• libx264-r1373, MinGW GCC 4.4.2, optimized for Pentium III[/*]
  
• libx264-r1373, MinGW GCC 4.4.2, without ASM (slow!)[/*]
  

[list=*]

• libx264-r1373, MinGW GCC 4.5.0, optimized for Core 2[/*]
  
• libx264-r1373, MinGW GCC 4.5.0, optimized for K10[/*]
  
• libx264-r1373, MinGW GCC 4.5.0, optimized for Pentium III[/*]
  
• libx264-r1373, MinGW GCC 4.5.0, without ASM (slow!)[/*]
  

These builds will NOT work with Avidemux 2.5.0 or older. Please update to Avidemux 2.5.1 r5602 or later now!

This build fixes a crash introduced in the previous build. People are highly encouraged to update asap!