x264 development

[xooyoozoo]

You have artificially expanded 8-bit data into 10-bit (without any meaningful information added) and then want to have those 10-bit stored losslessly in video stream. It's pretty obvious to me that the result of 10-bit lossless storage space occupation must be larger than the space that the same original occupies at 8-bit data width.

There's a 60% increase in size between the artificially padded file and the normal file, which is just straight-up odd. My own intuition suggests that modern compression should and does* efficiently handle extra 'fake' information, the massive gap in my situation above just screams that there's a regression in the code somewhere.

I'm not exactly invested in 10bit lossless. I just bring this up in case it *is* a bug and to inform people because the large swings in bitrates here seem like something that should be in the fine print.

*Case in point:
7zipped 8bit YUV: 126.5 MB
7zipped FFMPEG'ed fake 10bit: 132.9 MB
Base on everything I know, the extra precision 10bit x264 would give to prediction should more than make up that ~5% gap. At the very least, predictive lossless shouldn't be worse than a zip file.

[Dark Shikari]

I'm surprised it's only 60%, I would have expected it to be more, given how H.264's entropy coding works.

H.264 isn't LZMA; it can't and isn't designed to absorb arbitrary redundancies in the source -- only those it's designed to compress. It's also a few hundred times faster.

[xooyoozoo]

I'm surprised it's only 60%, I would have expected it to be more, given how H.264's entropy coding works.

H.264 isn't LZMA; it can't and isn't designed to absorb arbitrary redundancies in the source -- only those it's designed to compress. It's also a few hundred times faster.

So just to make sure I get it right, somewhere between "normal" QPs and lossless QP, fake-10bit hurts more than helps?

[Dark Shikari]

So just to make sure I get it right, somewhere between "normal" QPs and lossless QP, fake-10bit hurts more than helps?No; it always helps for lossy at the same bitrate.

It's just that 10-bit adds 12 more QPs below the lowest possible QP in 8-bit, representing the possibility of up to 4 times greater precision. This represents more precision than is in the source in an 8-bit video; there is no equivalent QP in 8-bit encoding.

[BugiBugBug]

I don't know if this is the right place to ask, but I figured a small question like this is not worth a separate thread :)
I encode primarily with the same or similar settings, and I was wondering if it is possible or makes sense to use these particular settings (simple --preset medium or slow with b-adapt2, ref 3 and bframes 3 or 4, sometimes trellis2) in fprofiling my x264 binary?
Or more in general, does it make sense to delete OPT.. in the makefile that will never be used, or some options in it like --ssim in OPT1? Could be that I'm misunderstanding the way fprofiled works, of course - I'm kind of a newby at the game.
Maybe I could create my own OPT.. lines?

[Groucho2004]

I don't know if this is the right place to ask, but I figured a small question like this is not worth a separate thread :)
I encode primarily with the same or similar settings, and I was wondering if it is possible or makes sense to use these particular settings (simple --preset medium or slow with b-adapt2, ref 3 and bframes 3 or 4, sometimes trellis2) in fprofiling my x264 binary?
Or more in general, does it make sense to delete OPT.. in the makefile that will never be used, or some options in it like --ssim in OPT1? Could be that I'm misunderstanding the way fprofiled works, of course - I'm kind of a newby at the game.
Maybe I could create my own OPT.. lines?
Been there, done that (when I was really bored). Even profiling for a specific source didn't increase performance more than 1-2 %.
I don't use profiling any more - not worth it (at least with GCC).

[schweinsz]

How to use the x264 to encode the bitstreams using arbitrary hierarchical B coding.
For example, the display sequence is: B0 B1 B2 B3 B4 B5 B6 B7, the encoding sequence is: B0 B7 B2 B4 B1 B3 B5 B6.

If there is not this function., could somebody add it, it's not a big patch if only poc based ref. is used, but it perhaps gives a real gain perhaps big on coding efficiency.

[rack04]

summing the feedback my last post got up:

--bluray-compat

enables a bunch of 'Blu-ray hacks':
- min-CR + level 4.1 hack
- Special b-pyramid SEI
- B-frames cannot reference frames outside their minigop
- Open-GOP keyframe interval hack
renders '--open-gop' parameters obsolete:
- now: --bluray-compat + --open-gop <> old version: --open-gop bluray
- now: --open-gop without --bluray-compat <> old version: --open-gop cbrHD
enforces:
- aud=1
- nalhrd=vbr
(-> these are not needed in the command line when using '--bluray-compat')
restricts:
- bframes to: 3 or less
- bpyramid to: strict or none
- max references to: 6 or less
- weightp to: 1 or 0


I want to make sure I understand this correctly. I have been backing up my Blu-ray collection for quite awhile using the following command line:

Encoding Pass 1 with I-Frame Chapters ...
"%x264_PATH%" --preset %PRESET% --tune %TUNE% --pass 1 --bitrate %VIDBITRATE% --stats "%SOURCE_FOLDER%\%SOURCE_FILENAME%.stats" --bluray-compat --level 4.1 --keyint 48
--vbv-bufsize 15000 --vbv-maxrate 15000 --slices 4 --sar 1:1 --b-pyramid strict --open-gop --colorprim bt709 --transfer bt709 --colormatrix bt709
--output NUL "%INPUT_VIDEO%" --qpfile "%QPFILE_PATH%"

Encoding Pass 2 with I-Frame Chapters ...
"%x264_PATH%" --preset %PRESET% --tune %TUNE% --pass 2 --bitrate %VIDBITRATE% --stats "%SOURCE_FOLDER%\%SOURCE_FILENAME%.stats" --bluray-compat --level 4.1 --keyint 48
--vbv-bufsize 15000 --vbv-maxrate 15000 --slices 4 --sar 1:1 --b-pyramid strict --open-gop --colorprim bt709 --transfer bt709 --colormatrix bt709
--output "%SOURCE_FOLDER%\%SOURCE_FILENAME%-output.264" "%INPUT_VIDEO%" --qpfile "%QPFILE_PATH%"

According to the quoted post above, since I'm using both --bluray-compat and --open-gop x264 applies --open-gop bluray?

[LoRd_MuldeR]

According to the quoted post above, since I'm using both --bluray-compat and --open-gop x264 applies --open-gop bluray?

The "--open-gop" option doesn't have a parameter anymore. So there is no "--open-gop bluray" in current x264.

However using "--open-gop" together with "--bluray-compat" enables the BluRay-safe variant of OpenGOP, so it's effectively the same as "--open-gop bluray" in older version.

(Though "--bluray-compat" does much more things than "--open-gop bluray" used to do)

[iSunrise]

Introduction to AVX2 optimizations in x264 (http://www.scribd.com/doc/137419114/Introduction-to-AVX2-optimizations-in-x264)

Looks pretty tasty!

[MaistroX]

Hi, anyone able to explain the following VARNINGS "x264 [warning]: non-strictly-monotonic pts at frame" & "x264 [warning]: MB rate (391288) > level limit (245760)" for me?

F:\_BD3D2MK3D\JP3D_48FPS\00023_m2ts>"C:\BD3D2MK3D v0.17\toolset\stereoplayer.ex
e\avs2yuv.exe" "_ENCODE_3D_MOVIE.avs" -o - | "C:\BD3D2MK3D v0.17\toolset\stereoplayer.exe\x264_x64
.exe" --bitrate 10000 --pass 1 --stats "00023_m2ts.stats" --preset medium --profile high10 --level 4.
1 --video-filter resize:1920,1080,method=bicubic --qpfile chapters_3D.qpfile --output "00023_m2ts.26
4" --frames 364870 --demuxer y4m --stdin y4m -
_ENCODE_3D_MOVIE.avs: 3840x1080, 48000/1001 fps, 364873 frames
y4m [info]: 3840x1080p 0:0 @ 48000/1001 fps (cfr)
resize [info]: resizing to 1920x1080
x264 [info]: using SAR=2/1
x264 [warning]: MB rate (391288) > level limit (245760)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile Main, level 4.1
x264 [warning]: non-strictly-monotonic pts at frame 1 (0 <= 0)
x264 [warning]: non-strictly-monotonic pts at frame 2 (0 <= 1)
x264 [warning]: non-strictly-monotonic pts at frame 3 (0 <= 2)
x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones
[0.0%] 121/364870 frames, 0.83 fps, 28471.29 kb/s, eta 122:46:40
"

Wonder what it means and what it can make for faults + what I can do to make them go away ? :)

Regards MaistroX

[nhakobian]

The warning:
x264 [warning]: non-strictly-monotonic pts at frame
is telling you that the input pts timestamps are messed up in some way. In fact it looks like the timestamp is set to 0 for each of them (0 < 1 notations, etc.). Unless your source is variable frame rate, I don't think this should make a difference since you are forcing a frame rate.

x264 [warning]: MB rate (391288) > level limit (245760)
This is telling you that your resolution+fps setting exceeds the specified level limits. In this case, you are asking for level 4.1 and 1920x1080@48fps. This isn't allowed in level 4.1 (but is in 4.2). See http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels for more info.

[MasterNobody]

MaistroX
x264 shouldn't give "x264 [warning]: non-strictly-monotonic pts at frame ..." with y4m input. So its look like miscompiled build of x264. What build did you used exactly? Have you compiled it yourself or this http://x264.nl/ build (then which version)?

[Fishman0919]

I'm getting an error compiling the latest daily tarball (x264-snapshot-20130424-2245.tar.bz2) or git. A perl.exe.stackdump error.

NM, got it.... "which perl" showed pointing to perl.exe in git... renamed. alset

http://i467.photobucket.com/albums/rr37/fishman0919/perlerror_zpseafbc357.png (http://s467.photobucket.com/user/fishman0919/media/perlerror_zpseafbc357.png.html)

[LoRd_MuldeR]

If you don't need OpenCL support, you can use "--disable-opencl", but you probably have read that yourself ;)

Anyway, I usually use Strawberry (http://strawberryperl.com/) if I need Perl on the Windows platform...

[MaistroX]

I use:

x264 version:

x264 0.130.2273 b3065e6
(libswscale 2.2.100)
(libavformat 54.63.100)
(ffmpegsource 2.17.3.0)
built by Komisar on Feb 27 2013, gcc: 4.7.2 (multilib.generic.Komisar)
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

http://komisar.gin.by/


MaistroX
x264 shouldn't give "x264 [warning]: non-strictly-monotonic pts at frame ..." with y4m input. So its look like miscompiled build of x264. What build did you used exactly? Have you compiled it yourself or this http://x264.nl/ build (then which version)?

[Fishman0919]

If you don't need OpenCL support, you can use "--disable-opencl", but you probably have read that yourself ;)

Anyway, I usually use Strawberry (http://strawberryperl.com/) if I need Perl on the Windows platform...

Yes, thank you LoRd_MuldeR... but for some reason when I did "which perl" it was pointing to the "perl.exe" in the Git installation instead of the one in Strawberry.

[LoRd_MuldeR]

Yes, thank you LoRd_MuldeR... but for some reason when I did "which perl" it was pointing to the "perl.exe" in the Git installation instead of the one in Strawberry.

It's probably because MSYS will insert its own "bin" directory (as well as the "bin" directory of the associated MinGW/GCC) into its PATH variable before anything else that it inherited from your systems PATH environment variable. Or you have a separate Git installed that happened to end up in your PATH before the entry of Strawberry. MSYS Git comes with its own MSYS stuff, which can cause trouble.

Try something like "export set PATH=/c/strawberry/bin:$PATH" before you execute "./configure".

[MasterNobody]

I use:

x264 version:

x264 0.130.2273 b3065e6
(libswscale 2.2.100)
(libavformat 54.63.100)
(ffmpegsource 2.17.3.0)
built by Komisar on Feb 27 2013, gcc: 4.7.2 (multilib.generic.Komisar)
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

http://komisar.gin.by/

I tried this (clear x86_64) komisar's build and couldn't reproduce issue with your command line (obviously I had to use another avisynth script for avs2yuv and different qp-file but all other was the same). So may be it is problem with something other on your system (non standard AviSynth version or dunno)?

[LoRd_MuldeR]

I noticed that latest x264.exe will now depend on OpenCL.dll, if compiled with OpenCL lookahead support.

Correct me if I'm wrong, but I think this means that now a graphics card with OpenCL support plus an up-to-date display driver, that provides an OpenCL.dll is required to run x264.

If so, I guess a lot of users will run into issues with "standard" builds now. Wouldn't it be possible to detect and load the OpenCL.dll at runtime, only if available?

[filler56789]

I noticed that latest x264.exe will now depend on OpenCL.dll, if compiled with OpenCL lookahead support.

O_o

Correct if I'm wrong, but I think this means that now a graphics card with OpenCL support plus an up-to-date display driver, that provides an OpenCL.dll is required to run x264.

I haven't yet run a test encode with the latest x264, but so far it seems the DLL is required only for making x264.exe S.T.F.U. :p

And oh BTW, is that DLL freely-redistributable? :confused:
Yes, I've found it and downloaded it, but this is not the point, of course.

EDIT:
Just confirming, r2309 does work normally IF you have OpenCL.dll in the same folder as x264.exe.

EDIT 2:
By "x264 works normally", I mean I didN'T use the the --opencl option.

[Dark Shikari]

Eesh, I wonder if there's a better way to go about this (dlopen?)

[mariush]

Hmm... I just downloaded the 64bit 8bit version and it says "x264 [warning]: OpenCL: not compiled with OpenCL support, disabling"

The 32bit version says "x264 [warning]: OpenCL: Unable to find a compatible device" ... though I don't have an opencl.dll in the folder, I suspect my radeon 4850 is just not supported.

Should the 64bit version support opencl or...

Maybe I'm just stupid at 7am now after a night of no sleep.

later edit: How could I determine if an OpenCL device would be supported by x264? The only mention I see is something about cl_image in the git log

With Aida64 I see in "Device Features" at Radeon 4850 that "Images" is not supported. Is that the thing to look for? Because I have OpenCL entry for the fx-8320 which says it supports Images but x264 says "no device"

[Sparktank]

Nothing worked for 8 bit: x86/x64 (10 bit not supported :erm: )
I tried using with Avisynth for a conversion and also directly from file using --demuxer.
Still got errors and it seemed to really choke up the system until I terminated process.
For a few minutes after, the system ran very slowly. :S


"GPU Caps Viewer 1.18.0" detects OpenCL 1.2 on my laptop.
Detected Nvidia OpenCL on desktop.

x86/8 version: (x264.nl)
x264 0.132.2309 3b1f1f7
(libswscale 2.2.100)
(libavformat 55.3.100)
(ffmpegsource 2.17.4.0)
built on Apr 24 2013, gcc: 4.7.3
configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: LGPL version 2.1 or later

Laptop: (store bought HP Paviliopn G series)
Windows 7 (x64)
Intel HD 3000 (QuickSynch) (can't update! custom build from HP :/) so only have...
Intel(R) SDK for OpenCL Applications 2013 (with runtime installed) OpenCL 1.2

Desktop: custom build from a friend
Windows XP (x86)
Nvidia GeForce 8400 GS (old!!) updated to latest driver (includes OpenCL)

Without OpenCL.dll in same folder as x264...

--opencl
Desktop:
avs [debug]: using avisynth version 2.60
avs [info]: 1280x528p 0:0 @ 2500000/104271 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce 8400 GS
x264 [info]: Compiling OpenCL kernels...
x264 [warning]: OpenCL: kernel build errors written to x264_kernel_build_log.txt
>>x264_kernel_build_log.txt
(0) Error: unsupported operation

Laptop:
avs [debug]: using avisynth version 2.60
avs [info]: 1280x544p 0:0 @ 10000000/416667 fps (cfr)
avs [info]: color matrix: undef
x264 [debug]: using mv_range_thread = 40
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [warning]: OpenCL: Unable to find a compatible device

--opencl --opencl-device 1
Desktop:
avs [debug]: using avisynth version 2.60
avs [info]: 1280x528p 0:0 @ 2500000/104271 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [warning]: OpenCL: Unable to find a compatible device

Laptop:
avs [debug]: using avisynth version 2.60
avs [info]: 1280x544p 0:0 @ 10000000/416667 fps (cfr)
avs [info]: color matrix: undef
x264 [debug]: using mv_range_thread = 40
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [warning]: OpenCL: Unable to find a compatible device

x64/8 --demuxer lavf for lossless video codec: Utvideo. (inside AVI)
Laptop:
--opencl & With/without --opencl-device 1
x264 [warning]: OpenCL: not compiled with OpenCL support, disabling

I even tried a custom build from tmod.nmm-hd.org and still no OpenCL support.
x264_rev2309+704_tMod

I will try with copying opencl.dll to x264 directory.
I think separate folders:
C:\Windows\SysWOW64\OpenCL.dll -> x64 bit x264
C:\Windows\System32\OpenCL.dll -> x86 bit x264

EDIT:
Nope. Isolating x264 and OpenCL.dll into a single folder didn't fix problem.
x264 [warning]: OpenCL: Unable to find a compatible device

[jpsdr]

I used to compile my own build with some patches added. Until the last commit, everything was fine, but now, i'm unable to compile if i keep the "Film grain optimization" patch.
I'm unable to figure out precisely what's wrong. Error messages are related to x264_pixel_### functions. It seems to be linked with the DECL_PIXELS, but i've not been able to figure out...
If by any luck someone can help.
Thanks.

[filler56789]

FWIW, at least two patches from Komisar's site (L-Smash muxer and avi muxer) do not work with the latest git :eek:
Apparently he still hasn't updated the .diff files in his homepage...
nor managed to compile the VfW codec as well.

[Selur]

regarding openCl, would be cool if x264 has some sort of --check-opencl which, could be called without starting an encode and would return the compatible cards detected or a message like 'OpenCL: Unable to find a compatible device' and 'OpenCL: Unable to find a opencl.dll'

[Sparktank]

regarding openCl, would be cool if x264 has some sort of --check-opencl which, could be called without starting an encode and would return the compatible cards detected or a message like 'OpenCL: Unable to find a compatible device' and 'OpenCL: Unable to find a opencl.dll'

Agreed. I googled last night to see if there was any undocumented switch for x264 to do a check.
In the mean time, I jut added --frame 20 to do a short test with log-level at debug to see what's going on.

I read somewhere on a German forum (I don't think it was gleitz) that between the last stable version and current one, the only ones with OpenCL support were made and patched by users as test builds.

I have not since been able to find that forum again.

[komisar]

FWIW, at least two patches from Komisar's site (L-Smash muxer and avi muxer) do not work with the latest git :eek:
Apparently he still hasn't updated the .diff files in his homepage...
nor managed to compile the VfW codec as well.
all patches apply clearly in my kMod build...
VFW is waiting while refactor config form...

[LoRd_MuldeR]

Eesh, I wonder if there's a better way to go about this (dlopen?)

Yup, I think dlopen+dlsym or its Windows equivalents LoadLibrary+GetProcAddress would be the usual approach.

Though, from what I see, there are quite a number of functions we need to lookup from OpenCL.dll :o

On Windows (MSVC) we could also use "DLL Delay Loading", but I have no idea if that is supported in Linux or MinGW.

(BTW: I think a lot of similar stuff already happens in the Avisynth code in x264)

[mastrboy]

Has any AMD FX 8150/8350 users been able to do some benchmarking on rev 2309?
I'm curious about the new AVX2 optimizations that made it into x264 between r2273 and r2309...

[nevcairiel]

Has any AMD FX 8150/8350 users been able to do some benchmarking on rev 2309?
I'm curious about the new AVX2 optimizations that made it into x264 between r2273 and r2309...

How are these two things related?
Only Intels upcoming Haswell CPU has AVX2 (so far)

[mastrboy]

How are these two things related?
Only Intels upcoming Haswell CPU has AVX2 (so far)

You're right, I misread the wiki article: http://en.wikipedia.org/wiki/Advanced_Vector_Extensions

Then, never mind my previous post...

[filler56789]

all patches apply clearly in my kMod build...
VFW is waiting while refactor config form...

Thanks for answering, I will try to find out what was my mistake, then. :o

[LoRd_MuldeR]

UPDATE: Latest x264 will now only try to load OPENCL.DLL, if you really used the "--opencl" option. Thus, the "dummy" DLL is not required anymore!

I will not delete the attachment for now, but you really should NOT download or use that file anymore. Instead just update your x264 :)

FWIW, I have spent three minutes to make a "dummy" OPENCL.DLL which people can use to make x264.exe start on their system, if no "real" OpenCL DLL is available.

It should be clear, that any OpenCL-specific functions will not actually work with this DLL. Also this DLL herewith is declared Public Domain, so please feel free to redistribute it ;)

Warning: If you actually want to use "--opencl", then this DLL is not for you!

[dbtayag]

Okay, I have spent three minutes to make a "dummy" OPENCL.DLL which people can use to make x264.exe start on their system, if no "real" OpenCL DLL is available.

It should be clear, that any OpenCL-specific functions will not actually work with this DLL. Also this DLL herewith is declared Public Domain, so please feel free to redistribute it ;)Thank you very much for this. x264 works again!

[filler56789]

^
^
:thanks: too :)

[Snowknight26]

x264 [error]: clSetKernelArg error '-49'
x264 [error]: clSetKernelArg error '-49'
x264 [error]: clSetKernelArg error '-49'

Can you not Ctrl+C/SIGINT encoding successfully anymore?

[mogobime]

just loaded the rev2309 8-bit x64 from x264.nl and got this message when setting --opencl:
x264 [warning]: OpenCL: not compiled with OpenCL support, disabling

[JEEB]

just loaded the rev2309 8-bit x264 from x264.nl and got this message when setting --opencl:
That's because the OpenCL SDK finding code fails if you give the configuration script a cross-prefix (like I do when compiling the 64bit builds), and thus it didn't get enabled :P . A fix for that is being reviewed on #x264dev.

[pepelugil]

Hello,

Is it safe to use r2309 without tweaking slices?

I'm worried after looking this: Fix two bugs in slice-min-mbs and slices-max (https://github.com/DarkShikari/x264-devel/commit/76a5c3a19f97cd34b65aeff050de4042b054bc65)

[JEEB]

Hello,

Is it safe to use r2309 without tweaking slices?

I'm worried after looking this: Fix two bugs in slice-min-mbs and slices-max (https://github.com/DarkShikari/x264-devel/commit/76a5c3a19f97cd34b65aeff050de4042b054bc65)
Those only affected the cases specified, but in any case I finally got to building 2310 builds. They should be put onto x264.nl as soon as jarod notes my ping to him to run the mirroring script. Until then they can be found here (http://x264.fushizen.eu/builds/revision2310/).

[pepelugil]

Those only affected the cases specified, but in any case I finally got to building 2310 builds. They should be put onto x264.nl as soon as jarod notes my ping to him to run the mirroring script. Until then they can be found here (http://x264.fushizen.eu/builds/revision2310/).

Thank you!!!

And sorry, but I don't really understand what the problem was: If I didn't use --slices-max parameter I would have problems?

[mogobime]

still got the same problem with v2310:
x264 [warning]: OpenCL: not compiled with OpenCL support, disabling

The x264_r2274+opencl.7z (http://tmod.nmm-hd.org/x264/test/) from Tmod works perfekt on my system, dxdiag output:
ftp://x-quasat.redirectme.net/public/DxDiag.txt

[jdobbs]

still got the same problem with v2310:


The x264_r2274+opencl.7z (http://tmod.nmm-hd.org/x264/test/) from Tmod works perfekt on my system, dxdiag output:
ftp://x-quasat.redirectme.net/public/DxDiag.txtSo LoRd_MuldeR's fix in this post (http://forum.doom9.org/showthread.php?p=1625943#post1625943) doesn't work for you?

[LoRd_MuldeR]

So LoRd_MuldeR's fix in this post (http://forum.doom9.org/showthread.php?p=1625943#post1625943) doesn't work for you?

It seems that he is using an x264 build that simply was not compiled with OpenCL support, which can only be fixed by re-compiling. And, according to JEEB, a new/fixed build is on the way.

On the other hand, my "fix" is intended to make x264 (if compiled with OpenCL support) work on systems without OpenCL hardware/drivers.

That's because, even if you don't want to use the new OpenCL functions of x264, it still needs an OpenCL DLL now! Without such DLL, current x264 won't even start. The "dummy" DLL fixes that.

Of course the OpenCL functions of x264 will not work at all with that "dummy" DLL ;)

The "proper" way to handle this would be detecting the OpenCL DLL at runtime and simply disable OpenCL, if the DLL can not be loaded, but that needs modifying x264 code.

[mogobime]

I thought --opencl won't work with this fake-dll?
It should be clear, that any OpenCL-specific functions will not actually work with this DLL.
I have no problem to run x264, but it doesn't use opencl lookahead...

EDIT:
LoRd_MuldeR was faster ;)

[jdobbs]

It seems that he is using an x264 build that simply was not compiled with OpenCL support, which can only be fixed by re-compiling. And, according to JEEB, a new/fixed build is on the way.

On the other hand, my "fix" is intended to make x264 (if compiled with OpenCL support) work on systems without OpenCL hardware/drivers.

That's because, even if you don't want to use the new OpenCL functions of x264, it still needs an OpenCL DLL now! Without such DLL, current x264 won't even start. The "dummy" DLL fixes that.

Of course the OpenCL functions of x264 will not work at all with that "dummy" DLL ;)Ahhh... I thought he was getting the same error as the earlier posters -- I should have looked closer.

[CarlPig]

Those only affected the cases specified, but in any case I finally got to building 2310 builds. They should be put onto x264.nl as soon as jarod notes my ping to him to run the mirroring script. Until then they can be found here (http://x264.fushizen.eu/builds/revision2310/).

No changelog??

[cyberbeing]

No changelog??
Changelogs can always be found on x264.nl

The only change from r2309 to r2310 was this (https://github.com/DarkShikari/x264-devel/commit/76a5c3a19f97cd34b65aeff050de4042b054bc65) as mentioned in the previous post.