x264 OpenCL

[aegisofrime]

Now before you guys groan and say "Oh not another noob asking for a GPU accelerated OpenCL", take a look at this article first:

http://www.anandtech.com/show/5835/testing-opencl-accelerated-handbrakex264-with-amds-trinity-apu

Yes there actually is an implementation of x264 with the lookahead function offloaded to the GPU. And the speed difference is quite impressive actually. Now the question is where can we download it :p

[06_taro]

x264's dev IRC has been testing OpenCL lookahead for months. You can join the IRC, request for the patch, compile a binary, and test or use on your own risk.

[Dark Shikari]

It's buggy and nowhere near ready for serious usage, but you can test it if you want; ask muggs on IRC.

Buggy drivers aren't helping either.

[fields_g]

The open source community thus far hasn't been very interested in supporting Intel's proprietary technologies. As a result, Quick Sync remains unused by the applications we want to use for video transcoding.

I thought there were issues with getting useful APIs from Intel... correct me if I'm wrong.

[Dark Shikari]

Intel provides a very minimal high-level encoding API missing all but the most basic features for video encoding. The low-level API is completely undocumented and barely half existent, and they haven't shown any real interest in exposing it in any real way.

Naturally, it's unsurprising that people aren't interested in something that Intel themselves doesn't seem to care about.

[aegisofrime]

It's buggy and nowhere near ready for serious usage, but you can test it if you want; ask muggs on IRC.

Buggy drivers aren't helping either.

Thanks for the kind reply. I'm assuming that there are some technical competence requirements to be a tester? Seeing as this is beta...

[wiak]

Thanks for the kind reply. I'm assuming that there are some technical competence requirements to be a tester? Seeing as this is beta...
well beta means that is buggy, and people should send in logs/systeminfo and samples of files that fail to encode

:stupid:

nice to see x264 getting opencl support, keep up the awesome work Dark Shikari & you other awesome devs

and it might be useful to make this the offical x264 opencl thread, so people dont post yet more threads about the same subject :)

[RunningSkittle]

unfortunately catalyst driver on linux does not support latest xorg 1.12

many people will be unable to test.

[ajp_anton]

So is this largely thanks to AMD finding uses for their superior iGPU compared to Intel?

What kind of speedup is expected? I know it depends on CPU/GPU, but I'm fine with an "up to" =).

[wiak]

So is this largely thanks to AMD finding uses for their superior iGPU compared to Intel?

What kind of speedup is expected? I know it depends on CPU/GPU, but I'm fine with an "up to" =).
check anandtech arcticke :p
6.98 without OpenCL > 15.01 with OpenCL
and thats on midrange radeon 6000 series class chip, i wonder how it is on a HD 7970 or even HD 7990 when that comes
:stupid:

[ajp_anton]

Haha, forgot they actually tested it =).
But it's still not finished. Is it speed-optimized and just needs some bugs fixed, or will it get even faster?

[aegisofrime]

check anandtech arcticke :p
6.98 without OpenCL > 15.01 with OpenCL
and thats on midrange radeon 6000 series class chip, i wonder how it is on a HD 7970 or even HD 7990 when that comes
:stupid:

Actually I won't be surprised if a discrete card ends up being slower. Remember that the Radeon on Trinity is on the same die. I'm not sure how much sending data over PCI-E and back will affect the speed.

Developers please correct me if I'm saying something stupid.

[JoeH]

Is this currently working (as well as an alpha can work, of course) on NVidia as well as AMD? I know NVidia as implemented OpenCL, but I'm not sure if there implementation is as complete as AMD's.

[JEEB]

Is this currently working (as well as an alpha can work, of course) on NVidia as well as AMD? I know NVidia as implemented OpenCL, but I'm not sure if there implementation is as complete as AMD's.
When I tested the patch the last time, it compiled and worked on my 9600M GS just fine.

Also, the patch is available (http://doom10.org/index.php?topic=2247.0) for public testing by the developer over at Doom10.

[Atak_Snajpera]

I assume that it requires OpenCL 1.1 GPU at least?

[JEEB]

I assume that it requires OpenCL 1.1 GPU at least?
GPU-Z shows my GPU as "Supported profile: OpenCL 1.0" and, unless a lot has changed since I last tested it, it should work just fine :)

[sneaker_ger]

Could you share your build, JEEB?

[aegisofrime]

Could you share your build, JEEB?

Seconded. I tried to patch and compile it myself but I have no idea what to do when it asked for the file to patch :p

[aufkrawall]

Oh yes, that would really be very interesting, even though it's still "alpha".

[spawnbsd]

Could you share your build, JEEB?

I second this, even if its an alpha build, I'd be willing to play with it.

[06_taro]

A test build (http://astrataro.wordpress.com/2012/05/17/x264-test-build-with-opencl-lookahead/)

Compiled with APP's SDK. Can also run on NVidia cards, but not sure if it would be faster or not on NV cards when compiled with CUDA SDK....

[sneaker_ger]

Thx.
Crashes my graphic driver, so beware!
Radeon HD 5850, Catalyst 12.4, Win7 x64

[06_taro]

Actually crashed once in about 10 tests on my HD6770M, Catalyst 12.3, Win7 x64. :P

[sneaker_ger]

Then you have more luck than me. Mine crashes 60% of the time .... every time.
The BSOD right now was probably my PC telling me it's time to stop trying.

[06_taro]

Oops, that's terrible....

The only case it crashed was when I use Ctrl+C to terminate the process, which now I found is always crashing.
And my friends's GTX460 hadn't met crash in normal usage.
Not sure if 12.4 has any issues with APP runtime or I have any problems with my compiling configure....

[aufkrawall]

It works here but GPU load is very low.
Do I have to consider any commands?

[Audionut]

Looks like the patch has disappeared.

Quick tests on the test build, I'm finding that the higher the encoded bitrate, the lower the performance increase.

dgnv 1440x1080 source, preset veryslow

Around 60% @ 350kbps
45% @ 1500kbps
8% @ 6500kbps

preset medium (default)
12% @ 1500kbps
6% @ 5000kbps

[aegisofrime]

I just tested it. Thanks for the build, 06_taro!

The source file is 4000 frames out of a 720p H.264 file. The source filter is FFVideoSource. No crashes during the test.

Preset was --crf 21 preset "slower". That's it.

Speed wise:

OpenCL: 17.83 fps
Normal: 11.12 fps

The OpenCL version did produce a slightly bigger file, as Anandtech noted. The OpenCL file was 61.6MB and the normal file 60.8MB.

My system:

i7-2600K
16GB RAM
Radeon 7850

Edit: I'm doing more comprehensive tests to determine is the crashes are driver related, or GPU generation related. Perhaps GCN is more stable?

[06_taro]

In my tests opencl lookahead always archives lower ssim with higher bitrate. Tested with --tune ssim --ssim, and with/without --no-opencl.

[aegisofrime]

In my tests opencl lookahead always archives lower ssim with higher bitrate. Tested with --tune ssim --ssim, and with/without --no-opencl.

Could you post a short guide on how to build? I'm just stuck at the part where after I have "patch -p < "C:/x264/OpenCL.diff"", I get a prompt asking me what file I want to patch :p

[06_taro]

Here's a step-by-step guide: How to Compile x264 on 32 & 64 Bit Windows (http://doom10.org/index.php?topic=26.0). The only thing not mentioned in this article is that building x264 with opencl support needs opencl sdk installed in your system. Either CUDA SDK or AMD APP SDK is required. The opencl libs will be checked during configuring.

[aegisofrime]

Here's a step-by-step guide: How to Compile x264 on 32 & 64 Bit Windows (http://doom10.org/index.php?topic=26.0). The only thing not mentioned in this article is that building x264 with opencl support needs opencl sdk installed in your system. Either CUDA SDK or AMD APP SDK is required. The opencl libs will be checked during configuring.

In fact I did use that guide. The unclear part is the patching, because I was prompted for which file to patch. I didn't know what to fill in.

Basically what I did was to save the patch as OpenCL.diff. I then moved this file to my x264 folder.

Here's my build script:

#!/bin/bash -x
set -e
#git clone git://git.videolan.org/x264.git "C:/x264"
patch -p1 < "C:/x264/OpenCL.diff"
cd "C:/x264"
CFLAGS=-march=corei7-avx ./configure --cross-prefix=x86_64-w64-mingw32- --host=x86_64-pc-mingw32 --enable-win32thread --bit-depth=10
make fprofiled VIDS="C:/fprofile.avs"

Did I get the order correct?

Edit: Hmmm maybe my problem was that I didn't have the AMD APP SDK installed? I will install that and try again.

[Audionut]

Can someone also re-upload the patch please.

[aegisofrime]

Can someone also re-upload the patch please.

There ya go:

http://www.mediafire.com/?8qxxp7zbocqn14m

[06_taro]

In fact I did use that guide. The unclear part is the patching, because I was prompted for which file to patch. I didn't know what to fill in.

Basically what I did was to save the patch as OpenCL.diff. I then moved this file to my x264 folder.

Here's my build script:

#!/bin/bash -x
set -e
#git clone git://git.videolan.org/x264.git "C:/x264"
patch -p1 < "C:/x264/OpenCL.diff"
cd "C:/x264"
CFLAGS=-march=corei7-avx ./configure --cross-prefix=x86_64-w64-mingw32- --host=x86_64-pc-mingw32 --enable-win32thread --bit-depth=10
make fprofiled VIDS="C:/fprofile.avs"

Did I get the order correct?

Edit: Hmmm maybe my problem was that I didn't have the AMD APP SDK installed? I will install that and try again.

"cd /c/x264" before patching, then patch.exe will find the files to be patched.

Also note that opencl lookahead doesn't support high bit depth, so don't build 10-bit version.

[Bloax]

Well it's a bit faster @ --preset Medium & --crf 25.05 (and lots of other stuff) here, though with about 1 fps. (Strangely enough --rc-lookahead 80 was almost 2 fps faster than non-ocl)

Of course I just compared it to a x264 build without OCL that I had before.

My silly machine: C2D E8600 @ 3.67 Ghz and a 9800 GT.

If it crashes, then that's a bit unfortunate for it, since the video I tested it on (I was lazy, so it was a 0:29 clip) turned out to be 3 MB bigger than the normal x264.
But yeah, it's a nice feature and all - but it's far from there. :/

[JEEB]

In my tests opencl lookahead always archives lower ssim with higher bitrate. Tested with --tune ssim --ssim, and with/without --no-opencl.
Yes, it isn't using the same algorithms :)

One of the problems for GPU lookahead pretty much seems to have been the fact that you'd have to implement something completely new that would work on the GPU at least with some amount of speed (if not in the context of no such prior art, at least in the context of the application).

Should try building this version of the OpenCL patch with the nvidia's SDK, but I'm lazy to use dlltool on the dot-lib files for mingw (to create dot-a files) .-.

[Przemek_Sperling]

Is this currently working (as well as an alpha can work, of course) on NVidia as well as AMD? I know NVidia as implemented OpenCL, but I'm not sure if there implementation is as complete as AMD's.

The problem is that NV cards are pretty weak in OpenCL
http://vr-zone.com/articles/from-gtc-2012-amd-r7970-preferred-over-nvidia-kepler-in-real-gpgpu-deployments-/15903.html

[zbutsam]

I must be doing something wrong because the OpenCL build is about 2-3% slower with OpenCL activated than with the --no-opencl switch.

My PC is a Core2Duo E8200@3.4 Ghz with an Ati 5850 and Windows XP 32 Professional. I'm running the 11.12 Catalyst drivers which are the last to support OpenCL under XP. I can see my card speeding up from idle when running the OpenCL build but the load stays at 0%. I have tried OpenCL with other tools and benchmarks (to make sure it works) and the GPU load goes to 100%.

My x264 settings are
x264.exe --level 3.1 --preset slow --tune film --crf 20 --vbv-bufsize 14000 --vbv-maxrate 17500 --vbv-bufsize 14000 --vbv-maxrate 17500 -o e:\trailer.mkv e:\trailer.avs

[LoRd_MuldeR]

I must be doing something wrong because the OpenCL build is about 2-3% slower with OpenCL activated than with the --no-opencl switch.

GPUGPU, may it be implemented via OpenCL or via CUDA or via something else, is not the "magic" speed booster that many people seems to think. Just throwing your CPU code on the GPU won't work. Even if you manage to port your CPU code and make it run on the GPU, it will be slow like hell. Getting calculations done one the GPU fast usually requires completely new ideas/algorithms - and that's exactly where all those so-called "GPU Encoders" sacrifice quality for speed to get some nice FPS numbers for the marketing department! And even if you mange to get your calculations done on the GPU fast - and with "fast" I mean significant faster than on a state-of-the-art the CPU - then it's still not guaranteed that you'll see an overall speed-up! Uploading and downloading the data to/from the "device" (graphics card memory) causes a lot of overhead. Only if you still save time including that overhead then you might be able to see some overall speed-up...

In other words: It's very easy to port your CPU-based software to the GPU and get something that runs a lot slower than the original. At the same time getting something that actually runs faster is very difficult and sometimes impossible!

(There are some calculations that are "sequential" by nature and therefore will never run fast on a massively parallel processor, such as a GPU)

[aegisofrime]

GPUGPU, may it be implemented via OpenCL or via CUDA or via something else, is not the "magic" speed booster that many people seems to think. Just throwing your CPU code on the GPU won't work. Even if you manage to port your CPU code and make it run on the GPU, it will be slow like hell. Getting calculations done one the GPU fast usually requires completely new ideas/algorithms - and that's exactly where all those so-called "GPU Encoders" sacrifice quality for speed to get some nice FPS numbers for the marketing department! And even if you mange to get your calculations done on the GPU fast - and with "fast" I mean significant faster than on a state-of-the-art the CPU - then it's still not guaranteed that you'll see an overall speed-up! Uploading and downloading the data to/from the "device" (graphics card memory) causes a lot of overhead. Only if you still save time when considering that overhead you will be able to see some overall speed-up...

(In other words: It's very easy to port your CPU-based software to the GPU and get something that runs a lot slower than the original. At the same time getting something that actually runs faster is very difficult!)

And that might be part of the reason why Trinity sees such a huge speedup. That is assuming that the OpenCL code used by Anandtech is the same as what we have got here.

[mariush]

See http://www.anandtech.com/show/5831/amd-trinity-review-a10-4600m-a-new-hope/2


Trinity still features two 64-bit DDR3 memory controllers with support for up to DDR3-1866 speeds. The controllers add support for 1.25V memory. Notebook bound Trinities (Socket FS1r2 and Socket FP2) support up to 32GB of memory, while the desktop variants (Socket FM2) can handle up to 64GB.

Hyper Transport is gone as an external interconnect, leaving only PCIe for off-chip IO. The Fusion Control Link is a 128-bit (each direction) interface giving off-chip IO devices access to system memory. Trinity also features a 256-bit (in each direction, per memory channel) Radeon Memory Bus (RMB) direct access to the DRAM controllers. The excessive width of this bus likely implies that it's also used for CPU/GPU communication as well.

IOMMU v2 is also supported by Trinity, giving supported discrete GPUs (e.g. Tahiti) access to the CPU's virtual memory. In Llano, you used to take data from disk, copy it to memory, then copy it from the CPU's address space to pinned memory that's accessible by the GPU, then the GPU gets it and brings it into its frame buffer. By having access to the CPU's virtual address space now the data goes from disk, to memory, then directly to the GPU's memory—you skip that intermediate mem to mem copy. Eventually we'll get to the point where there's truly one unified address space, but steps like these are what will get us there.

[Selur]

Gave it a short test spin with the version provided by 06_taro (http://forum.doom9.org/showthread.php?p=1574959#post1574959):
reencoding a small HD sample (8.Birds_1080p24fpsRef4-112Mbps posted by NikosD (http://forum.doom9.org/showthread.php?p=1539255#post1539255))

1st pass:
x264.exe --pass 1 --bitrate 2500 --profile high --level 4.1 --direct auto --b-adapt 2 --rc-lookahead 60 --stats "H:\Temp\sample.stats" --fps 24000/1001 --input-res 1920x1080 --output NUL -
2nd pass:
x264.exe --preset slower --pass 2 --bitrate 2500 --profile high --level 4.1 --ref 4 --vbv-maxrate 62500 --vbv-bufsize 78125 --colormatrix bt709 --stats "H:\Temp\sample.stats" --fps 24000/1001 --input-res 1920x1080 --output "H:\Temp\sample.264" -

normal 64bit version:
1st pass:
x264 [info]: kb/s:2096.56
encoded 543 frames, 17.59 fps, 2096.56 kb/s
2nd pass
x264 [info]: kb/s:2588.30
encoded 543 frames, 9.25 fps, 2588.30 kb/s

openCL 64bit version:
1st pass:
[info]: kb/s:2111.38
encoded 543 frames, 40.3178 fps, 2111.38 kb/s, 5.70 MB
2nd pass:
x264 [info]: kb/s:2571.07
encoded 543 frames, 9.3650 fps, 2571.07 kb/s, 6.94 MB

-> 2nd pass: nearly the same speed (too small difference to be sure it's caused by the mod)
-> 1st pass: more than twice the speed

=> faster 1st pass is nice :)

Cu Selur

Ps.: System I tested it with: Win7pro i7-875k@3.2Ghz, 16GB RAM, Geforce GTX 470

[Audionut]

-> 2nd pass: nearly the same speed (too small difference to be sure it's caused by the mod)
-> 1st pass: more than twice the speed

Considering all the lookahead is performed on the first pass, that's no suprise.

Also, the OpenCL test version you linked is 32bit.

[Selur]

Also, the OpenCL test version you linked is 32bit.
the x264_rev2197+666_tMod-opencl.7z I downloaded contains a 'x264_64_tMod+MixAQ+OpenCL-8bit-420' I figured that that would be a 64bit version,...

[06_taro]

You can use --no-opencl to disable opencl lookahead, and thus difference in build version should be avoided.

[Selur]

this time I took a 720p source, used crf and 2pass 1st encoding and always the opencl binary:

opencl:
x264 --preset slower --crf 18 --input-res 1280x720 --output "H:\Output\test.mp4" -
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: OpenCL: NVIDIA Corporation GeForce GTX 470
x264 [info]: profile High, level 4.0
x264 [info]: ...
x264 [info]: kb/s:1667.89
encoded 33974 frames, 24.2183 fps, 1667.89 kb/s, 270.20 MB
x264 [info]: ...
x264 [info]: encoding duration 0:23:23
normal:
x264 --preset slower --crf 18 --input-res 1280x720 --no-opencl --output "H:\Output\test.mp4" -
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.0
x264 [info]: ...
x264 [info]: kb/s:1650.22
encoded 33974 frames, 23.2390 fps, 1650.22 kb/s, 267.34 MB
x264 [info]: ...
x264 [info]: encoding duration 0:24:22


I also did a 1st pass comparison.
opencl:
x264 --pass 1 --bitrate 1500 --stats "H:\Output\test.stats" --input-res 1280x720 --output NUL -
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: OpenCL: NVIDIA Corporation GeForce GTX 470
x264 [info]: profile Main, level 3.1
x264 [info]: ...
x264 [info]: kb/s:1522.79
encoded 33974 frames, 171.3133 fps, 1522.79 kb/s, 246.69 MB
x264 [info]: ...
x264 [info]: encoding duration 0:03:18


normal:
x264 --pass 1 --bitrate 1500 --stats "H:\Output\test.stats" --no-opencl --input-res 1280x720 --output NUL -
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile Main, level 3.1
x264 [info]: ...
x264 [info]: kb/s:1523.24
encoded 33974 frames, 124.5961 fps, 1523.24 kb/s, 246.77 MB
x264 [info]: ...
x264 [info]: encoding duration 0:04:32

Cu Selur

[hajj_3]

we have only got opencl 1.0 on core i5 1st gen i believe. Wonder if someone could test that without a 3rd party gpu and see if there is any difference. This OpenCL support looks incredible, so much faster on 1st pass!

[wiak]

we have only got opencl 1.0 on core i5 1st gen i believe. Wonder if someone could test that without a 3rd party gpu and see if there is any difference. This OpenCL support looks incredible, so much faster on 1st pass!
it looks promising yes, lets hope they will release stable version before end of this year

[duncanvdlinden]

It still crashes on my system.
When i start encoding (with an AVS file) it don't start and my graphics driver crashed.
Invy Bridge 3770K
AMD HD6770
Win7 X64

Same encoding on an system from a friend with Nvidia GTX680, no problem at all.

Have tried:
Catalyst 12.4 and 12.5 beta
AMD APP SDK 2.6 and 2.7.
Disabled the onchip Intel HD4000 graphics
32bit and 64bit opencl version from 06_taro

[Gser]

Yup crashes on win7 x64, 5870 as well. Catalyst 11.4

[Snowknight26]

You're 12 versions behind on your GPU drivers.

[duncanvdlinden]

Ok it working now :) :
Uninstalled 12.5 beta (including APP SDK 2.6)
Installed 12.4
installed App SDK 2.6

Testing now...

[Gser]

You're 12 versions behind on your GPU drivers.

Typo, just updated them today. I'm at 12.4.

[duncanvdlinden]

If you had app SDK 2.7 before, try to uninstall everything from AMD, the drivers and the SDK (it's all in one and the same uninstaller), if you have multiple GPU's disable the others. Then, install catalyst 12.3, and APP SDK 2.6. Then it works on my system.

After that i have enable my onboard GPU again (use it for Intel Quicksync), the OpenCL X264 still working.

I don't know if all the things I mention makes sense, but that's wat I did and work with an AMD HD6770.

[Snake91]

mmm will there be opencl boost in crf mode too?

[deekey777]

GPUGPU, may it be implemented via OpenCL or via CUDA or via something else, is not the "magic" speed booster that many people seems to think. Just throwing your CPU code on the GPU won't work. Even if you manage to port your CPU code and make it run on the GPU, it will be slow like hell. Getting calculations done one the GPU fast usually requires completely new ideas/algorithms - and that's exactly where all those so-called "GPU Encoders" sacrifice quality for speed to get some nice FPS numbers for the marketing department! And even if you mange to get your calculations done on the GPU fast - and with "fast" I mean significant faster than on a state-of-the-art the CPU - then it's still not guaranteed that you'll see an overall speed-up! Uploading and downloading the data to/from the "device" (graphics card memory) causes a lot of overhead. Only if you still save time including that overhead then you might be able to see some overall speed-up...

In other words: It's very easy to port your CPU-based software to the GPU and get something that runs a lot slower than the original. At the same time getting something that actually runs faster is very difficult and sometimes impossible!

(There are some calculations that are "sequential" by nature and therefore will never run fast on a massively parallel processor, such as a GPU)

So, it's time for PCIe 3.0?
http://www.hardwaresecrets.com/article/AMD-Radeon-HD-7970-Video-Card-Review/1458/13

[LoRd_MuldeR]

Well, PCIe 3.0 might be able to speed-up the upload/download delays quite a bit. Still, having to upload all data from CPU memory to GPU memory before you can access it in your GPU program ("kernel") and later downloading all the results again is orders of magnitude slower than accessing the data right away from CPU memory. PCIe 3.0 won't change this fundamentally, I think. Also the "Unified Addressing" now available in CUDA, which means you don't have to distinguish between device pointers and host pointers, may be a simplification for the programmer, but it doesn't change the fact that all data needs to be transferred over the Bus at some point in time. Furthermore, the "on board" (or "on CPU") GPU's may come at the advantage that they use the main memory as graphics memory, so ideally nothing needs to be copied between different memories. But on the other hand the CPU's main-memory interface may now become the bottleneck, if both, the CPU itself and its built-in GPU, heavily access the main memory. Last but not least all "on board" (or "on CPU") graphics chips are relatively weak GPU's. They have become better recently, yes. Still even a cheap dedicated Graphics Cards easily rules out the built-in CPU graphics chip. High-end cards are from another world. After all you won't be able to benefit from GPUPU, unless your GPU program ("kernel") runs sufficiently long to "hide" the upload/download delays. Some "Pipelining" might also help...

[sborho]

You need a fairly recent discrete GPU to get really obvious performance improvements, and even then, the best it can do is make the lookahead fast. If the lookahead was not the bottleneck, the encode will not go a lot faster (you only get the off-load benefit of doing the work on the GPU)

For AMD GPUs, you need the latest Catalyst drivers (at least 12.3) to get some required compiler fixes. There is a known issue that seems to affect many Radeon HD 6xxx GPUs that causes driver resets when the intra analysis kernel runs. AMD is investigating.

[Audionut]

and even then, the best it can do is make the lookahead fast.

There's probably a reason it's called OpenCL lookahead. ;)

[hajj_3]

i wonder if these intel docs just released will help us with utilising intel's chips to do hardware encoding: http://hardware.slashdot.org/story/12/06/23/1635238/intel-releases-ivy-bridge-programming-docs-under-cc-license

[CruNcher]

There's probably a reason it's called OpenCL lookahead. ;)

Yes though AMD advertises it like it's the holly grail in the press ;)

looks like the guys who implemented it are currently on a OpenCL run http://www.multicorewareinc.com/index.php?option=com_content&view=article&id=76&Itemid=86

Though im really surprised that AMD didn't acquired them yet seeing how much work they do for them though they seem to position in the middle and leave cuda and opencl left and right of them Dancing on both Parties ;)


So i did my own OpenCL lookahead benchmarks

460 GTX

No OpenCL 64 = 120W = 103 fps = 52 sec = SSIM Mean Y:0.9658581

OpenCL 64 = 175W = 125 fps = 42 sec = SSIM Mean Y:0.9655919 / PSNR Global 39.658

+ 55W = + 22 fps = - 10 sec (30% GPU Utilization) (130% Overall System Utilization)


X264 High Speed Quality (HSQ) 32bit = 125W = 190 fps = 28 sec = PSNR Global 39.534 / 40.097 (100% Overall System Utilization)

X264 High Speed Quality (HSQ) 64bit = 125W = 194 fps = 27 sec = PSNR Global 39.534 / 40.097 (100% Overall System Utilization)

Nvidia Cuda Encoder 32 bit = 180W = 193 fps = 27 sec = PSNR Global 39.649 = (110% Overall System Utilization)

[fields_g]

i wonder if these intel docs just released will help us with utilising intel's chips to do hardware encoding: http://hardware.slashdot.org/story/12/06/23/1635238/intel-releases-ivy-bridge-programming-docs-under-cc-license

That's why I just came back to this thread... wondering if the new docs were any use.

Direct Link: http://intellinuxgraphics.org/documentation.html

[hajj_3]

Does anyone know about any new progress on OpenCL x264 encoding support?

[Filker]

Does anyone know about any new progress on OpenCL x264 encoding support?

"A publicly available, OpenCL-enabled version of x264 should be out as early as next month. Luckily, we didn't have to wait—we secured a build of Handbrake that includes a pre-release, hardware-accelerated x264 encoder, and we've posted the results alongside our data from MediaEspresso and MediaConverter."

http://techreport.com/articles.x/23324

[Bloax]

It's a bit silly they used a very high motion shot for comparing reasons, unsurprisingly it looked the worst in x264, because it's actually smart enough not to allocate too many bits to a part you won't be able to really follow in detail.

[Keiyakusha]

It's a bit silly they used a very high motion shot for comparing reasons, unsurprisingly it looked the worst in x264, because it's actually smart enough not to allocate too many bits to a part you won't be able to really follow in detail.
BTW this x264 behavior really bugs me. Lets say I can spare a lot of bitrate to make everything look perfect. When most of the movie IS perfect - parts with high motion look too bad they even have blocks. Of course I can't see this is motion, only in artificial comparison. If I will rise bitrate to make fast motion look good too, other parts recieve overkill amount of bitrate so now look not only good but virtually lossless... If this is what CRF brings to us, maybe its time to go qp? ^__^

[Dark Shikari]

The problem is that x264 doesn't know what "perfect" is, since it doesn't have any code to do something on the order of a "just-noticeable differences" metric. It only knows varying levels of quality, not what the cutoff is for "you can't see any difference". And "you can't see any difference" is going to vary a lot depending on how you watch the video, too. If it did, it would be able to cap the quality in areas of the video that are lower-complexity, freeing up bits for the other areas.

[SassBot]

Of course I can't see this is motion, only in artificial comparison.

So then what exactly is the problem? Do you routinely watch movies by single stepping?

[Keiyakusha]

So then what exactly is the problem? Do you routinely watch movies by single stepping?
I don't watch anything I'm backuping. If I do some encoding - I watched this already and maybe even more than once. The goal is to make it look as close to the original as possible.
And here is my observation (not a complaint or something):
every time when I pick x264 settings in a way that scenes with fast motion will look like original (minus some loses in grain and stuff) - other more static parts, which are usually most of the show recieve overkill amount of bitrate.
If something will happen with original BD, I don't want to have backup with some parts of it in lower quality regardless of can I see it or not.
EDIT: of course i can use qpfile or something but this is too much work.

[Dark Shikari]

If you want to reduce that effect, raise qcomp. Watch out: it'll make the lower complexity areas worse, since the bits don't come from nowhere.

[turab]

I don't watch anything I'm backuping. If I do some encoding - I watched this already and maybe even more than once. The goal is to make it look as close to the original as possible.
And here is my observation (not a complaint or something):
every time when I pick x264 settings in a way that scenes with fast motion will look like original (minus some loses in grain and stuff) - other more static parts, which are usually most of the show recieve overkill amount of bitrate.
If something will happen with original BD, I don't want to have backup with some parts of it in lower quality regardless of can I see it or not.
EDIT: of course i can use qpfile or something but this is too much work.
If you want every frame to have the same quality regardless of motion, I believe --no-mbtree will work.

[Bloax]

If you want every frame to have the same quality regardless of motion, I believe --no-mbtree will work.
I think that would be --q-comp 1

[Andouille]

--q-comp 1turns completely off constant quality by turning on constant quantizer.
Who really wants this ??

[mandarinka]

It won't force constant quantizer, AQ will still be enabled IIRC.
I never tried that, I do encode with raised qcomp (default is 0.6) often, though. With mbtree, it helps more often than with pre-mbtree rate-control (IIRC).

[zerowalker]

Can i get the latest x264 build with Opencl x64 :)?
If it´s available.

[Filker]

benchmark of x264 opencl accelerated version on Trinity A10M vs i5.

https://reviews.handbrake.fr/r/328/

https://forum.handbrake.fr/viewtopic.php?f=11&t=24966&p=115091&hilit=opencl#p114793
" The executive summary is that an i5 CPU unaccelerated beats an accelerated amd trinity in nearly all categories. And the only workloads where accelerated trinity beats unaccelerated trinity by any significant margin is when downscaling is being done during the encode."

I hope the top of the line A10 Desktop gets better results.

[deadrats]

with regards to all the OCL benchmarks it seems to me that the testers are missing the point of having the lookahead function hw accelerated.

as a general rule of thumb setting the lookahead to higher values results in higher quality and/or stability as per:

http://mewiki.project357.com/wiki/X264_Settings#rc-lookahead

with normal software based lookahead setting this value to the max 250 slows down the encoding by quite a bit. since this is an easily parallelizable function and thus ideally suitable for gpu acceleration, an OCL enabled x264 build will allow end users to max out this setting, thus increasing the quality of the encode, without having to worry about the performance impact.

basically the proper way to test/see the benefits of OCL lookahead is to run 2 test encodes, where the exact same settings are used (including rc_lookahead=250) and compare the encode times (and resulting quality) with a pure software build of x264 and the OCL enabled build of x264.

i think we will find that the speed discrepancy between the 2 builds will be significant.

[Dark Shikari]

Setting lookahead higher than the defaults is generally useless for compression.

[deadrats]

Setting lookahead higher than the defaults is generally useless for compression.

what about quality?

[Asmodian]

In this context compression is synonymous with quality.

[deadrats]

this then begs the obvious question: if compressibility/quality isn't affected by higher lookahead values, then why bother coding them into the encoder in the first place?

this question applies to a whole bunch of x264 settings, the wiki is full of "this setting should be left at default" or "there's no need to change these settings", well why did the developers code the settings and include them as customizable parameters if they should be touched? just hard code the settings and be done with it.

[Dark Shikari]

rc-lookahead isn't even listed on the main help page. You don't have to touch it, and it's not out in the open to be messed with. Just because it's there doesn't mean you have to put your fingers in it without understanding it first (following that logic would quickly lead to a lack of fingers).

The lookahead is lowered by many faster presets in order to improve speed. We can't simply eliminate it as a parameter.

Not every option is applicable to every use case. It's simply not reasonable to remove all the options that aren't relevant to yours.

[deadrats]

side note, does subme 11 (full rd) not work? i wanted to test it out and set it within the latest video mastering works and xmedia recode but when i analyzed the results with mediainfo it said that subme=9 was used.

i know for subme=10, trellis=2 and aq-mode must be greater than 0 but does that also apply to subme 11?

[Dark Shikari]

Yes, all subme settings are a superset of lower subme settings.

[hajj_3]

@Dark Shikari, do you have an eta as to when OpenCL support will land in a stable build of x264?

[Dark Shikari]

I have no idea. A month, 6 months, never, depending on when people get their act together. Currently, the person responsible for the patch is working on it entirely in his free time, because the contract to write it apparently made no stipulations about actually getting it committed and finished.

[Filker]

http://astrataro.wordpress.com/

x264_rev2216+686_tMod-opencl.7z (test only)

"OpenCL version need --opencl to enable use of opencl lookahead. I did not test it, as it seems broken on my CCC 12.8. The last driver I successfully run it was CCC 12.3 ( or NVidia cards ), compiled with APP v2.6, but this version is compiled with APP v2.7."

Anyone tested it yet?

[sneaker_ger]

I can confirm that it crashes the GPU driver on Catalyst 12.8, HD 5850, Win7 x64, just like the older build...

[Atak_Snajpera]

the whole opencl is a pure madness for programmer. similar problems people have with flac cl . sometimes it works and sometime does not work. developer had to implement many workarounds for specific gpu cards.

[cyberbeing]

Anyone tested it yet?

Works fine on my NVIDIA GT440 DDR5 (864Mhz Core / 1728Mhz RAM), but opencl was ~13% slower at defaults settings on 720p, compared to CPU-only on my i5-3570K @4.4Ghz with near-identical PSNR & SSIM results. GPU load with opencl was 50-80% throughout encoding, but I guess the GT440 DDR5 is just too slow to see any benefit?

[Hiritsuki]

@cyberbeing
maybe it's need more faster gpu card.
I'll test it with GTX670 tomorow.

[Keiyakusha]

On nvidia 5xx generation there is zero benefits too, results vary from the same speed as core I7, to a bit (but just a bit, like 5% max) slower. I don't see it will be better than that, because it doesn't uses much gpu processing power... It just not very optimized or reached some design limits... However I don't know, with latest nvidia drivers opencl apps don't work for me at all :D

[06_taro]

opencl lookahead is implemented in opencl 1.1, and Catalyst 12.4 seems to have made some changes for opencl 1.1->1.2, not sure if it causes this failure or not.

[deadrats]

Works fine on my NVIDIA GT440 DDR5 (864Mhz Core / 1728Mhz RAM), but opencl was ~13% slower at defaults settings on 720p, compared to CPU-only on my i5-3570K @4.4Ghz with near-identical PSNR & SSIM results. GPU load with opencl was 50-80% throughout encoding, but I guess the GT440 DDR5 is just too slow to see any benefit?

really? you're comparing a gt440@864 mhz against a i5-3570@4.4 ghz and you're surprised that the software only version is faster? i'm surprised that the gpu version was only 13% slower.

i would expect a fair test using a better matched video card to be more than just a bit faster and i would expect to really see the difference if you used a lookahead value of 60 frames.

btw, how are you guys testing this build, from the CLI?

[the_weirdo]

really? you're comparing a gt440@864 mhz against a i5-3570@4.4 ghz and you're surprised that the software only version is faster? i'm surprised that the gpu version was only 13% slower.

Oh, that're you again! I'm not going to argue with you, actually I shouldn't, because I know how it'll be ended :sly: However, once again, you don't have any clues from what you say. GPU and CPU have different architectures, and so they also operate differently. That means you're comparing Orange with Apple (uh, I mean Apple the fruit). According to your logic, do you know GT 440 has 96 stream processors (CUDA cores) while i5-3570 has only 4 cores? And you expect we have to compare a 864 Mhz CPU against a 864 Mhz GPU?

I'll stop here and don't expect I'll reply your arguments in this thread again, 'cause like I've said, I shouldn't argue with you.

[Hiritsuki]

ok ... today i'd try it with my gtx480
it's around 6% faster than no gpu acceleration

my pc now is
980X@4.2Ghz
DDR3-1600@24GB@9-11-10-24 1T
N480GTX Lightning Default clock

that my test , the source is same.

my usual setting with opencl
http://i.imgur.com/vaLFk.png

my usual setting without opencl
http://i.imgur.com/RVxY4.png

set placebo with opencl
http://i.imgur.com/6kiDV.png

set placebo without opencl
http://i.imgur.com/R6m0z.png

[deadrats]

According to your logic, do you know GT 440 has 96 stream processors (CUDA cores) while i5-3570 has only 4 cores? And you expect we have to compare a 864 Mhz CPU against a 864 Mhz GPU?

you do know that the term "CUDA core" is primarily a marketing term and that GPU cores are simplistic ALU's whereas cpu cores are ALU's coupled to hybrid SIMD/FP units with either exclusive or inclusive cache hierarchies?

do you also know that Intel and AMD cpu's are primarily CISC architectures whereas gpu's are primarily RISC architectures.

my point was hat he was testing a lower end video card against a upper middle range cpu and harping on the fact that the gpu version was 13% slower.

@Hiritsuki
that's not bad, a 6% speed up for what is essentially "free" and you have an overclocked 6 core beast, a guy with a low end dual core will probably see a much bigger speed up and he doesn't have to spend any dough on new hardware. i see no reason why someone wouldn't use the ocl version as long as they have a decent video card.

[cyberbeing]

really? you're comparing a gt440@864 mhz against a i5-3570@4.4 ghz and you're surprised that the software only version is faster?
I would have expected lookhead offloaded to the GPU to result in the CPU being able to dedicate resources to other encoding tasks and speed up encoding. It would seem that there must be a GPU<->CPU communication penalty, which is greater with the GT440 DDR5 than the speed gain from GPU lookahead. This is after-all a low-end fermi GPU which has poor performance to begin with.

i would expect a fair test using a better matched video card to be more than just a bit faster and i would expect to really see the difference if you used a lookahead value of 60 frames.

I don't have a 'better matched' video card to test, but I ran a couple more CPU-only encodes on the same source with higher --rc-lookahead values:

CPU-only default settings with --rc-lookahead 60 was 11% faster than --opencl
CPU-only default settings with --rc-lookahead 250 was 2% faster than --opencl
CPU-only --preset veryslow --crf 16 was 16% faster than --opencl

Anybody have have a Kepler NVIDIA GPU + overclocked Ivy Bridge which they'd be willing to test?

[Hiritsuki]

that's my conclusion..
It's seem usage rate too low to make faster.

[deadrats]

@cyberbeing and Hiritsuki

perhaps you guys should try a different test, namely in addition to testing with different rc-lookahead values you should also play with lookahead-thread values.

in Hiritsuki's test he set lookahead-thread=3, i'm left to wonder why.

as was pointed out gpu's have hundreds of "cores", why launch only 3 threads with which to process lookahead.

if you guys can, try repeating the tests with the following parameters:

everything as you tested the first time but for the cpu test set the number of lookahead threads equal to the number of cpu threads that each one's processor can simultaneously handle (for cyberbeing it would be 4 and for Hiritsuki it would be 12) and for the opencl test set the rc-lookahead to 60 and the lookahead threads to 100 and see if that greatly shifts the performance data to the gpu's advantage.

also, if you guys are testing with uncompressed sources that's also skewing the results somewhat as most people re-encode already compressed content and so most people would also have a software decoder working in addition to the encode.

[Hiritsuki]

I'd try --lookahead-thread 480
http://i.imgur.com/2Rahj.png

it's limit to 16?

but it's maybe faster.

[cyberbeing]

in Hiritsuki's test he set lookahead-thread=3, i'm left to wonder why.
He has a 6-core CPU with 12 threads through hyper-threading. On his CPU, lookahead-threads=3 likely speeds up encoding.

I have a 4-core CPU with 4 threads without hyper-threading. On my CPU, x264 defaults to lookahead-threads=1. Using more would likely make encoding slower on this CPU because of lack of available threads.

What you're suggesting doesn't sound like a fair test. Setting lookahead-threads=4 on my CPU would result in x264 using 10 threads total (4 lookahead + 6 encoding) which is more than double the threads available on my CPU. And as far as I know, lookahead-threads only affect CPU lookahead and should have no effect on OpenCL lookahead.

--preset veryslow --crf 16 --opencl = 12.75 fps
--preset veryslow --crf 16 --opencl --lookahead-threads 4 = 12.74 fps (margin of error)

--preset veryslow --crf 16 = 14.72 fps
--preset veryslow --crf 16 --lookahead-threads 4 = 14.58 fps (1% slower)

also, if you guys are testing with uncompressed sources that's also skewing the results somewhat as most people re-encode already compressed content and so most people would also have a software decoder working in addition to the encode.

My testing was done with a ~2Mbps 720p 8-bit h.264 source, ffms2 r712-2 software decoding, and astrataro's 32-bit x264 opencl build.

[deadrats]

i think lookahead thread is limited to 100:

http://mailman.videolan.org/pipermail/x264-devel/2012-May/009354.html

normally it defaults to 1/6 the number of threads

also try playing with sync-lookahead as well:

sync-lookahead
Default: auto (bframes+1)
Sets the number of frames to be used as a buffer for threaded lookahead. Maximum Value is 250. Automatically disabled during the 2nd or greater pass or when using sliced threads.
Setting this to 0 disables threaded lookahead, which allows lower latency at the cost of reduced performance.

[deadrats]

What you're suggesting doesn't sound like a fair test. Setting lookahead-threads=4 on my CPU would result in x264 using 10 threads total (4 lookahead + 6 encoding) which is more than double the threads available on my CPU. And as far as I know, lookahead-threads only affect CPU lookahead and should have no effect on OpenCL lookahead.


according to http://mailman.videolan.org/pipermail/x264-devel/2012-May/009354.html lookahead-thread splits rc-lookahead into multiple threads, if rc-lookahead is being processed by the gpu then it stands to reason that you need to increase lookahead-thread to big numbers in order to extract maximum performance from a gpu's ability to handle lots of threads simultaneously.

it seems to me that if you're going to make a fair analysis of what ocl brings to x264 the test should be lookahead-thread=100 and rc-lookahead should be at least 100, maybe even maxed out at 250.

[Dark Shikari]

lookahead-threads is about CPU threads for lookahead slice threading; it has nothing to do with GPUs at all.

[Hiritsuki]

@deadrats

no... it's limited to 16
http://i.imgur.com/AKnIi.png

and ... it's really should be optimized ...

480 and 670 is same fps ...

[Hiritsuki]

if set --sync-lookahead 0
cl will be not accelerat x264

[Hiritsuki]

if set rc-lookahead 250
the gddr will be overused and make error
http://i.imgur.com/U3fH4.png

[Hiritsuki]

rc-lookahead set 0 it's will not to use gddr and gpu's opencl efficacy...

[Kurtnoise]

you know that you can edit your posts ?

[deadrats]

hmm, maybe nvidia's gaming drivers aren't properly optimized for OpenCL applications.

i seem to recall someone speculating of the possibility that discrete graphics gpu's wouldn't benefit all that much from this patch, that only gpu integrated onto the cpu die would really benefit ala AMD's apu's and intel's SB/IB processors.

bummer.

[Hiritsuki]

@Kurtnoise
sorry i forgot it...

@deadrats
i means the software x264 opencl should be optimized....
Not graphic card's driver....
now the x264 opencl is only accelerated the rc-lookahead,it's accelerate a little of all x264's processing.

[Sagittaire]

euh ... OpenCL for lookahead is really out of interest. lookahead is not really important setting for quality. OpenCL for CABAC or RDO will be really more interessing to compare interest with CPU if it's possible to make massive GPU theading for that ... ?

[Hiritsuki]

@Sagittaire
hi, if possible i hope it can accelerat for me&subme

[mandarinka]

I think that the general consensus among people who understand the matter is that RDO and CABAC are *precisely* the parts that cannot be successfully converted into OpenCL to run on GPUs.

[SassBot]

hmm, maybe nvidia's gaming drivers aren't properly optimized for OpenCL applications.

I've run it on both Quadro and GeForce cards. The difference is not nearly as much as you're thinking it would be. The drivers really aren't the issue. With all GPGPU involving discrete GPUs, the latency and transfer speed of the PCI-E bus is the overriding factor since even the peak theoretical rate of a PCI-E 2.0 x16 bus is 8GB/sec. This pales in comparison to the internal memory bandwidth of, for example, a GTX 460 which based on the brand and model I've seen range from 80+GB/sec to over 120GB/sec.

i seem to recall someone speculating of the possibility that discrete graphics gpu's wouldn't benefit all that much from this patch, that only gpu integrated onto the cpu die would really benefit ala AMD's apu's and intel's SB/IB processors.

bummer.

Which is only obvious since they are designed in a way to remove the interconnect bottleneck between the CPU and discrete GPU.

[Sagittaire]

I think that the general consensus among people who understand the matter is that RDO and CABAC are *precisely* the parts that cannot be successfully converted into OpenCL to run on GPUs.

If it's true then OpenCL is definitively out of interest for high quality encoding ...

[Filker]

A10 4600M with Opencl compressing close to i7 2760qm speeds
http://www.youtube.com/watch?v=uOOOTqqI18A&feature=relmfu

Stable x264 opencl release "a couple of months away"

[sneaker_ger]

AMD Catalyst 12.9 (beta) (http://support.amd.com/us/gpudownload/windows/Pages/radeonaiw_vista64.aspx) seems to fix opencl encoding.
between 3% and 4% speed-up for preset medium and preset slower on 1920x816p with HD 5850 and Core-i7 860 in a short test.
(taro's 2216+688: x264_64_tMod+MixAQ-8bit-420-opencl.exe)

[hajj_3]

AMD Catalyst 12.9 (beta) (http://support.amd.com/us/gpudownload/windows/Pages/radeonaiw_vista64.aspx) seems to fix opencl encoding.
between 3% and 4% speed-up for preset medium and preset slower on 1920x816p with HD 5850 and Core-i7 860 in a short test.
(taro's 2216+688: x264_64_tMod+MixAQ-8bit-420-opencl.exe)

Very nice, it will be nice to see a stable version of x264 and a stable new amd driver with a proper review comparing amd, nvidia and intel.

[aegisofrime]

AMD Catalyst 12.9 (beta) (http://support.amd.com/us/gpudownload/windows/Pages/radeonaiw_vista64.aspx) seems to fix opencl encoding.
between 3% and 4% speed-up for preset medium and preset slower on 1920x816p with HD 5850 and Core-i7 860 in a short test.
(taro's 2216+688: x264_64_tMod+MixAQ-8bit-420-opencl.exe)

Unfortunately, the performance speed-up does not justify the power usage of the GPU :(

[hajj_3]

Unfortunately, the performance speed-up does not justify the power usage of the GPU :(

for a standalone gpu maybe but who knows about amd's llano and trinity apu's.

[Atak_Snajpera]

it seems that opencl is only useful for apu. only apu gets noticiable speed up. this is good news for amd because cheaper cpu can be as fast as intel's solution.

[aegisofrime]

for a standalone gpu maybe but who knows about amd's llano and trinity apu's.

That's true...

it seems that opencl is only useful for apu. only apu gets noticiable speed up. this is good news for amd because cheaper cpu can be as fast as intel's solution.

As fast as if only pure transcoding if going on. If one is doing, for example, deinterlacing with QTGMC, the Trinity solution would be slower over. Perhaps much slower.

OF course, I haven't forgotten the price difference. But still, with a quad-core mobile Ivy Bridge going for only US$150 more than a top end Trinity laptop, I would gladly pay the difference.

[Vesdaris]

i tried the latest build from here
http://astrataro.wordpress.com/category/encode/x264/x264-bin/ (x264_rev2216+688_tMod-opencl.7z (test only) )

and though i see that my GPU is being used while encoding process is active ( 7970) but fps is the same if not lower. maybe im doing something wrong

i generally use crf17, slower preset, dxva compatibility custom number of b frames and ref frames(which i select based on a sample encoding), -me tesa --subme 11 --no-fast-pskip . and leave it for a night.

What number of lookahead should i set when using opencl x264 ? i tried standard for this preset 60 and increasing them- didnt see any difference between non opencl and opencled x264

[hackeron]

i tried the latest build from here
http://astrataro.wordpress.com/category/encode/x264/x264-bin/ (x264_rev2216+688_tMod-opencl.7z (test only) )

and though i see that my GPU is being used while encoding process is active ( 7970) but fps is the same if not lower. maybe im doing something wrong

i generally use crf17, slower preset, dxva compatibility custom number of b frames and ref frames(which i select based on a sample encoding), -me tesa --subme 11 --no-fast-pskip . and leave it for a night.

What number of lookahead should i set when using opencl x264 ? i tried standard for this preset 60 and increasing them- didnt see any difference between non opencl and opencled x264

What difference in FPS do you get if you use the ultrafast preset?

[Vesdaris]

i've yet to test it in ultrafast preset, but i did some tests encoding a dvd and there is absolutely no difference or it is quite negligible.(2pass and crf encode, a bit tweaked placebo preset)
GPU load sits at about 35-50% depending on a number of lookahead frames .Having opencl acceleration enabled which in turn helps to reduce CPU load is the only positive side i see about this opencl stuff.

maybe it is supposed to work much better on AMD's APU .

[MMrrTT]

Could someone tell me which one should I use for my i7 and AMD 7950?
http://clip2net.com/clip/m70200/1355454347-clip-2kb.png

Why does it uses my GPU only during first pass? :(

[Blue_MiSfit]

@ MMrrTT: because lookahead only happens in the first pass. The OpenCL patch specifically accelerates lookahead only.

[MMrrTT]

Blue_MiSfit, that is so sad ;( Are there any codecs or encoders that fully supports AMD Stream like others fully support CUDA?

[Racer]

What I really don't unterstande why they always want to boost the performance for the encoding part. In my opinion it would be much better to focus first on decoding what the GPUs can already pretty well. So if there would be something like DGDecNV (right now only for Nvidia) for frameserving/decoding in x264 you would have significantly better performance with less effort.
If also switched from software decoding to DGDecNV and could improve my encoding speed by about 30%.

[sneaker_ger]

30% speed improvement from switching to hardware decoding is very very seldom. Typical speed-ups are in the (low) single digit range. You've either been doing something wrong or have encountered a corner case. The more cpu intensive the x264 settings, the more minor the improvement becomes. And for very fast settings CPU decoding can actually be faster because many hardware decoders were designed with real-time playback in mind.

[Racer]

Yes, I'm using very fast x264 encoding; this was the reason why ffdshow couldn't deliver enough frames on my AMD X6 1045T and x264 never reached 100% cpu load. Right now I'm encoding at 80FPS with DGDecNV and a GT520 (VP5; maximum about 120fps for decoding).
I also had to set the x264 threads to 12 for my AMD X6 as per default it would only use one lookahead thread. I actually need 2 to get 100% cpu load.

[sneaker_ger]

Yes, I'm using very fast x264 encoding; this was the reason why ffdshow couldn't deliver enough frames on my AMD X6 1045T and x264 never reached 100% cpu load.

Which could probably be easily fixed by using multi-threaded source filters like ffms2.

Right now I'm encoding at 80FPS with DGDecNV and a GT520 (VP5; maximum about 120fps for decoding).

Yes, those VP5s are decently fast. Intel hardware decoding is even faster, IIRC.

I also had to set the x264 threads to 12 for my AMD X6 as per default it would only use one lookahead thread. I actually need 2 to get 100% cpu load.

Maybe the devs should consider changing this?
I don't know the exact code, but 6 cores should result in 6 * 1.5 = 9 threads and in return make lookahead threads 9/6 = 1.5 threads which then should be rounded to 2?
Is this not happening?

[itsonlyjustincase]

If you guys want, I can test on a Core i3 540 machine with an AMD Radeon HD 7770 graphics card.
This would probably be the best chance for a discreet GPU to give a speedup.

Just need some rudimentary directions, and possibly a test clip representative of the average movie.

Oh, and I have the patience for Placebo too. 40-hour encodes aren't new to me :)

[Bleck]

If you guys want, I can test on a Core i3 540 machine with an AMD Radeon HD 7770 graphics card.
This would probably be the best chance for a discreet GPU to give a speedup.

Just need some rudimentary directions, and possibly a test clip representative of the average movie.

Oh, and I have the patience for Placebo too. 40-hour encodes aren't new to me :)

Don't waste your time with placebo seriously. Visual difference is 0,001 %. Same with filesize. Placebo was made because people would asked for a maximum settings preset.

[Racer]

What is the status now for x264 OpenCL. Is it already dead?

[MMrrTT]

Would like to try to use x264 with GPU support in Sony Vegas.
Does GPU acceleration work in single pass quantizer based presets?
Are there VFW+OpenCL versions of x264?

[Blue_MiSfit]

@MMrrTT: Why would you ever want to use constant qp mode? This is literally a terrible idea for anything other than developer testing IMO.

I'm not sure if there are VFW + OpenCL builds. I haven't tried to use a VFW build for a few years now...

In Vegas, your best bet is probably to render out lossless and then transcode with x264.

[MMrrTT]

@MMrrTT: Why would you ever want to use constant qp mode? This is literally a terrible idea for anything other than developer testing IMO.That was a stupid advice. Still with low quants it gives very-very good picture. But uses enormous bitrate.

I'm not sure if there are VFW + OpenCL builds. I haven't tried to use a VFW build for a few years now...What do you do to edit video, edit audio and encode the result? Or you just convert videos using console?

In Vegas, your best bet is probably to render out lossless and then transcode with x264.That requires terabytes of storage for my 60-70 minutes video + too much time for encoding. I used to use 2-pass encoding with slow preset, but that takes too much time for me - up to x10 times of video duration. Now I'm looking for the way to get the best possible quality at YouTube and the least time spent for encoding and uploading.

[Sagittaire]

That was a stupid advice. Still with low quants it gives very-very good picture. But uses enormous bitrate.

What do you do to edit video, edit audio and encode the result? Or you just convert videos using console?

That requires terabytes of storage for my 60-70 minutes video + too much time for encoding. I used to use 2-pass encoding with slow preset, but that takes too much time for me - up to x10 times of video duration. Now I'm looking for the way to get the best possible quality at YouTube and the least time spent for encoding and uploading.

- crf mode will be really better.

- x264.exe have directly spliter and decoder filter now. You can use ffmpeg.exe if you want more complete video filtrer.

- what are your source type? I will post the good command line for x264. For 1080p encoding I have half real time encoding (for complete encoding at 2 pass) with my old Q6600 in slowest mode.

[MMrrTT]

- x264.exe have directly spliter and decoder filter now. You can use ffmpeg.exe if you want more complete video filtrer.I don't understand why, but I don't have x264 option in ffdshow.
http://clip2net.com/clip/m70200/1357475866-clip-30kb.png

- what are your source type? I will post the good command line for x264. For 1080p encoding I have half real time encoding (for complete encoding at 2 pass) with my old Q6600 in slowest mode.I use 1080p@30fps MJPEG video, about 180 Mbps bitrate.

[Sagittaire]

I don't understand why, but I don't have x264 option in ffdshow.
http://clip2net.com/clip/m70200/1357475866-clip-30kb.png

I use 1080p@30fps MJPEG video, about 180 Mbps bitrate.

encoding profil please? (resolution, bitrate)

[MMrrTT]

The one I use to prepare video for YouTube upload? I don't have one, cause I'm trying out different ones in order to get maximum quality at appropriate encoding speed. And the limitation is about 20 Gb per file. I don't make videos more than 70-90 minutes and don't upload files larger than 20 Gb. I believe it will be 1080p@30fps, x264, 5.1 high profile, ~15-20 Mbps bitrate @ fast or faster preset.

[Sagittaire]

You upload video at youtube with 1080p30 at 20 Mbps. It's really overkill for streaming, no ... ???

[sneaker_ger]

ffmpeg and ffdshow are not the same. x264 encoding (and probably others, too) has been removed from the latter because no one wanted to maintain them anymore and VfW h.264 encoding is not really recommended anyways. I don't think anyone bothered to make an OpenCL VfW build of x264, but if you really want to use it there should be a Vegas frameserver (->google) which lets you combine Vegas with CLI encoders. But don't expect anything great, as you can see from the results posted here the speed-up will probably not exceed low single digit %.

[Sagittaire]

well try this profil with your 1080p30 MJPEG source. You can expect IMO half real time speed encoding with your i7 at 3.5 Ghz with really good quality (Blu Ray quality)

@REM -----------------------------------------------------------
@REM
@REM Profil BluRay Ripp 1080p BD9 64 bits
@REM
@REM -----------------------------------------------------------


x264\x264_64.exe --video-filter resize:1280,720 --demuxer lavf --slow-firstpass --bframe 3 --b-pyramid "strict" --b-adapt 1 --weightp 1 --ref 1 --direct auto --deblock -1:-3 --bitrate 15000 --pass 1 --stats "x264\test.log" --qcomp 0.80 --ipratio 1.00 --pbratio 1.00 --min-keyint 1 --partitions "none" --me "dia" --subme 5 --deadzone-inter 4 --deadzone-intra 4 --psy-rd 1.0:0.25 --aq-mode 1 --aq-strength 0.5 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 300 --open-gop --slices 1 --sar 1:1 -o NUL sample\sample.avi

x264\x264_64.exe --demuxer lavf --bframe 3 --b-pyramid "strict" --weightp 1 --ref 3 --direct auto --deblock -1:-3 --bitrate 15000 --pass 3 --stats "x264\test.log" --qcomp 0.80 --ipratio 1.00 --pbratio 1.00 --min-keyint 1 --partitions "all" --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --deadzone-inter 4 --deadzone-intra 4 --trellis 1 --psy-rd 1.0:0.25 --aq-mode 1 --aq-strength 0.5 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 300 --open-gop --slices 1 --sar 1:1 --psnr --ssim -o sample\1080p_64.mp4 sample\sample.avi

[MMrrTT]

You upload video at youtube with 1080p30 at 20 Mbps. It's really overkill for streaming, no ... ???At first I though I could reach some threshold of bitrate which YouTube won't convert and will just show directly. But YouTube converts everything. So, I've decided to upload videos at maximum quality. The more bitrated videos I upload the less squares I see after YouTube convertion. So, when I use 2-pass bitrate based encoding I choose it ~20 Mbps or something like 20-50 in Premiere. By the way, I've to test CFR encoding.

ffmpeg and ffdshow are not the same. x264 encoding (and probably others, too) have been removed from the latter because no one wanted to maintain them anymore and VfW h.264 encoding is not really recommended anyways. I don't think anyone bothered to make an OpenCL VfW build of x264, but if you really want to use it there should be a Vegas frameserver (->google) which lets you combine Vegas with CLI encoders. But don't expect anything great, as you can see from the results posted here the speed-up will probably not exceed low single digit %.My bad. Now I see.
I think I'm giving up trying to use OpenCL - it's too complicated and unsupported. It doesn't worth it for now.
The latest stable build, I believe, is in the MeGUI and it uses CLI version of x264. So, it is the best variant to encode videos in order to use the latest CLI x264?

[sneaker_ger]

well try this profil with your 1080p30 MJPEG source. You can expect IMO half real time speed encoding with your i7 at 3.5 Ghz with really good quality (Blu Ray quality)
--slow-firstpass? vbv buffer at 30000 with average bitrate 15000, even though this is only for uploading to youtube?
I don't think that's a good profile and it is overly complicated on top of that.

Just use CRF or ABR with a preset of your choice and no vbv.

The latest stable build, I believe, is in the MeGUI and it uses CLI version of x264. So, it is the best variant to encode videos in order to use the latest CLI x264?

Yes, those builds in MeGUI are the de-facto official builds from x264.nl (http://x264.nl) IIRC and are recommended for 99% of all users.

[MMrrTT]

well try this profil with your 1080p30 MJPEG source. You can expect IMO half real time speed encoding with your i7 at 3.5 Ghz with really good quality (Blu Ray quality)Is it with resize up to 720 if I understood it right? I'm considering to move to faster of fast preset instead of slow or slower. It takes too much time with nearly not noticeable improvements. Maybe I'd rather add some bitrate.

Just use CRF or ABR with a preset of your choice and no vbv.I'm trying it out.

[Sagittaire]

--slow-firstpass? vbv buffer at 30000 with average bitrate 15000, even though this is only for uploading to youtube?
That is a shitty profile and an overly complicated command line.

Just use CRF or ABR with a preset of your choice and no vbv.

You don't read my profil or you don't know how work slow-first pass. slow-first pass desactive simply defaut setting for high speed first pass in x264. I use simply another and personal setting for high speed first pass (tiny slower ... but tiny better analyse for second pass). Moreover I use downsizing at 1280x720 for fisrt pass. In these condition CPU computing will be at 80% exclusively for MJPEG decoding ... ;-)

[MMrrTT]

Ok, I see. :) I've tried with this file http://mirror01.x264.nl/x264/64bit/8bit_depth/revision2230/x264.exe but it says it can't find decoder for source video. It is possible to use default system decoder?

[Sagittaire]

vbv buffer at 30000 with average bitrate 15000,

And what is relation between buffer and average bitrate? I don't remove mu vbv setting simply because it certainely will be not use with max bitrate at 40 Mbps. These vbv setting are simple the max vbv setting for blu-Ray encoding.


Just use CRF or ABR with a preset of your choice and no vbv.

with crf you have not size predictiblity. My profil use really high speed first pass if you compare at second pass. And you have size predictibility.


Yes, those builds in MeGUI are the de-facto official builds from x264.nl (http://x264.nl) IIRC and are recommended for 99% of all users.

No bad idea for speed. Megui use avisynth frameserver. Imply slow decoding for MJPEG at 180 Mbps (not multithreading possible her). Imply to use 32 bits version of x264.


My solution is by far the better for quality/speed ... try if you want.

[Sagittaire]

Ok, I see. :) I've tried with this file http://mirror01.x264.nl/x264/64bit/8bit_depth/revision2230/x264.exe but it says it can't find decoder for source video. It is possible to use default system decoder?

actual x264.nl build are buggy. Try with that:
http://jfl1974.free.fr/Software/x264_64.exe

or change decoder from lavf to ffms in command line

[sneaker_ger]

And what is relation between buffer and average bitrate? I don't remove mu vbv setting simply because it certainely will be not use with max bitrate at 40 Mbps. These vbv setting are simple the max vbv setting for blu-Ray encoding.

Yes, they are for Blu-Ray. There's no reason to use them for youtube, even if there's no direct relation between average bitrate and vbv.

with crf you have not size predictiblity. My profil use really high speed first pass if you compare at second pass. And you have size predictibility.

Yes, you cannot predict the size with CRF. But it can save you some uploading time by not going needlessly high with the bitrate.

No bad idea for speed. Megui use avisynth frameserver. Imply slow decoding for MJPEG at 180 Mbps (not multithreading possible her). Imply to use 32 bits version of x264.

MeGUI uses x264 64 bit by default.
I don't know about the MJPEG decoding, but you should be able to use any VfW decoder through AviSource(), or ffms2 or simply pipe from ffmpeg directly. (I didn't comment on the decoding at all, though.)

My solution is by far the better for quality/speed ... try if you want.

Sorry, I will rather use the recommendations of the x264 team. I'm not saying that your profile is insanely bad (but fair enough, my initial wording was too harsh), but I don't think I would recommend it for any beginner. Also, you gave no reasons for many of the options, like b-pyramid strict, weightp 1, your choice of deblocking etc. This is nothing I would recommend to anyone without proper explanations.

[MMrrTT]

actual x264.nl build are buggy. Try with that:
http://jfl1974.free.fr/Software/x264_64.exe

or change decoder from lavf to ffms in command line
Both variants didn't worked :(
http://clip2net.com/clip/m70200/1357485770-clip-22kb.png

I've tried MeGUI with very fast preset @ CFR 19 (--keyint 100) and it encoded at 32fps and the quality is rather nice. It shrank my source file by ~7 times.
Then I've thied it with this file and same settings - ~40fps and

[Sagittaire]

Yes, they are for Blu-Ray. There's no reason to use them for youtube, even if there's no direct relation between average bitrate and vbv.

Well vbv setting will be certainely not use with this average bitrate. And if x264 use it the quality will be really high (max Blu Ray quality). No problem with that ... ;-)



Yes, you cannot predict the size with CRF. But it can save you some uploading time by not going needlessly high with the bitrate.

It's problem if your encoding produce 10 Mbps or 40 Mbps here, isn't it? When you have size limit (20 Go here). You can't use crf encoding.



MeGUI uses x264 64 bit by default.
I don't know about the MJPEG decoding, but you should be able to use any VfW decoder through AviSource(), or ffms2 or simply pipe from ffmpeg directly. (I didn't comment on the decoding at all, though.)

Internal x264 or ffmpeg pipe will be always faster than avisynth pipe. Try if you want.



Sorry, I will rather use the recommendations of the x264 team. I'm not saying that your profile is insanely bad (but fair enough, my initial wording was too harsh), but I don't think I would recommend it for any beginner. Also, you gave no reasons for many of the options, like b-pyramid strict, weightp 1, your choice of deblocking etc. This is nothing I would recommend to anyone without proper explanations.

x264 team recommande to use MeGui? Where? IMO x264 recommand probaly to use internal x264 libavcodec decoding (it's certainly for that the team make implementation, isn't it?). It's by far better way for higher speed decoding than avisynth 64 bit alpha pipe.

[sneaker_ger]

It's problem if your encoding produce 10 Mbps or 40 Mbps here, isn't it? When you have size limit (20 Go here). You can't use crf encoding.

Ok, fair enough. (I did also mention ABR, though)

Internal x264 or ffmpeg pipe will be always faster that avisynth pipe. Try if you want.

I did not suggest otherwise.

x264 team recommande to use MeGui? Where?

No, but the x264 team would recommend using the presets/tunings instead of some overly complicated command-line without any good reasons to deviate from them, regardless of the GUI. They don't really have anything to do with the libav decoding part.

[JoeH]

@MMrrTT: Why would you ever want to use constant qp mode? This is literally a terrible idea for anything other than developer testing IMO.

I'm not sure if there are VFW + OpenCL builds. I haven't tried to use a VFW build for a few years now...

In Vegas, your best bet is probably to render out lossless and then transcode with x264.

The best option for encoding x264 from Vegas is to use the DebugMode FrameServer. Then you can feed Vegas directly into MeGUI or whatever other x264 front-end you like to use.

[MMrrTT]

or change decoder from lavf to ffms in command line"--demuxer auto" helped.

But I'm a little worried about errors.
E:\>x264.bat

E:\>x264_64.exe --video-filter resize:1280,720 --demuxer auto --slow-firstpass -
-bframe 3 --b-pyramid "strict" --b-adapt 1 --weightp 1 --ref 1 --direct auto --d
eblock -1:-3 --bitrate 15000 --pass 1 --stats "test.log" --qcomp 0.80 --ipratio
1.00 --pbratio 1.00 --min-keyint 1 --partitions "none" --me "dia" --subme 5 --de
adzone-inter 4 --deadzone-intra 4 --psy-rd 1.0:0.25 --aq-mode 1 --aq-strength 0.
5 --vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 300 --open-gop --
slices 1 --sar 1:1 -o NUL video.avi
ffms [error]: could not create index
lavf [error]: could not find decoder for video stream
avs [info]: trying AVISource... succeeded
avs [info]: 1920x1080p 1:1 @ 30/1 fps (cfr)
resize [info]: resizing to 1280x720
resize [warning]: converting from bgra to yuv420p
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:1025 Avg QP:23.30 size:156323
x264 [info]: frame P:46715 Avg QP:22.83 size: 84424
x264 [info]: frame B:40316 Avg QP:23.35 size: 30400
x264 [info]: consecutive B-frames: 22.3% 47.4% 7.4% 22.9%
x264 [info]: mb I I16..4: 11.8% 23.1% 65.1%
x264 [info]: mb P I16..4: 16.8% 0.0% 0.0% P16..4: 73.5% 0.0% 0.0% 0.0% 0
.0% skip: 9.7%
x264 [info]: mb B I16..4: 1.9% 0.0% 0.0% B16..8: 40.1% 0.0% 0.0% direct:
17.3% skip:40.7% L0:24.9% L1:28.8% BI:46.3%
x264 [info]: final ratefactor: 21.29
x264 [info]: 8x8 transform intra:2.5% inter:29.0%
x264 [info]: direct mvs spatial:99.1% temporal:0.9%
x264 [info]: coded y,uvDC,uvAC intra: 82.1% 42.4% 14.3% inter: 44.1% 15.0% 1.4%
x264 [info]: i16 v,h,dc,p: 14% 16% 52% 18%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 20% 27% 7% 6% 5% 8% 6% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 18% 15% 8% 9% 8% 11% 8% 12%
x264 [info]: i8c dc,h,v,p: 68% 17% 13% 2%
x264 [info]: Weighted P-Frames: Y:19.8% UV:3.4%
x264 [info]: kb/s:14526.26

encoded 88056 frames, 23.59 fps, 14526.26 kb/s

E:\>x264_64.exe --demuxer auto --bframe 3 --b-pyramid "strict" --weightp 1 --ref
3 --direct auto --deblock -1:-3 --bitrate 15000 --pass 3 --stats "test.log" --q
comp 0.80 --ipratio 1.00 --pbratio 1.00 --min-keyint 1 --partitions "all" --me "
umh" --subme 7 --no-fast-pskip --no-dct-decimate --deadzone-inter 4 --deadzone-i
ntra 4 --trellis 1 --psy-rd 1.0:0.25 --aq-mode 1 --aq-strength 0.5 --vbv-maxrate
40000 --vbv-bufsize 30000 --level 4.1 --keyint 300 --open-gop --slices 1 --sar
1:1 --psnr --ssim -o video.mp4 video.avi
ffms [error]: could not create index
lavf [error]: could not find decoder for video stream
avs [info]: trying AVISource... succeeded
avs [info]: 1920x1080p 1:1 @ 30/1 fps (cfr)
resize [warning]: converting from bgra to yuv420p
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [info]: frame I:1025 Avg QP:31.13 size:161725 PSNR Mean Y:34.30 U:46.63
V:47.96 Avg:35.94 Global:35.34
x264 [info]: frame P:46715 Avg QP:30.68 size: 89084 PSNR Mean Y:34.12 U:47.19
V:48.67 Avg:35.77 Global:34.95
x264 [info]: frame B:40316 Avg QP:32.47 size: 28812 PSNR Mean Y:34.60 U:47.49
V:48.94 Avg:36.24 Global:34.97
x264 [info]: consecutive B-frames: 22.3% 47.4% 7.4% 22.9%
x264 [info]: mb I I16..4: 12.9% 72.4% 14.7%
x264 [info]: mb P I16..4: 2.6% 7.6% 1.1% P16..4: 40.4% 13.3% 15.2% 1.8% 0
.6% skip:17.4%
x264 [info]: mb B I16..4: 0.2% 0.7% 0.1% B16..8: 30.0% 6.9% 2.4% direct:
3.7% skip:56.0% L0:37.8% L1:47.4% BI:14.8%
x264 [info]: 8x8 transform intra:68.2% inter:47.2%
x264 [info]: direct mvs spatial:93.4% temporal:6.6%
x264 [info]: coded y,uvDC,uvAC intra: 67.4% 25.8% 4.3% inter: 24.4% 4.3% 0.6%
x264 [info]: i16 v,h,dc,p: 40% 35% 11% 14%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 11% 37% 6% 6% 7% 6% 7% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 14% 21% 7% 8% 9% 8% 7% 6%
x264 [info]: i8c dc,h,v,p: 83% 9% 7% 1%
x264 [info]: Weighted P-Frames: Y:19.9% UV:3.4%
x264 [info]: ref P L0: 82.8% 12.4% 4.8%
x264 [info]: ref B L0: 88.3% 11.7%
x264 [info]: ref B L1: 97.2% 2.8%
x264 [info]: SSIM Mean Y:0.8977723 ( 9.904db)
x264 [info]: PSNR Mean Y:34.339 U:47.322 V:48.783 Avg:35.985 Global:34.965 kb/s:
14960.17

encoded 88056 frames, 13.08 fps, 14960.18 kb/s

[Sagittaire]

Work perfectly when I create AVI with MJPEG codec in YV12 mode. Your avi files are certainely corrupted. Anyway avisource seem work correctly.

Like you see with your hardware you have ~half real time encoding. Anyway the quality is really low: average q=30 for encoding with 35 dB for OPSNR must be not really high visual quality. Your source must be really noisy (luma and not chroma). Try to denoise your source before encoding.

[MMrrTT]

I can record only with 4:4:4 or 4:2:0 (YUV411 I believe). Would rather use 4:4:4. Can you please tell me in what way this avi is corrupted?

Yes, original was very crispy and sharp. Still when I uploaded it to YouTube I noticed no differences between this video and 4 other I made with XviD and x264 with very different settings (I had files from 2Gb to 16Gb).

[sl1pkn07]

is possible build with intel opencl SDK?

[Filker]

OpenCL version of handbrake:

https://build.handbrake.fr/view/OpenCL/

What is accelerated

- Accelerated Crop and Scaling filter
- DXVA decoding support via LibAV

Coming Soon

- x264 lookahead acceleration.

[Dodgexander]

Anyone know what has happened to the progress of these builds? They have been taken down from the link and an article on the Handbrake FAQ states limitations are what is stopping them from supporting OpenCL

[cyberbeing]

I believe that Dark Shikari found a critical driver conflict between AMD OpenCL and Intel iGPU OpenCL which was breaking things horribly. It wasn't an x264 bug, so an official x264 OpenCL release was put on hold until this is fixed upstream, which may or may not happen anytime soon, if ever. AMD(?) was supposedly investigating if a solution was possible, but so far has come up empty handed.

I haven't really been following this, so anybody in-the-know please correct any inaccuracies.

[Dark Shikari]

I think it'll be released relatively soon, likely before a bugfix (that bug is seriously being looked at by AMD/friends, but might not be fixed any time soon). Just be very cautious when using OpenCL on systems with AMD+Intel dual graphics (i.e. any system with a Sandy/Ivy Bridge and an AMD discrete card).

OpenCL won't be on by default; it's far too buggy for that.

[sl1pkn07]

and nvidia's opencl systems?. have this "issue"?

[Snowknight26]

I believe that Dark Shikari found a critical driver conflict between AMD OpenCL and Intel iGPU OpenCL which was breaking things horribly. It wasn't an x264 bug, so an official x264 OpenCL release was put on hold until this is fixed upstream, which may or may not happen anytime soon, if ever.

Anyone have any further reading on the subject? I'd love to see technical info regarding the issue.

[Dark Shikari]

I have no idea, honestly. All I know is it's some kind of driver conflict related to interactions between the two OpenCL drivers, but it's quite possible even the people trying to fix it aren't quite sure of the details. I'd love to know more.

[Dodgexander]

Very interesting, although I've seen it mentioned a bunch of times that OpenCL isn't worth the extra speed or less flexibility against just using software decoding that it's used both by winzip and Photoshop now to accelerate there processes.

Even more interesting is the inclusion of OpenCL to the haswell gpu architecture.

Perhaps we will start to see a common alternative now to CUDA when it comes to hardware decoding/encoding.

I'm eager to know what the future beholds ;)

Sent from my Blade S using Tapatalk 2

[Mangix]

Perhaps we will start to see a common alternative now to CUDA when it comes to hardware decoding/encoding.

No

You already have Intel QuickSync and DXVA2 to decode it.

GPU based encoding sucks as the quality is bad.

[benwaggoner]

Perhaps we will start to see a common alternative now to CUDA when it comes to hardware decoding/encoding.
Pretty much any GPU that can do CUDA or OpenCL already has hardware H.264 decode.

I think we'll see a bunch of HEVC decoders using CUDA/OpenCL/DirectCompute over the next couple of years. It's the first time we've had very programmable GPUs when a new codec comes out before we have actual HW decoders on the GPUs. And HEVC has some nice features to make highly parallelized decoding more feasible.

[Dodgexander]

I kind of meant for accelerated decoding such as CUDA in lav. Using madvr with CUDA works a lot better than dxva, so why not? Also for amds case of course.

And encode wise, if the architecture is there, why not utilize is?

[mogobime]

Are there any newer official x264 beta builds with openCL-lookahead? The only official compiled version I found was in this planet3dnow-article from June 2012:
http://www.planet3dnow.de/vbulletin/showthread.php?t=406096&garpg=4

Actually I'm doing a lot of tests with the tmod-OpenCL-version and I have no problems and really like it:
http://astrataro.wordpress.com/category/encode/x264/
It speeds up my 1080p encodings around 13-15% when I tune the sync-lookahead and lookahead-threads settings a little.
Until now I could not find any appreciable negative effects on SSIM when the output bitrates are the same (opencl sometimes produced a little bit lower output-bitrates, when using the same bitrate in average bitrate encodes)

[Dodgexander]

I didn't even know those builds existed!

Seems quick sync destroyed the idea of using opencl which is a pain for older systems/amd users.

Sent from my Blade S using Tapatalk 2

[06_taro]

OpenCL lookahead was githubbed (https://github.com/DarkShikari/x264-devel/commit/35d002951c26cb7e60cf27f4f474cfd5aa03cf05). It is likely to be available in the following vanilla builds.

[Selur]

Nice! :D
One thing:
Use --opencl-device N to specify a number of capable GPUs to skip during device detection.
+
--opencl-device <integer> Specify OpenCL device ordinal
-> will '--opencl-device' select a specific device or will it skip the first N detected GPUs and select GPU number N+1 ? (or is this basically the same since numbering starts at 0 and the first OpenCL capable GPU after N will be used ?)
May be it's just me, but this seems a bit confusing. :)

[paradoxical]

I kind of meant for accelerated decoding such as CUDA in lav.

LAV uses CUVID which is just the API for using the GPU's ASIC decoder.

[mogobime]

@06_taro
It is likely to be available in the following vanilla builds.

Do you know more than I do? I'm glad to hear this :)

[Dodgexander]

LAV uses CUVID which is just the API for using the GPU's ASIC decoder.

Thanks! For some reason I thought the two were related.

Sent from my Blade S using Tapatalk 2

[Selur]

Does anyone know a formula which (at least roughly, e.g. a 50MB save zone) estimated the memory consumption when using: rc-lookahead X and sync-lookahead Y and resolution WxH ?
Would be nice to know beforehand a rough number to know if my e.g. 256/512MB/1024MB/... graphic card can handle the memory consumption rc-lookahead using OpenCL would require.

[Selur]

btw. running:
x264_64_tMod-8bit-all.exe --preset slower --tune film --crf 18 --profile high --level 4.1 --rc-lookahead 40 --sync-lookahead 225 --vbv-maxrate 62500 --vbv-bufsize 78125 --colormatrix bt470bg --fps 25000/1000 --opencl --input-res 1920x1080 --output "H:\Output\test.264" -
works fine, around 1500MB of GPU RAM (of 2047MB) are used, but when I call the same with "--rc-lookahead 40 --sync-lookahead 250" it crashed with:
x264 [error]: OpenCL: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAND_NDRANGE_KERNEL on GeForce GTX 660 Ti (Device 0).
x264 [error]: OpenCL: fatal error, aborting encode
x264 [error]: clEnqueueNDRangeKernel error '-4'
x264 [error]: x264_encoder_encode failed
reporting this since I'm not sure if these settings are just to extreme for the hardware or if it's a bug. (btw. I'm running NVIDIA driver 314.07)

NVIDIA System Information report created on: 03/23/2013 20:13:45
System name: QUAD

[Display]
Operating System: Windows 7 Professional, 64-bit (Service Pack 1)
DirectX version: 11.0
GPU processor: GeForce GTX 660 Ti
Driver version: 314.07
Direct3D API version: 11
Direct3D feature level: 11_0
CUDA Cores: 1344
Core clock: 915 MHz
Memory data rate: 6008 MHz
Memory interface: 192-bit
Memory bandwidth: 144.19 GB/s
Total available graphics memory: 4095 MB
Dedicated video memory: 2048 MB GDDR5
System video memory: 0 MB
Shared system memory: 2047 MB
Video BIOS version: 80.04.4B.00.60
IRQ: 0
Bus: PCI Express x16 Gen2
Device Id: 10DE 1183 36603842
Part Number: 2004 0001

[Components]

easyDaemonAPIU64.DLL 1.12.12.0 NVIDIA Update Components
WLMerger.exe 1.12.12.0 NVIDIA Update Components
daemonu.exe 1.12.12.0 NVIDIA Update Components
ComUpdatus.exe 1.12.12.0 NVIDIA Update Components
NvUpdtr.dll 1.12.12.0 NVIDIA Update Components
NvUpdt.dll 1.12.12.0 NVIDIA Update Components
nvui.dll 8.17.13.1407 NVIDIA User Experience Driver Component
nvxdsync.exe 8.17.13.1407 NVIDIA User Experience Driver Component
nvxdplcy.dll 8.17.13.1407 NVIDIA User Experience Driver Component
nvxdbat.dll 8.17.13.1407 NVIDIA User Experience Driver Component
nvxdapix.dll 8.17.13.1407 NVIDIA User Experience Driver Component
NVCPL.DLL 8.17.13.1407 NVIDIA User Experience Driver Component
nvCplUI.exe 7.1.720.0 NVIDIA Control Panel
nvWSS.dll 6.14.13.1407 NVIDIA Workstation Server
nvViTvS.dll 6.14.13.1407 NVIDIA Video Server
NVSTVIEW.EXE 7.17.13.1407 NVIDIA 3D Vision Photo Viewer
NVSTTEST.EXE 7.17.13.1407 NVIDIA 3D Vision Test Application
NVSTRES.DLL 7.17.13.1407 NVIDIA 3D Vision Module
NVMCTRAY.DLL 8.17.13.1407 NVIDIA Media Center Library
nvDispS.dll 6.14.13.1407 NVIDIA Display Server
PhysX 09.12.1031 NVIDIA PhysX
NVCUDA.DLL 8.17.13.1407 NVIDIA CUDA 5.0.1 driver
nvGameS.dll 6.14.13.1407 NVIDIA 3D Settings Server

Cu Selur

[mogobime]

I've build a table that shows different sync-lookahead and rc-lookahead settings that cause problems with gpu memory usage using x264_64_tMod-8bit-all.exe (x264_rev2274+704_tMod-v2-FFmpeg) and doing 1080p encodings.

OO-spreadsheet that shows the tested settings:
ftp://x-quasat.redirectme.net/public/GPU_mem_usage_1080p.ods
html-table that shows the tested settings:
ftp://x-quasat.redirectme.net/public/GPU_mem_usage_1080p.html

dxdiag:
ftp://x-quasat.redirectme.net/public/dxdiag.txt

[zerowalker]

I can´t get opencl to work properly. I get green lines all over the place;S

I do have a card that support opencl: AMD 6970 so i can´t see what the problem is.

EDIT: it seems to go away if i lower the lookahead.

It seems that with Opencl activated, the encoding is alot slower for some reason.

EDIT2:

I seem to get the Green lines randomly, with opencl off or on, i think it´s the tmod x264 that does it, not sure why though.

[06_taro]

tmod used old opencl patch, which was updated a lot in github's dev repo.

amd's opencl runtime had some issues with catalyst 12.4 to 12.9.

What is the command line to re-produce that green line regression?

[mogobime]

@06_taro

do you know any source where I can get newer prebuild binaries of x264 with opencl support?

[zerowalker]

It seems to be completely random, even without Opencl activated, if it´s not always on of course.

And as mogobime, i would like to ask the same.
Or point me towards one git that i can compile myself.

[mogobime]

Actually I'm publishing some speed/quality-tests with TMod x264 OpenCL.

I've build a spreadsheet comparing different bitrates and sync-lookahead settings with standard encoding, x264 OpenCL-encoding and x264 OpenCL encoding with DGDecNV decoding.

I will release some more comparisons in the next days, you can find all here:
http://forum.selur.de/topic249-dgdecnv-gpu-decoding-x264-opencl-lookahead-benchmarks.html

btw, still nobody knows where to get some up to date x264 opencl binaries?

[06_taro]

x264_r2274+opencl.7z (http://tmod.nmm-hd.org/x264/test/x264_r2274%2Bopencl.7z)

plain r2274 plus this (https://github.com/DarkShikari/x264-devel/commit/c902b90bbb6846471a6f22f7377782c89da3052f) new opencl patch

[mogobime]

Nice, thx :)

will publish some tests with this build here (http://forum.selur.de/topic249-dgdecnv-gpu-decoding-x264-opencl-lookahead-benchmarks.html).

In a few minutes for first I will add a spreadsheet with values I detected with a 720p source and the TMod build.

As soon as the 720p tests are finished I will start testing this build.
I'm curious to find out if there are differences, especially concerning to GPU memory usage above 1500MB...

[LoRd_MuldeR]

Only marginally faster with OpenCL on my system: 13.45 fps vs. 13.57 fps with default settings, 2.29 fps vs. 2.32 fps with "slower" preset.

But most important, the OpenCL-enabled build seems to be very slow, regardless of OpenCL enabled/disabled!

Same input with same settings encoded with vanilla x264 r2273 gives me 52.66fps for the default settings and 18.59 fps withe "slower" preset :confused:

System specs: Intel Q6600 with GeForce GTX 660 Ti. Latest drivers installed.

---[x264 OpenCL default]---

D:\Temp\x264_r2274+opencl>x264_64.exe --crf 22 -o NUL E:\Samples\Lossless\soccer.704x576.60fps.avi
avs [error]: failed to load avisynth
raw [info]: 704x576p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: profile High, level 3.0
x264 [info]: frame I:2 Avg QP:33.00 size:286911
x264 [info]: frame P:331 Avg QP:34.00 size:268114
x264 [info]: mb I I16..4: 0.0% 0.0% 100.0%
x264 [info]: mb P I16..4: 97.8% 0.9% 1.3% P16..4: 0.0% 0.0% 0.0% 0.0% 0.0% skip: 0.0%
x264 [info]: 8x8 transform intra:0.9%
x264 [info]: coded y,uvDC,uvAC intra: 100.0% 100.0% 100.0%
x264 [info]: i16 v,h,dc,p: 0% 0% 92% 8%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 3% 9% 56% 5% 5% 4% 6% 4% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 3% 8% 32% 10% 10% 9% 11% 8% 10%
x264 [info]: i8c dc,h,v,p: 90% 1% 0% 9%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: kb/s:53645.37

encoded 333 frames, 13.45 fps, 53645.37 kb/s

D:\Temp\x264_r2274+opencl>x264_64.exe --crf 22 --opencl -o NUL E:\Samples\Lossless\soccer.704x576.60fps.avi
avs [error]: failed to load avisynth
raw [info]: 704x576p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660 Ti
x264 [info]: profile High, level 3.0
x264 [info]: frame I:2 Avg QP:33.00 size:286911
x264 [info]: frame P:331 Avg QP:34.00 size:268115
x264 [info]: mb I I16..4: 0.0% 0.0% 100.0%
x264 [info]: mb P I16..4: 97.8% 0.9% 1.3% P16..4: 0.0% 0.0% 0.0% 0.0% 0.0% skip: 0.0%
x264 [info]: 8x8 transform intra:0.9%
x264 [info]: coded y,uvDC,uvAC intra: 100.0% 100.0% 100.0%
x264 [info]: i16 v,h,dc,p: 0% 0% 92% 8%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 3% 9% 56% 5% 5% 4% 6% 4% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 3% 8% 32% 10% 10% 9% 11% 7% 10%
x264 [info]: i8c dc,h,v,p: 90% 1% 0% 9%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: kb/s:53645.51

encoded 333 frames, 13.57 fps, 53645.51 kb/s

---[x264 OpenCL slower]---

D:\Temp\x264_r2274+opencl>x264_64.exe --crf 22 --preset slower -o NUL E:\Samples\Lossless\soccer.704x576.60fps.avi
avs [error]: failed to load avisynth
raw [info]: 704x576p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: profile High, level 3.1
x264 [info]: frame I:2 Avg QP:32.16 size:302591
x264 [info]: frame P:114 Avg QP:34.00 size:268666
x264 [info]: frame B:217 Avg QP:34.00 size:279163
x264 [info]: consecutive B-frames: 1.8% 1.8% 96.4% 0.0%
x264 [info]: mb I I16..4: 0.0% 0.0% 100.0%
x264 [info]: mb P I16..4: 95.9% 2.2% 0.7% P16..4: 0.3% 0.6% 0.3% 0.0% 0.0% skip: 0.0%
x264 [info]: mb B I16..4: 20.8% 0.0% 27.8% B16..8: 19.6% 20.6% 9.6% direct: 1.7% skip: 0.0% L0:37.8% L1: 5.2% BI:57.1%
x264 [info]: 8x8 transform intra:1.2% inter:69.8%
x264 [info]: direct mvs spatial:0.0% temporal:100.0%
x264 [info]: coded y,uvDC,uvAC intra: 100.0% 100.0% 100.0% inter: 100.0% 100.0% 100.0%
x264 [info]: i16 v,h,dc,p: 0% 0% 81% 18%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 3% 10% 35% 7% 8% 8% 10% 7% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 2% 6% 23% 10% 12% 10% 13% 10% 14%
x264 [info]: i8c dc,h,v,p: 89% 0% 0% 11%
x264 [info]: Weighted P-Frames: Y:1.8% UV:1.8%
x264 [info]: ref P L0: 12.5% 3.5% 14.3% 11.9% 11.7% 12.2% 12.4% 11.0% 10.6%
x264 [info]: ref B L0: 25.0% 18.5% 15.9% 13.0% 11.8% 10.9% 4.9%
x264 [info]: ref B L1: 66.8% 33.2%
x264 [info]: kb/s:55142.02

encoded 333 frames, 2.29 fps, 55142.02 kb/s

D:\Temp\x264_r2274+opencl>x264_64.exe --crf 22 --opencl --preset slower -o NUL E:\Samples\Lossless\soccer.704x576.60fps.avi
avs [error]: failed to load avisynth
raw [info]: 704x576p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660 Ti
x264 [info]: profile High, level 3.1
x264 [info]: frame I:2 Avg QP:32.34 size:299989
x264 [info]: frame P:114 Avg QP:34.00 size:268830
x264 [info]: frame B:217 Avg QP:34.00 size:279275
x264 [info]: consecutive B-frames: 2.1% 0.6% 97.3% 0.0%
x264 [info]: mb I I16..4: 0.0% 0.0% 100.0%
x264 [info]: mb P I16..4: 94.3% 2.7% 1.5% P16..4: 0.4% 0.7% 0.3% 0.0% 0.0% skip: 0.0%
x264 [info]: mb B I16..4: 20.0% 0.0% 29.0% B16..8: 19.6% 20.2% 9.4% direct: 1.8% skip: 0.0% L0:37.9% L1: 5.4% BI:56.7%
x264 [info]: 8x8 transform intra:1.4% inter:69.6%
x264 [info]: direct mvs spatial:0.0% temporal:100.0%
x264 [info]: coded y,uvDC,uvAC intra: 100.0% 100.0% 100.0% inter: 100.0% 100.0% 100.0%
x264 [info]: i16 v,h,dc,p: 0% 0% 81% 18%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 2% 9% 35% 7% 8% 8% 11% 7% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 2% 6% 23% 10% 12% 10% 13% 10% 14%
x264 [info]: i8c dc,h,v,p: 89% 0% 0% 11%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 11.6% 3.8% 13.3% 12.1% 12.1% 14.7% 13.2% 10.4% 8.7%
x264 [info]: ref B L0: 24.6% 18.9% 16.2% 13.2% 12.0% 10.4% 4.7%
x264 [info]: ref B L1: 66.6% 33.4%
x264 [info]: kb/s:55164.78

encoded 333 frames, 2.32 fps, 55164.77 kb/s

---[x264 r2273 vanilla]---

D:\Temp\x264_r2274+opencl>x264_8bit_x64.exe --crf 22 -o NUL E:\Samples\Lossless\soccer.704x576.60fps.avi
ffms [info]: 704x576p 128:117 @ 60062/1001 fps (vfr)
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:25.75 size: 36923
x264 [info]: frame P:297 Avg QP:27.55 size: 9449
x264 [info]: frame B:300 Avg QP:31.16 size: 2217
x264 [info]: consecutive B-frames: 0.7% 97.3% 2.0% 0.0%
x264 [info]: mb I I16..4: 3.6% 72.1% 24.3%
x264 [info]: mb P I16..4: 0.2% 3.9% 1.0% P16..4: 41.0% 17.9% 10.7% 0.0% 0.0% skip:25.4%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 43.5% 5.0% 1.2% direct: 1.3% skip:48.8% L0:36.3% L1:57.5% BI: 6.1%
x264 [info]: 8x8 transform intra:75.5% inter:72.7%
x264 [info]: coded y,uvDC,uvAC intra: 85.7% 64.1% 32.0% inter: 19.3% 8.0% 0.2%
x264 [info]: i16 v,h,dc,p: 14% 67% 2% 17%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 23% 13% 7% 8% 9% 8% 9% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 33% 13% 6% 7% 7% 7% 6% 6%
x264 [info]: i8c dc,h,v,p: 52% 22% 19% 7%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 64.8% 24.0% 7.6% 3.6%
x264 [info]: ref B L0: 92.5% 7.5% 0.0%
x264 [info]: ref B L1: 99.9% 0.1%
x264 [info]: kb/s:2865.85

encoded 600 frames, 52.66 fps, 2865.85 kb/s

D:\Temp\x264_r2274+opencl>x264_8bit_x64.exe --crf 22 --preset slower -o NUL E:\Samples\Lossless\soccer.704x576.60fps.avi
ffms [info]: 704x576p 128:117 @ 60062/1001 fps (vfr)
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:25.28 size: 40919
x264 [info]: frame P:162 Avg QP:27.05 size: 13161
x264 [info]: frame B:435 Avg QP:31.75 size: 2604
x264 [info]: consecutive B-frames: 0.8% 1.0% 19.5% 78.7%
x264 [info]: mb I I16..4: 4.3% 80.4% 15.3%
x264 [info]: mb P I16..4: 0.4% 6.2% 1.1% P16..4: 45.4% 16.5% 14.0% 0.3% 0.0% skip:16.1%
x264 [info]: mb B I16..4: 0.0% 0.2% 0.0% B16..8: 43.0% 6.0% 1.7% direct: 1.9% skip:47.2% L0:40.0% L1:53.2% BI: 6.8%
x264 [info]: 8x8 transform intra:80.1% inter:68.5%
x264 [info]: direct mvs spatial:99.1% temporal:0.9%
x264 [info]: coded y,uvDC,uvAC intra: 88.8% 62.0% 29.5% inter: 15.3% 6.4% 0.2%
x264 [info]: i16 v,h,dc,p: 15% 65% 4% 16%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 14% 3% 10% 13% 12% 14% 12% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 6% 27% 2% 7% 10% 11% 12% 9% 14%
x264 [info]: i8c dc,h,v,p: 28% 38% 19% 15%
x264 [info]: Weighted P-Frames: Y:0.6% UV:0.6%
x264 [info]: ref P L0: 55.9% 19.1% 12.1% 3.2% 3.0% 2.2% 2.3% 2.0% 0.3% 0.0%
x264 [info]: ref B L0: 89.7% 5.4% 2.1% 1.1% 0.8% 0.5% 0.4%
x264 [info]: ref B L1: 96.9% 3.1%
x264 [info]: kb/s:2710.10

encoded 600 frames, 18.59 fps, 2710.10 kb/s

[Selur]

yup, opencl mainly helps if you: a. use higher resolutions and b. use higher lookahead counts than the default values.

[LoRd_MuldeR]

yup, opencl mainly helps if you: a. use higher resolutions and b. use higher lookahead counts than the default values.

But why is it so much slower than the latest non-OpenCL build, even with OpenCL disabled at runtime? :confused:

I suspect a regression or a build issue... :eek:

[Selur]

I suspect a regression or a build issue...
at least something is fishy ;)

[mogobime]

yup, opencl mainly helps if you: a. use higher resolutions and b. use higher lookahead counts than the default values.

And the lower the bitrate the more it helps to speed up the encode.

But I still didn't test this new plain r2274+opencl build here, only the older Tmod build with opencl support: http://tmod.nmm-hd.org/x264/x264_rev2274%2B704_tMod-v2.7z

[mogobime]

@LoRd_MuldeR
I've tested the build, and encoding-speed is really good, but I do the decoding with mencoder and Hybrid.

Did you see, that your encodes result in a bitrate >50Mbit/s?
This Release is really small (only 1 MB instead of 10), I think there are missing some decoding functions of x264.

[LoRd_MuldeR]

Okay, seemed to be a decoding issue indeed! This time I used FFmpeg for decoding.

Now I get encoding speeds with the OpenCL build that are more similar to those I get with the "vanilla" build:

---[x264 OpenCL]---

D:\Temp\x264_r2274+opencl>ffmpeg.exe -i E:\Samples\Lossless\soccer.704x576.60fps.avi -f yuv4mpegpipe -loglevel panic - | x264_64.exe -o NUL --demuxer y4m -
y4m [info]: 704x576p 128:117 @ 60/1 fps (cfr)
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:26.75 size: 33232
x264 [info]: frame P:297 Avg QP:28.64 size: 7850
x264 [info]: frame B:300 Avg QP:32.21 size: 1971
x264 [info]: consecutive B-frames: 0.7% 97.3% 2.0% 0.0%
x264 [info]: mb I I16..4: 4.4% 73.4% 22.1%
x264 [info]: mb P I16..4: 0.3% 3.8% 0.9% P16..4: 40.3% 15.2% 8.8% 0.0% 0.0% skip:30.8%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 43.3% 4.5% 1.0% direct: 1.2% skip:49.9% L0:37.0% L1:57.9% BI: 5.0%
x264 [info]: 8x8 transform intra:75.9% inter:74.3%
x264 [info]: coded y,uvDC,uvAC intra: 83.1% 59.7% 28.1% inter: 16.4% 6.7% 0.1%
x264 [info]: i16 v,h,dc,p: 15% 65% 2% 18%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 22% 13% 7% 8% 9% 8% 9% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 33% 14% 6% 7% 7% 7% 6% 6%
x264 [info]: i8c dc,h,v,p: 55% 20% 18% 7%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 64.9% 24.8% 7.1% 3.2%
x264 [info]: ref B L0: 92.5% 7.5% 0.0%
x264 [info]: ref B L1: 99.9% 0.1%
x264 [info]: kb/s:2418.02

encoded 600 frames, 41.87 fps, 2418.02 kb/s

D:\Temp\x264_r2274+opencl>ffmpeg.exe -i E:\Samples\Lossless\soccer.704x576.60fps.avi -f yuv4mpegpipe -loglevel panic - | x264_64.exe -o NUL --opencl --demuxer y4m -
y4m [info]: 704x576p 128:117 @ 60/1 fps (cfr)
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660 Ti
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:26.82 size: 33026
x264 [info]: frame P:299 Avg QP:28.73 size: 7727
x264 [info]: frame B:298 Avg QP:32.20 size: 1992
x264 [info]: consecutive B-frames: 1.2% 97.3% 1.5% 0.0%
x264 [info]: mb I I16..4: 4.5% 72.7% 22.8%
x264 [info]: mb P I16..4: 0.3% 3.8% 0.9% P16..4: 40.0% 14.9% 8.5% 0.0% 0.0% skip:31.6%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 43.5% 4.6% 1.0% direct: 1.1% skip:49.6% L0:37.1% L1:58.0% BI: 4.9%
x264 [info]: 8x8 transform intra:75.5% inter:74.5%
x264 [info]: coded y,uvDC,uvAC intra: 83.0% 58.6% 28.3% inter: 16.3% 6.6% 0.1%
x264 [info]: i16 v,h,dc,p: 14% 67% 2% 17%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 22% 13% 7% 8% 9% 9% 9% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 32% 13% 6% 7% 7% 7% 6% 5%
x264 [info]: i8c dc,h,v,p: 55% 20% 18% 7%
x264 [info]: Weighted P-Frames: Y:0.3% UV:0.0%
x264 [info]: ref P L0: 64.9% 24.8% 7.0% 3.3% 0.0%
x264 [info]: ref B L0: 91.8% 8.2% 0.0%
x264 [info]: ref B L1: 100.0% 0.0%
x264 [info]: kb/s:2402.27

encoded 600 frames, 42.54 fps, 2402.27 kb/s

---[x264 r2273 vanilla]---

D:\Temp\x264_r2274+opencl>ffmpeg.exe -i E:\Samples\Lossless\soccer.704x576.60fps.avi -f yuv4mpegpipe -loglevel panic - | x264_8bit_x64.exe -o NUL --demuxer y4m -
y4m [info]: 704x576p 128:117 @ 60/1 fps (cfr)
x264 [info]: using SAR=128/117
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: profile High, level 3.1
x264 [info]: frame I:3 Avg QP:26.75 size: 33231
x264 [info]: frame P:297 Avg QP:28.64 size: 7850
x264 [info]: frame B:300 Avg QP:32.21 size: 1971
x264 [info]: consecutive B-frames: 0.7% 97.3% 2.0% 0.0%
x264 [info]: mb I I16..4: 4.4% 73.4% 22.1%
x264 [info]: mb P I16..4: 0.3% 3.8% 0.9% P16..4: 40.3% 15.2% 8.8% 0.0% 0.0% skip:30.8%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 43.3% 4.5% 1.0% direct: 1.2% skip:49.9% L0:37.0% L1:57.9% BI: 5.0%
x264 [info]: 8x8 transform intra:75.9% inter:74.3%
x264 [info]: coded y,uvDC,uvAC intra: 83.1% 59.7% 28.1% inter: 16.4% 6.7% 0.1%
x264 [info]: i16 v,h,dc,p: 15% 65% 2% 18%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 22% 13% 7% 8% 9% 8% 9% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 33% 14% 6% 7% 7% 7% 6% 6%
x264 [info]: i8c dc,h,v,p: 55% 20% 18% 7%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 64.9% 24.8% 7.1% 3.2%
x264 [info]: ref B L0: 92.5% 7.5% 0.0%
x264 [info]: ref B L1: 99.9% 0.1%
x264 [info]: kb/s:2418.02

encoded 600 frames, 55.19 fps, 2418.02 kb/s

Still, with OpenCL enabled, it's only marginally faster (and that may even be only noise).

Also the "vanilla" build still is clearly faster than the one with OpenCL patch...

[mogobime]

My benchmarks in this OpenCL-testing thread (http://forum.selur.de/topic249-dgdecnv-gpu-decoding-x264-opencl-lookahead-benchmarks.html) showed that with the older Tmod-version the best encoding-speed was reached with mencoder, ffmpeg was slower.

You could also try to encode a 720p sample, opencl should be faster then.

But I will compare with the regular version now.

[mogobime]

I did some CRF18-encodings now with the regular vanilla-build and the one with the OpenCL-patch (720p stuff).

Without OpenCL the patched build was marginal faster (0,6%), with OpenCL enabled the speed gain with the patched build was 3,1% compared to the regular build - less than i achieved with my ABR encodes.
I think it's because CRF18 resulted in a for 720p stuff high bitrate of 6500 kbit/s (in my ABR encodings lower bitrates always were faster).

vanilla build, CRF 18:
mencoder -lavdopts threads=6 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "C:\SSDWOR~1\HBR_Test\8MIN_H~1.MKV" | x264 --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_35_3910_01.264" -


x264 (1 pass) encoding started...
Starting Main@02:30:51.577:
"C:\Program Files\Hybrid\x264.exe" --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_35_3910_01.264" -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [warning]: --ssim used with psy on: results will be invalid!
x264 [warning]: --tune ssim should be used if attempting to benchmark ssim!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 4.2
x264 [info]: frame I:177 Avg QP:15.60 size:135298
x264 [info]: frame P:6165 Avg QP:18.52 size: 44314
x264 [info]: frame B:5987 Avg QP:20.49 size: 17290
x264 [info]: consecutive B-frames: 24.6% 28.5% 10.4% 36.5%
x264 [info]: mb I I16..4: 5.7% 82.9% 11.3%
x264 [info]: mb P I16..4: 1.7% 12.8% 1.0% P16..4: 45.6% 23.2% 10.7% 0.0% 0.0% skip: 5.0%
x264 [info]: mb B I16..4: 0.1% 1.3% 0.1% B16..8: 56.5% 8.9% 2.0% direct: 4.8% skip:26.3% L0:44.1% L1:47.2% BI: 8.7%
x264 [info]: 8x8 transform intra:82.6% inter:61.4%
x264 [info]: coded y,uvDC,uvAC intra: 84.0% 88.8% 51.6% inter: 39.7% 52.3% 22.5%
x264 [info]: i16 v,h,dc,p: 41% 19% 14% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 13% 31% 6% 8% 7% 8% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 18% 19% 7% 10% 9% 9% 7% 7%
x264 [info]: i8c dc,h,v,p: 56% 20% 17% 6%
x264 [info]: Weighted P-Frames: Y:2.6% UV:1.0%
x264 [info]: ref P L0: 57.1% 12.5% 19.8% 10.5% 0.1%
x264 [info]: ref B L0: 81.5% 15.1% 3.5%
x264 [info]: ref B L1: 92.9% 7.1%
x264 [info]: SSIM Mean Y:0.9823529 (17.533db)
x264 [info]: kb/s:6499.54
encoded 12329 frames, 38.42 fps, 6499.54 kb/s
finished after 00:05:21.072
finished...

vanilla build with OpenCL-patch, CRF 18, OpenCL OFF:
mencoder -lavdopts threads=6 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "C:\SSDWOR~1\HBR_Test\8MIN_H~1.MKV" | x264 --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_35_3910_01.264" -


x264 (1 pass) encoding started...
Starting Main@02:07:59.326:
"C:\Program Files\Hybrid\x264.exe" --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_35_3910_01.264" -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [warning]: --ssim used with psy on: results will be invalid!
x264 [warning]: --tune ssim should be used if attempting to benchmark ssim!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile High, level 4.2
x264 [info]: frame I:177 Avg QP:15.60 size:135298
x264 [info]: frame P:6165 Avg QP:18.52 size: 44315
x264 [info]: frame B:5987 Avg QP:20.49 size: 17291
x264 [info]: consecutive B-frames: 24.6% 28.5% 10.4% 36.5%
x264 [info]: mb I I16..4: 5.7% 83.0% 11.3%
x264 [info]: mb P I16..4: 1.7% 12.7% 1.0% P16..4: 45.6% 23.2% 10.7% 0.0% 0.0% skip: 5.0%
x264 [info]: mb B I16..4: 0.1% 1.3% 0.1% B16..8: 56.5% 8.9% 2.0% direct: 4.8% skip:26.2% L0:44.1% L1:47.2% BI: 8.7%
x264 [info]: 8x8 transform intra:82.6% inter:61.3%
x264 [info]: coded y,uvDC,uvAC intra: 84.0% 88.8% 51.6% inter: 39.7% 52.3% 22.5%
x264 [info]: i16 v,h,dc,p: 41% 19% 14% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 13% 31% 6% 8% 7% 8% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 18% 19% 7% 10% 9% 9% 7% 7%
x264 [info]: i8c dc,h,v,p: 56% 20% 17% 6%
x264 [info]: Weighted P-Frames: Y:2.6% UV:1.0%
x264 [info]: ref P L0: 57.1% 12.5% 19.8% 10.5% 0.1%
x264 [info]: ref B L0: 81.5% 15.1% 3.4%
x264 [info]: ref B L1: 92.9% 7.1%
x264 [info]: SSIM Mean Y:0.9823518 (17.533db)
x264 [info]: kb/s:6499.71
encoded 12329 frames, 38.66 fps, 6499.71 kb/s
finished after 00:05:19.059
finished...

vanilla build with OpenCL-patch, CRF 18, OpenCL ON:
mencoder -lavdopts threads=6 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "C:\SSDWOR~1\HBR_Test\8MIN_H~1.MKV" | x264 --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --opencl --opencl-clbin "C:\Users\ANONYM~1\AppData\Local\Temp\x264_lookahead_02_07_38_3510_01.clbin" --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_38_3510_01.264" -


x264 (1 pass) encoding started...
Starting Main@02:13:21.598:
"C:\Program Files\Hybrid\x264.exe" --crf 18 --profile high --level 4.2 --ref 3 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct spatial --b-adapt 1 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 40 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me hex --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --opencl --opencl-clbin "C:\Users\ANONYM~1\AppData\Local\Temp\x264_lookahead_02_07_38_3510_01.clbin" --output "C:\Users\ANONYM~1\AppData\Local\Temp\02_07_38_3510_01.264" -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [warning]: --ssim used with psy on: results will be invalid!
x264 [warning]: --tune ssim should be used if attempting to benchmark ssim!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.2
x264 [info]: frame I:169 Avg QP:15.62 size:137770
x264 [info]: frame P:6170 Avg QP:18.51 size: 44398
x264 [info]: frame B:5990 Avg QP:20.50 size: 17258
x264 [info]: consecutive B-frames: 24.0% 29.6% 11.9% 34.5%
x264 [info]: mb I I16..4: 5.9% 82.7% 11.4%
x264 [info]: mb P I16..4: 1.7% 12.9% 1.1% P16..4: 45.7% 23.4% 10.6% 0.0% 0.0% skip: 4.6%
x264 [info]: mb B I16..4: 0.1% 1.4% 0.1% B16..8: 56.0% 9.1% 2.0% direct: 4.8% skip:26.4% L0:44.1% L1:47.1% BI: 8.8%
x264 [info]: 8x8 transform intra:82.7% inter:61.3%
x264 [info]: coded y,uvDC,uvAC intra: 84.1% 88.9% 51.5% inter: 39.9% 52.4% 22.5%
x264 [info]: i16 v,h,dc,p: 41% 19% 14% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 11% 13% 31% 6% 8% 7% 8% 7% 9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 18% 19% 7% 10% 9% 9% 7% 7%
x264 [info]: i8c dc,h,v,p: 56% 20% 17% 6%
x264 [info]: Weighted P-Frames: Y:2.5% UV:1.0%
x264 [info]: ref P L0: 56.8% 12.5% 20.0% 10.6% 0.1%
x264 [info]: ref B L0: 81.3% 15.3% 3.3%
x264 [info]: ref B L1: 92.8% 7.2%
x264 [info]: SSIM Mean Y:0.9821631 (17.487db)
x264 [info]: kb/s:6498.37
encoded 12329 frames, 39.61 fps, 6498.37 kb/s
finished after 00:05:11.466
finished...


I will repeat this now with CRF 22 and post it here.

EDIT:

Sorry, I was to tired to post here, had to get some sleep first ;)

CRF22 with identical settings didn't really change much, speed gain of regular vanilla build compared to OpenCL-patched vanilla build with OpenCL ON was 4,06%:


vanilla build, CRF 22:

x264 [info]: SSIM Mean Y:0.9709515 (15.369db)
x264 [info]: kb/s:3363.14
encoded 12329 frames, 47.05 fps, 3363.14 kb/s


vanilla build with OpenCL-patch, CRF 22, OpenCL OFF:

x264 [info]: SSIM Mean Y:0.9709510 (15.369db)
x264 [info]: kb/s:3363.02
encoded 12329 frames, 47.25 fps, 3363.02 kb/s


vanilla build with OpenCL-patch, CRF 22, OpenCL ON:

x264 [info]: SSIM Mean Y:0.9707238 (15.335db)
x264 [info]: kb/s:3357.07
encoded 12329 frames, 48.96 fps, 3357.07 kb/s


I'm not sure if it's the CRF mode itself which is slower then my ABR encodings (http://forum.selur.de/topic249-dgdecnv-gpu-decoding-x264-opencl-lookahead-benchmarks.html) done with the older TMod, which seems to act very similar to this build at my system (speed gain with ABR encodings @ 3000 kbit's was about 10-12%).
And I really have no idea why this new patched build is so slow at your system, because at mine with OpenCL disabled it seems to act like the regular build *confused*

Maybe you can try to encode with my CLI with mencoder piping to x264, to figure out if it's the settings or your system, that causes the problem?!?

[mogobime]

I tested the CRF-mode with different settings now (the test settings I used in my test-thread (http://forum.selur.de/topic249-dgdecnv-gpu-decoding-x264-opencl-lookahead-benchmarks.html) for ABR-encoding), and now the encoding was speeded up as I was used to:
Patched vanilla-build with opencl enabled was 13,66% faster then the unpatched build.
Without OpenCL the two builds were equal in speed:

x264 was called with mencoder as before, but the call is missing in the code:

vanilla, CRF 22:


x264.exe --crf 22 --profile high --level 4.2 --ref 6 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 5 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 4 --sync-lookahead 150 --lookahead-threads 4 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --no-psy --weightp 2 --aq-mode 2 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads 16 --sar 1:1 --deblock -1:-1 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "C:\Users\ANONYM~1\AppData\Local\Temp\12_28_44_8010_01.264" -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile High, level 4.2
x264 [info]: frame I:133 Avg QP:19.05 size:118726
x264 [info]: frame P:2698 Avg QP:22.35 size: 26333
x264 [info]: frame B:9498 Avg QP:24.47 size: 7302
x264 [info]: consecutive B-frames: 2.4% 3.7% 6.9% 16.5% 16.4% 54.1%
x264 [info]: mb I I16..4: 15.9% 74.2% 9.9%
x264 [info]: mb P I16..4: 11.9% 17.5% 1.3% P16..4: 38.9% 13.0% 4.9% 0.0% 0.0% skip:12.5%
x264 [info]: mb B I16..4: 1.6% 1.8% 0.1% B16..8: 34.5% 4.0% 0.6% direct: 1.8% skip:55.5% L0:42.0% L1:49.3% BI: 8.7%
x264 [info]: 8x8 transform intra:57.1% inter:66.5%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 60.1% 64.4% 23.0% inter: 14.1% 18.2% 3.4%
x264 [info]: i16 v,h,dc,p: 26% 21% 30% 22%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 17% 31% 5% 7% 7% 7% 6% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 19% 23% 6% 10% 8% 8% 6% 6%
x264 [info]: i8c dc,h,v,p: 53% 23% 19% 4%
x264 [info]: Weighted P-Frames: Y:2.4% UV:1.3%
x264 [info]: ref P L0: 54.9% 15.4% 14.7% 5.7% 5.7% 3.5% 0.2% 0.0%
x264 [info]: ref B L0: 80.0% 12.1% 5.5% 1.8% 0.7%
x264 [info]: ref B L1: 93.4% 6.6%
x264 [info]: SSIM Mean Y:0.9728666 (15.665db)
x264 [info]: kb/s:2533.80
encoded 12329 frames, 34.51 fps, 2533.80 kb/s


OpenCL-patched vanilla with OpenCL ON:


x264.exe --crf 22 --profile high --level 4.2 --ref 6 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 5 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 4 --sync-lookahead 150 --lookahead-threads 4 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions i4x4,i8x8,p8x8,b8x8 --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 7 --cabac --trellis 1 --no-psy --weightp 2 --aq-mode 2 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads 16 --sar 1:1 --deblock -1:-1 --ssim --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --opencl --opencl-clbin "C:\Users\ANONYM~1\AppData\Local\Temp\x264_lookahead_12_28_53_1010_01.clbin" --output "C:\Users\ANONYM~1\AppData\Local\Temp\12_28_53_1010_01.264" -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.2
x264 [info]: frame I:137 Avg QP:19.14 size:116097
x264 [info]: frame P:2657 Avg QP:22.26 size: 26380
x264 [info]: frame B:9535 Avg QP:24.49 size: 7303
x264 [info]: consecutive B-frames: 2.1% 3.5% 6.4% 17.6% 15.9% 54.6%
x264 [info]: mb I I16..4: 16.2% 73.9% 9.9%
x264 [info]: mb P I16..4: 12.2% 18.0% 1.4% P16..4: 38.6% 12.7% 4.7% 0.0% 0.0% skip:12.4%
x264 [info]: mb B I16..4: 1.7% 1.8% 0.1% B16..8: 34.4% 4.1% 0.6% direct: 1.8% skip:55.6% L0:42.1% L1:49.2% BI: 8.7%
x264 [info]: 8x8 transform intra:57.1% inter:66.8%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 60.1% 64.5% 23.2% inter: 13.9% 18.0% 3.3%
x264 [info]: i16 v,h,dc,p: 26% 22% 30% 22%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 17% 31% 5% 7% 7% 7% 6% 7%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 19% 23% 6% 10% 8% 8% 6% 6%
x264 [info]: i8c dc,h,v,p: 53% 23% 19% 4%
x264 [info]: Weighted P-Frames: Y:2.7% UV:1.5%
x264 [info]: ref P L0: 54.4% 15.0% 15.4% 5.8% 5.7% 3.5% 0.2% 0.0%
x264 [info]: ref B L0: 80.1% 12.0% 5.5% 1.7% 0.7%
x264 [info]: ref B L1: 93.5% 6.5%
x264 [info]: SSIM Mean Y:0.9725541 (15.615db)
x264 [info]: kb/s:2524.64
encoded 12329 frames, 39.35 fps, 2524.64 kb/s


At the moment I have no idead what makes the difference...

[mogobime]

To me it seems that increasing bframes from 3->6 increases encoding speed at faster presets than "very slow" - contrary to regular CPU-based lookahead.

Also subme 7 seems to benefit more from OpenCL-lookahead than subme 9.


EDIT 30.03.2013:

CRF22, preset --slower, (sync-lookahead modified to 150), OpenCL OFF:

x264.exe --crf 22 --profile high --level 4.2 --ref 8 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions all --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 9 --cabac --trellis 2 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "..." -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile High, level 4.2
x264 [info]: frame I:140 Avg QP:19.44 size:120148
x264 [info]: frame P:3826 Avg QP:22.08 size: 25941
x264 [info]: frame B:8363 Avg QP:23.83 size: 10445
x264 [info]: consecutive B-frames: 2.2% 4.6% 52.1% 41.1%
x264 [info]: mb I I16..4: 7.0% 82.3% 10.7%
x264 [info]: mb P I16..4: 2.5% 9.8% 0.5% P16..4: 56.8% 11.7% 8.6% 0.1% 0.0% skip:10.0%
x264 [info]: mb B I16..4: 0.2% 1.8% 0.0% B16..8: 50.4% 4.4% 0.8% direct: 5.1% skip:37.3% L0:44.6% L1:50.8% BI: 4.6%
x264 [info]: 8x8 transform intra:80.5% inter:71.4%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 76.9% 76.8% 36.9% inter: 19.3% 32.4% 7.6%
x264 [info]: i16 v,h,dc,p: 38% 21% 15% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 8% 11% 10% 14% 12% 14% 10% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 13% 6% 8% 14% 12% 13% 10% 14%
x264 [info]: i8c dc,h,v,p: 50% 25% 16% 9%
x264 [info]: Weighted P-Frames: Y:2.5% UV:1.4%
x264 [info]: ref P L0: 48.5% 10.9% 16.8% 8.1% 5.1% 4.0% 3.3% 2.1% 1.1% 0.0%
x264 [info]: ref B L0: 74.5% 11.4% 7.1% 2.9% 2.2% 1.3% 0.6%
x264 [info]: ref B L1: 88.0% 12.0%
x264 [info]: kb/s:3299.97
encoded 12329 frames, 17.81 fps, 3299.97 kb/s

CRF22, preset --slower, (sync-lookahead modified to 150), OpenCL ON:

x264.exe" --crf 22 --profile high --level 4.2 --ref 8 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 3 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions all --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 9 --cabac --trellis 2 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --opencl --opencl-clbin "..." --output "..." -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.2
x264 [info]: frame I:139 Avg QP:19.53 size:118485
x264 [info]: frame P:3722 Avg QP:22.11 size: 25743
x264 [info]: frame B:8468 Avg QP:23.82 size: 10457
x264 [info]: consecutive B-frames: 2.3% 4.3% 42.3% 51.1%
x264 [info]: mb I I16..4: 7.5% 81.8% 10.7%
x264 [info]: mb P I16..4: 2.6% 10.2% 0.5% P16..4: 56.5% 11.6% 8.5% 0.1% 0.0% skip:10.0%
x264 [info]: mb B I16..4: 0.2% 1.8% 0.0% B16..8: 50.6% 4.5% 0.8% direct: 5.1% skip:36.9% L0:45.0% L1:50.4% BI: 4.5%
x264 [info]: 8x8 transform intra:80.1% inter:71.6%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 76.5% 76.3% 36.1% inter: 19.1% 32.0% 7.1%
x264 [info]: i16 v,h,dc,p: 38% 21% 15% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 8% 10% 10% 14% 12% 14% 10% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 13% 6% 8% 14% 12% 13% 10% 14%
x264 [info]: i8c dc,h,v,p: 49% 25% 16% 9%
x264 [info]: Weighted P-Frames: Y:2.3% UV:1.3%
x264 [info]: ref P L0: 48.7% 10.9% 17.3% 7.6% 5.1% 4.0% 3.3% 2.1% 1.0% 0.0%
x264 [info]: ref B L0: 74.2% 11.8% 7.1% 2.9% 2.2% 1.3% 0.6%
x264 [info]: ref B L1: 89.4% 10.6%
x264 [info]: kb/s:3257.93
encoded 12329 frames, 18.53 fps, 3257.93 kb/s

->speed increase 4,0%


CRF22, preset --slower, (sync-lookahead modified to 150), bframes increased to 6, OpenCL OFF:

x264.exe --crf 22 --profile high --level 4.2 --ref 8 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 6 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions all --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 9 --cabac --trellis 2 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --output "..." -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile High, level 4.2
x264 [info]: frame I:127 Avg QP:18.98 size:129079
x264 [info]: frame P:2594 Avg QP:21.97 size: 29951
x264 [info]: frame B:9608 Avg QP:23.82 size: 10884
x264 [info]: consecutive B-frames: 1.8% 3.1% 6.2% 15.5% 15.7% 57.3% 0.3%
x264 [info]: mb I I16..4: 6.7% 82.1% 11.1%
x264 [info]: mb P I16..4: 3.3% 12.9% 0.7% P16..4: 53.2% 13.8% 8.1% 0.1% 0.0% skip: 7.9%
x264 [info]: mb B I16..4: 0.2% 1.8% 0.0% B16..8: 49.1% 4.7% 0.9% direct: 5.3% skip:38.0% L0:44.3% L1:50.6% BI: 5.0%
x264 [info]: 8x8 transform intra:80.6% inter:72.2%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 77.3% 78.0% 39.5% inter: 18.1% 31.0% 7.1%
x264 [info]: i16 v,h,dc,p: 38% 22% 15% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 9% 11% 10% 14% 12% 13% 10% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 13% 6% 8% 14% 12% 13% 10% 14%
x264 [info]: i8c dc,h,v,p: 51% 24% 16% 9%
x264 [info]: Weighted P-Frames: Y:2.6% UV:1.4%
x264 [info]: ref P L0: 53.0% 12.9% 14.0% 6.9% 5.8% 3.9% 2.2% 1.2% 0.1% 0.0%
x264 [info]: ref B L0: 78.0% 11.7% 5.7% 2.4% 1.3% 0.6% 0.2%
x264 [info]: ref B L1: 93.1% 6.9%
x264 [info]: kb/s:3222.65
encoded 12329 frames, 17.74 fps, 3222.65 kb/s

CRF22, preset --slower, (sync-lookahead modified to 150), bframes increased to 6, OpenCL ON:

x264.exe" --crf 22 --profile high --level 4.2 --ref 8 --keyint 250 --min-keyint 0 --scenecut 40 --bframes 6 --b-bias 0 --b-pyramid normal --direct auto --b-adapt 2 --lookahead-threads 2 --sync-lookahead 150 --cplxblur 20 --qcomp 0.6 --qblur 0.5 --mbtree --rc-lookahead 60 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --qpmin 0 --qpmax 69 --qpstep 4 --partitions all --8x8dct --no-dct-decimate --me umh --merange 16 --mvrange -1 --subme 9 --cabac --trellis 2 --psy-rd 1:0 --weightp 2 --aq-mode 1 --aq-strength 1 --vbv-maxrate 62500 --vbv-bufsize 78125 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --cqm flat --threads auto --sar 1:1 --deblock 0:0 --colormatrix bt709 --fps 25000/1000 --input-res 1280x720 --opencl --opencl-clbin "..." --output "..." -
raw [info]: 1280x720p 1:1 @ 25/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 660
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.2
x264 [info]: frame I:127 Avg QP:19.12 size:126207
x264 [info]: frame P:2610 Avg QP:22.02 size: 29126
x264 [info]: frame B:9592 Avg QP:23.84 size: 10860
x264 [info]: consecutive B-frames: 1.9% 3.1% 6.6% 16.0% 14.6% 57.5% 0.3%
x264 [info]: mb I I16..4: 6.9% 81.9% 11.2%
x264 [info]: mb P I16..4: 3.4% 12.9% 0.7% P16..4: 53.4% 13.4% 8.0% 0.1% 0.0% skip: 8.1%
x264 [info]: mb B I16..4: 0.2% 1.8% 0.0% B16..8: 49.0% 4.7% 0.9% direct: 5.4% skip:38.0% L0:44.5% L1:50.6% BI: 4.9%
x264 [info]: 8x8 transform intra:80.3% inter:72.4%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 76.9% 77.7% 38.7% inter: 18.0% 30.8% 6.9%
x264 [info]: i16 v,h,dc,p: 38% 22% 15% 26%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 9% 11% 10% 14% 12% 14% 10% 14%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 13% 6% 8% 14% 12% 13% 10% 14%
x264 [info]: i8c dc,h,v,p: 50% 25% 16% 9%
x264 [info]: Weighted P-Frames: Y:2.5% UV:1.3%
x264 [info]: ref P L0: 52.7% 12.6% 14.6% 6.9% 5.7% 3.9% 2.3% 1.3% 0.1% 0.0%
x264 [info]: ref B L0: 77.8% 11.8% 5.7% 2.4% 1.4% 0.6% 0.2%
x264 [info]: ref B L1: 93.1% 6.9%
x264 [info]: kb/s:3182.99
encoded 12329 frames, 19.02 fps, 3182.99 kb/s

-> speed increase 7,2%

[mogobime]

I created some more OpenCL-lookahead/DGDecNV decoding benchmark-spreadsheets in the meantime.
They for example compare the performance of non-standard bframes values and show the performance of opencl-lookahead using the x264 presets:
http://forum.selur.de/post2766.html#p2766

[Dodgexander]

So currently there's no significant performance gain at all by changing b frames? At least for 1080p. Start to compare it to ffmpeg alone and you see an improvement:)

[mogobime]

There is only a significant performance gain improving bframes compared to the established cpu-based lookahead (you can see this at the diff. FPS % column).
Increasing bframes can improve quality at (almost) no speed cost.
For example for me preset --slower with reduced ref=6 and increased bframes=5 performs very good with OpenCL.

ffmpeg:
As you can see in the few tests here (http://forum.selur.de/post2750.html#p2750) posted directly in the thread (not the posted spreadsheets), ffmpeg was slower for me than mencoder, no matter if I used opencl or not.

[Dodgexander]

Thanks for testing this, the results are interesting. I hope for better open-cl support in the future:p

Sent from my Blade S using Tapatalk 2

[mogobime]

I created one more (probably the last) comparison. 1080p source encoded with all x264 presets that support lookahead and with lookahead-threads calculated by x264:
http://forum.selur.de/post2766.html#p2766

[CarlPig]

Where can i get a x264 64-Bit build with OpenCL Patch of just a x264 32-Bit build with OpenCL Patch??

[mogobime]

It has been posted a few posts before already :rolleyes:: http://tmod.nmm-hd.org/x264/test/

[CarlPig]

Thanks for the link.

I will try it out.

[plonk420]

anyone have any luck (or tips for working) with AMD? running 5870 with astrataro's build. using 12.10; supposedly i installed APP 2.7 (tho the DirectComputeBenchmark 0.45b says i'm running 2.5, even after an uninstall where i verified OpenCL stuffs appeared to be uninstalled and non-functional).

edit: with --opencl, the CLI freezes for a short bit, then driver crashes.

[mandarinka]

As a general precaution, try to use the newest possible driver.

[plonk420]

i went from the newest drivers (which crashed on my first attempts) to the most recent ones AMD said was compatible (at somewhat implied that they were unofficially certified) with APP 2.7 to no avail.

[Blue_MiSfit]

D:\VideoTests\Test Sources\Elemental_4k>c:\x264\x264 1080p24.avs --preset veryfa
st --bitrate 4000 --output test2.mkv --opencl
avs [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 460

x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.0
x264 [error]: clEnqueueNDRangeKernel error '-4'
x264 [error]: OpenCL: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAN
D_NDRANGE_KERNEL on GeForce GTX 460 (Device 0).

x264 [error]: OpenCL: fatal error, aborting encode
x264 [error]: OpenCL: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAN
D_NDRANGE_KERNEL on GeForce GTX 460 (Device 0).

x264 [error]: OpenCL: fatal error, aborting encode
x264 [error]: clEnqueueNDRangeKernel error '-4'
x264 [error]: x264_encoder_encode failed
x264 [error]: clEnqueueNDRangeKernel error '-4'
x264 [error]: OpenCL: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAN
D_NDRANGE_KERNEL on GeForce GTX 460 (Device 0).

x264 [error]: OpenCL: fatal error, aborting encode
x264 [info]: final ratefactor: 19.54

aborted at input frame 21, output frame 0

D:\VideoTests\Test Sources\Elemental_4k>


Welp... not sure what's happening.

I'm using the latest nVidia WHQL drivers - 314.22 on Windows 7 x64 SP1.

This is x264 0.132.2309 3b1f1f7 - 8 bpc, 32 bit, from x264.nl

[plonk420]

mine just freezes after the last line (screen freezes for 5-7 seconds, goes black for a couple, then comes back with Driver Crashed)

x264 --opencl 3x01-lossless-clip.avs -o clip-default.mp4
avs [info]: 1280x720p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x264 [info]: OpenCL acceleration enabled with Advanced Micro Devices, Inc. Cypress
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 3.1

until i Ctrl-C it a couple of times. x264.nl 32 bit version as well. GPU stuff *should* be working, as i've been mining bitcoin with cgminer the last month or so.

[mogobime]

@blue_misfits
To me it seems that you are running out of gpu memory. You should monitor gpu memory usage with gpu-z. Have a look at my benchmark-thread in the signature, it shows GPU mem usage with different settings.
Maybe you only have to close some windows/applications that eat too much GPU mem - otherwise try different settings.
With 2GB VRAM I didn't have much problems encoding with OpenCL.

[aegisofrime]

I'm wondering, has anyone done speed comparisons for OpenCL on a Trinity/Richland/Ivy Bridge/Haswell system, using the integrated GPU? I remember that Trinity got quite a large speedbump from running OpenCL.

[fabje]

Anyone build a new version biased on the newest x264 32bit version?

[the_weirdo]

Anyone build a new version biased on the newest x264 32bit version?

Latest x264 already has OpenCL lookahead feature. Is that what you asked for?

[fabje]

Latest x264 already has OpenCL lookahead feature. Is that what you asked for?
Ah didn't know the option --opencl was already in x264 :)

[Balling]

The author wants to remove OpenCL from x264. I am against it. https://code.videolan.org/videolan/x264/-/merge_requests/66

In particular giant work in ffmpeg will be gone for opencl integration.

[FranceBB]

The author wants to remove OpenCL from x264. I am against it.

I'm against removing it too!
Thanks for letting us know, you should comment in that thread too and let him know.
The more the better.

This is my reply:


I understand your point in the sense that you wanna introduce changes in the way lookahead works and you can't due to the opencl support, however I'm not really in favour of removing it. I know that it hasn't been maintained for years, but despite it being a proof of concept, it actually helps offloading the CPU and speeding things up a bit. I know that benchmarks sometimes showed little to no speed increase at all, but there are some use cases in which it does actually help. For instance, Here at Sky we have several servers re-encoding XDCAM-50 and XDCAM-85 masterfiles into low bitrate consumer H.264 files for the web and since the CPU is responsible not only of encoding the file but also of deinterlacing and resizing the chroma (yv16 to yv12) through Avisynth in an automated fashion, using --opencl in x264 and making use of the NVIDIA Quadro P4000 actually helped and I've gained 12 FPS on every encode (generally there are multiple encodes on a single server, up to 20). The cool thing about this is that even though using NVEnc would be faster, the NVIDIA hardware encoder ain't nearly as good as x264, especially at low consumer-tier bitrates, which is why I have always leaned towards x264. I don't think opencl support should be removed, if anything I'd like to see it implemented in x265 too! I guess we should have an online discussion about x264 and Opencl, though, and ask users whether they would like to keep it or not and see if people are actually really using it (and something tells me that lots of people are indeed using it).


https://code.videolan.org/videolan/x264/-/merge_requests/66

[Atak_Snajpera]

Is opencl still useful with current AMD (ZEN) APU/Intel iGPU like in the past?
http://images.anandtech.com/graphs/graph5835/46687.png

[nevcairiel]

This is my reply

If you want to make use of the GPU, you should make it do what its actually good at - and move said deinterlacing and chroma resizing to it, because per-pixel operations like that are the bread and butter of the GPU. That would give you a much better speedup then OpenCL in x264.

Otherwise, you could also fund development of that feature to make sure it doesn't block further advancement. Apparently you use it in a professional capacity, so that should be in a realm of possibility. "But I use that!" is rarely enough of an answer, if its not followed by "and I'll help to maintain it!"

[FranceBB]

If you want to make use of the GPU, you should make it do what its actually good at - and move said deinterlacing and chroma resizing to it, because per-pixel operations like that are the bread and butter of the GPU. That would give you a much better speedup then OpenCL in x264.

The problem with that is that hardware accelerated filtering is very limited in Avisynth. There are some cuda aware filters, but if you take like Donald Graft's deinterlacer via CUDA, it's 4:2:0 only and I found it to provide not so good results compared to BWDIF. Of course I'd love to see things like QTGMC, MVTools and the various resizing kernels all hardware accelerated and CUDA Aware, like a CUDA Aware Avsresize, but we're still far from it. We made some progress thanks to Grandmaster Ferenc merging code from Avisynth Neo, but there's still a lot to do and it will take years.


Otherwise, you could also fund development of that feature to make sure it doesn't block further advancement. Apparently you use it in a professional capacity, so that should be in a realm of possibility.

Throwing money at it isn't always an answer. I remember when I opened a ticket in the FFMpeg bug tracker asking for automatic DolbyE detection and decoding, literally providing Devs with the current workaround and asking them how much money they wanted to have automatic detection and decoding implemented for each DolbyE case/configuration and nobody replied, which led me to write around 413 lines of code in python using mediainfo to check the input and apply the right DolbyE decoding workaround according to the different audio configurations as FFprobe was "broken" and it was reporting bogus values.


"But I use that!" is rarely enough of an answer, if its not followed by "and I'll help to maintain it!"

The only issue with that is that I'm an Avisynth kind of guy, I can't maintain Opencl code. :(
Nonetheless I think that the public should be taken into account here: if there are enough people using it, I just don't think it should be removed and that's all.
I think we should have a democratic pool and let people vote and accept whatever the outcome of such a vote is going to be. If there are not enough people using it and the majority just don't care and would rather have it removed to get a new lookahead instead, then so be it, I would accept the result of the pool and that's it, but removing Opencl (or indeed keeping it) is not a decision we should take lightly.

That being said, Happy New Year! :D

[lvqcl]

I think we should have a democratic pool and let people vote and accept whatever the outcome of such a vote is going to be.

IIC there are parasites that control the behavior of their victims, but I don't think that it will end well.

[FranceBB]

IIC there are parasites that control the behavior of their victims, but I don't think that it will end well.

LOL
Users contribute a lot, calling users parasites is a bit harsh, isn't it?

That being said, Happy New Year, everyone!

[rwill]

IIC there are parasites that control the behavior of their victims, but I don't think that it will end well.

Well said.

Lookahead is how much CPU time ?
15% in the faster speed modes of total runtime ?
Insignificant runtime in veryslow and placebo ?
Most of it going into DRAM memory bandwidth ?

So OpenCL requires to copy the lowres frame to the GPU which is very slow. The GPU is also not made for what x264 is doing so that is inefficient also. Then the results have to be copied back to the host. Per Frame. It might even become a bottleneck due to Host - Device synchronizing. When OpenCL is faster than the CPU implementation this points to some other issue somewhere. I wont go into details because it would be just wasted.

Really if the maintainer says no one wants to touch it and it blocks things, keeping it makes no sense.

If you other people want to use your GPU get your filter stuff on the GPU. GPUs are great when they work on full pictures really, especially when one chains kernels and things are kept on the device. Not so much when working with little blocks and having to go back to the host each kernel call.

[Atak_Snajpera]

Before you remove anything I strongly recommend to perform some benchmarks if opencl lookahead still gives extra speed boost on AMD apu cpus! Those cpus use system RAM for iGPU so bottleneck should be less noticeable.

[nevcairiel]

I think we should have a democratic pool and let people vote and accept whatever the outcome of such a vote is going to be.

Ignoring the fact that democracy on the Internet means who can motivate the most trolls or bots to vote on their behalf..
I also don't believe it has any place in software development, open-source or otherwise. If an active developer wants to improve the software as a whole, and a somewhat-niche feature is blocking it - as well as noone is offering to maintain it to remove said block....

Even if the vote would be entirely fair, if we properly word it "do you want opencl, or do you want x264 to improve?", would you accept a simple majority on that?

[benwaggoner]

For modern hardware, I imagine using the GPU H.264 encoder itself for lookahead could provide a better speedup without much quality loss. x265 has a lot of analysis reuse features that can speed up encoding quite a lot. It can even use H.264 stream input to accelerate HEVC encoding. Perhaps that code could be backported to x264?

But in any case, if removing OpenCL support in x264 enables improvements in lookahead, I can easily imagine that'll provide a much more impactful net improvement for x264 users. Depending on the improvements in mind, perhaps some or all of the minor perf improvements of OpenCL can be gained in pure software.

[FranceBB]

Ignoring the fact that democracy on the Internet means who can motivate the most trolls or bots to vote on their behalf..


True, although I always found Doom9 to be a safe heaven with dedicated and respectful people, which is very hard to find anywhere else on the internet.


If an active developer wants to improve the software as a whole, and a somewhat-niche feature is blocking it - as well as no one is offering to maintain it to remove said block....


I get that...
I mean, going forward if the improvements on the lookahead are really worth and really no one is willing to maintain opencl support, then I wouldn't mind.

Depending on the improvements in mind, perhaps some or all of the minor perf improvements of OpenCL can be gained in pure software.

That would be nice and would solve the problem for everyone.
CPU Performance improvements that would match the little opencl speed-up we already have so that we can toss opencl support?
I'm all for it! Bring it on, I say eheheheheheh

[Balling]

I still use 4th generation Intel for my windows 11 PC. and 2080 Ti. Thinking about Alder Lake. So it is obviously good there, is not it? And anyway, you can always do a separate code path without opencl. Why remove it?

[benwaggoner]

And anyway, you can always do a separate code path without opencl. Why remove it?
This seems to be the most compelling justification:
Its presence prevents changes of general lookahead code because it should be changed in sync with OpenCL lookahead code which nobody wants to touch. And so, it harms development of core functionality.
Lots of stuff in x264 is tied together. Changes that aren't compatible with OpenCL require more of a fork than a separate path. People who really want to keep using OpenCL can keep on using current builds that don't have new incompatible features.

Lookahead code is really important stuff, and is something I could see yield material improvements in x264 output again after years of stagnation in compression efficiency.

[Ritsuka]

The question is, what was the last time anyone here used the OpenCL lookahead?

[Emulgator]

Seeing FranceBB's use case: +12fps looks very good.
I did use OpenCL lookahead because it was there, but will not suffer if its gone.

Listening to the few who actually put their effort into maintaining codebase
I can imagine the roadblock it would create if kept and who would be funding at all ?

Having just upgraded from 22nm 4th generation i7 to 14nm 11th generation i9
(and seeing 7nm Ryzens 60% ahead speedwise while consuming same or less power):

That bit offload CPU->GPU seems to be less noticeable and might not be worth it anymore,
but it takes more power users to chime in.

[FranceBB]

Seeing FranceBB's use case: +12fps looks very good.
I did use OpenCL lookahead because it was there, but will not suffer if its gone.


Yeah, the thing is that my use case is very different to the one of the average user. Generally, users encode 1 file at a time, with a peculiarly written AVS Script and things like --preset veryslow and have a consumer GPU. On my side, however, this is done by an HP Server with an Intel Xeon CPU (28c/56th) which would be overly used anyway as it encodes several files at the same time from high bitrate yv16 25i internal mezzanine files to consumer-tier H.264 yv12 25p (even as many as 30 files at the same time sometimes, on rare occasions) with --preset medium to deliver the result to the social networks (Facebook, Twitter, Instagram), to YouTube and to the train stations all over the country (The recap of the Italian version of Sky News is played on the monitors of train stations scattered across Italy). So, with an overly loaded CPU and a professional card like the NVIDIA Quadro P4000 sitting there doing absolutely nothing, it makes sense to offload some of the work, hence the speed bump (it goes from around 96fps to around 108fps).

[Atak_Snajpera]

Seeing FranceBB's use case: +12fps looks very good.
I did use OpenCL lookahead because it was there, but will not suffer if its gone.

Listening to the few who actually put their effort into maintaining codebase
I can imagine the roadblock it would create if kept and who would be funding at all ?

Having just upgraded from 22nm 4th generation i7 to 14nm 11th generation i9
(and seeing 7nm Ryzens 60% ahead speedwise while consuming same or less power):

That bit offload CPU->GPU seems to be less noticeable and might not be worth it anymore,
but it takes more power users to chime in.

Have you benchmarked opencl using integrated GPU? It would be stupid to remove something what could give you ~25% speed boost on CPU with iGPU! BTW. ZEN4 will also have iGPU so not so fast with that "delete old code" mentality.

[rwill]

So, with an overly loaded CPU and a professional card like the NVIDIA Quadro P4000 sitting there doing absolutely nothing, it makes sense to offload some of the work, hence the speed bump (it goes from around 96fps to around 108fps).

I would just buy another headless server. Might I suggest one with some EPYC CPU ?

[Emulgator]

Have you benchmarked opencl using integrated GPU?
Not yet, will go to your x264 FHD benchmark soon.
Hm, have difficulties finding it. Links are dead.
Found something... 1.0.1 still valid ? 178MB?
I see: x264 from 2011, I would have to swap x264 and generate a new commandline.
Now I guess it would be better to use Ripbot because uf selectable OpenCL device, isn't it ?

P.S. Went testing StaxRip, OpenCL on CPU Integrated Graphics:
I don't know how to activate that path on that system, it is not available as dropdown.

Using the available RTX3080 OpenCL accelerates a bit:
x264 superslow encode from 7,9..8.0fps to 8,2..8,5fps.

[Atak_Snajpera]

Not yet, will go to your benchmark soon.

Perform simple 1080p test without any filtering in avisynth. Use at least preset medium and preset veryslow

[ReinerSchweinlin]

Could it be an option to move motion estimation from OPENCL to DX12 (at least on windows)?

http://forum.doom9.org/showthread.php?t=183517&page=3

I used the OPENCL Acceleration quite often in the past. Just like others stated above, it can offload some of the CPU work to the GPU and free up ressources for filtering etc... Especially with not so powerfull CPUs in combination with small AMD GPUs (which are fast in OPENCL... GCN 2 and above), the combination of GPU/CPU offered a lot of performance for the invested money.....

In my tests, it seemed like fast transfers from CPU to GPU helped in this regard - I noticed significant drops in speeds with slower PCI-E connections.
For smaller resolutions, iGPUs and APUs were a good combination. Although the processing power isn´t that great on internal GPUs, the often fast connection between CPU and GPU seemed to help..

This whole topic reminds of an older thread where Hardware-Acceleration of x264 and x265 was discussed... One of the developers of x265 jumped in and mentioned that with x265 it wasn´t worth thinking about adding some GPU offloading, because the transfer speeds were too much of a bottleneck. Also, AVX Extensions could do a lot of what the OPENCL part was doing (I hope I remember correctly, can´t find the thread at the moment...).. Maybe - with faster PCIE Connections, the situation could be re-evaluated ?

[benwaggoner]

Could it be an option to move motion estimation from OPENCL to DX12 (at least on windows)?
Sure. It would be less portable of course, and I'm not sure there would be any benefit.

I used the OPENCL Acceleration quite often in the past. Just like others stated above, it can offload some of the CPU work to the GPU and free up ressources for filtering etc... Especially with not so powerfull CPUs in combination with small AMD GPUs (which are fast in OPENCL... GCN 2 and above), the combination of GPU/CPU offered a lot of performance for the invested money...
The value proposition was a lot higher back when the standard CPU had only a few cores. The limited parallelization in x264 itself means there are generally unused cores available on modern hardware. Which is the hardware that the groups who fund x264 development use.

In my tests, it seemed like fast transfers from CPU to GPU helped in this regard - I noticed significant drops in speeds with slower PCI-E connections.
For smaller resolutions, iGPUs and APUs were a good combination. Although the processing power isn´t that great on internal GPUs, the often fast connection between CPU and GPU seemed to help..
Latency is generally a bigger limitation than bandwidth for this scenario. And modern codecs have more and more ways to do things, which means more and more very branchy logic with lots of early exits and heuristics. CPU + SIMD does that very well. Even though GPU has more compute available, the round trip latency between CPU and GPU means the GPU is often idle waiting for the CPU to process GPU output to make new instructions for the GPU.

The OpenCL preview uses a very simplified x264, nothing like what's in a --preset veryslow. One strong possibility is that using built-in encoder output could provide a similar fidelity of data, but faster and much simpler.

This whole topic reminds of an older thread where Hardware-Acceleration of x264 and x265 was discussed... One of the developers of x265 jumped in and mentioned that with x265 it wasn´t worth thinking about adding some GPU offloading, because the transfer speeds were too much of a bottleneck. Also, AVX Extensions could do a lot of what the OPENCL part was doing (I hope I remember correctly, can´t find the thread at the moment...).. Maybe - with faster PCIE Connections, the situation could be re-evaluated ?
HEVC has a lot more modes than H.264, so there's way more little branchy decisions to make per frame. And the bottle neck is more latency than bandwidth. And yeah, AVX2 and other SIMD can do a lot of GPU-style operations in a shared L3 cache. Net compute is quite a bit lower, but having super low latency between complex logic and SIMD makes up the delta and more.

The relatively small gains of OpenCL is a reflection of how much better CPUs have gotten more than anything. If GPUs had evolved at current pace but CPU designs stayed where they were in 2013, OpenCL would have a much bigger per gain.

This is a broad industry trend. Broadcast encoders a decade ago were mainly ASIC or GPU based. Today, particularly with HEVC, the high end stuff is all CPU based, because CPU offers the best quality @ bitrate @ $$$. Even with H.264, software x264 was always a lot better than any GPU or ASIC implementation for < 1 Mbps. AV1 and VVC are even more CPU-friendly, so I doubt we'll see a fundamental change. GPU is great for source decode and filtering, and for mixed filtering/encoding workflows, Having everything but encoding happen on GPU leaving the CPU for compete is a much more beneficial optimization.

[DTL]

"Of course I'd love to see things like QTGMC, MVTools and the various resizing kernels all hardware accelerated and CUDA Aware, like a CUDA Aware Avsresize, but we're still far from it. "

I read your company uses some expensive CPUs like Xeons platinum with 12-ch memory. (Possible memory speed about 1 TB/s). But do you have or plan to use some good-performance data compute accelerators like NVIDIA A100 (memory speed about 2 TB/s) ? I see it priced close to that Xeons (about $15000) and have a bit more mem speed and possibly higher computational performance. Though it may be pure computational accelerator without any piece of ME engine. So require to develop full Compute-Shader/DirectCompute based MAnalyse. But it is expected to be much faster in compare with currently fixed-performance ME engine in available accelerators.

I also interesting in possibility of adding DX12_ME to x264 on windows hosts (though I read some window-less processing of DX12-based applications also possible with Linux ?). Currently at i5-9600K + GTX1060 with transcoding some FullHD footage with tr=25 degraining and x264 with placebo-like settings at about 6..7 fps and about 9 Mbit/s output MPEG speed I have about 50% of Video Encode load and 100% CPU load. So about 50% of ME-engine resources is still free. It can offload some ME-work from x264 if it good separated from other processing. I still not look into 264 program how it is perform ME - in more or less separated function or highly integrated with 'branching' and other stuff ? If it is enough separated - it can be easily routed outside x264 execution to accelerator and download back the ME-result. The upload and download speed via bus should not be any issue. Even if make it with separated pairs of src+ref frames. But if ME is highly integrated in the other MPEG-encoding parts and can not be separated as total frame processing stage - it is sad.

" is something I could see yield material improvements in x264 output again after years of stagnation in compression efficiency. "

The real significant addition to efficiency for natural optical camera based footages is combining of noise reduction with 'classic MPEG' encoding. Do developers of 'pure MPEG' encoders plan to put some work into this approach ? Currently 'in the field' users of x264 need to apply external multi-frame noise reduction that is based on the same algoriphms that MPEG uses (motion-compensated blocks averaging). So for real benefit the good 'motion pictures compression engine' need to combine and reuse the ME processing for both mult-frame noise reduction and other compression stages.

Currently we have separate ME (CPU or accelerator based) in denosie pre-processing stage and next in the MPEG-encoding stage. It is waste of computational and hardware resources. The most sad fun is visible with latest DX12-ME mod of mvtools - the 'standard' now in Windows10 and later ME operating system's service (accelerated by hardware MPEG encoder chip) is completely compatible with multi-frame denoiser and can gain the compression efficiency up to several times (depending on noise level in the input footage and crf-setting and scenes complexity).
And for natural camera-based footages the output MPEG-speed (actual total compression efficiency) is greatly based on amout of residual noise after denoise stage and crf-setting in the x264 encoder. Also x264 have some 'denoiser' built-in. But why it have so poor performance and possibly never used by anyone ?

"And modern codecs have more and more ways to do things, which means more and more very branchy logic with lots of early exits and heuristics. CPU + SIMD does that very well. "

With the progress of number of 'unuiversal compute cores' at accelerators I see the old 'video cards' greatly outperforms the 'CPU chips'. Shame on intel-architecture of PCs - it now stuck with both low logical cores and low host memory speed. Number of compute cores at accelerator may be easily to dozens and hundreds and each core may execute its logical thread at simple logical C-language written. With host CPU programmer is overloaded with attempt to fit in few numbers of avaialble 'universal logic hardware threads' and try to put data parallelization into very limited in logic and avaialble optimal data-placement patterns SIMD-coprocessor. Each program for SIMD-coprocessor is low-level hand-crafted (separately for each SIMD-generation) and still only more or less effective for some given dataset size (like block size only NxN, bitdepth only M, etc, etc).
With mvtools example - simple SAD computation 'onCPU' using ready to use ME-MVs data takes visible time and loads host memory significantly. Even with best-in-world SIMD optimizations fine tuned by decades (actually taken from x264 project as I see). With simple C-based compute shader at accelerator is still something inbetween 0 and 1% of 'GPU load' on the mid-201x year accelerator.

[ReinerSchweinlin]

@benwaggoner

Thanx for taking the time to respond in such a elaborate way, I apprecciate it :)