x264 OpenCL

[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.