x264 build discussion

[zerowalker]

Okay i compiled from DarkShikari, but the x264 is just 1.4mb, compared to the vanilla which is like 10mb.
It feels like something is wrong, but i can use it and all, with opencl.

[J_Darnley]

Do you have the ffmpeg libraries installed? They're what takes most of that space when you compile with them.

[zerowalker]

Don´t know, probably not.
Got the ffdshow decoder/encoder, but that´s probably not it.

Do i need them?
I use Avisynth when i encode, so the decoding is not done by x264 i think.

[Groucho2004]

Don´t know, probably not.
Got the ffdshow decoder/encoder, but that´s probably not it.

Do i need them?
I use Avisynth when i encode, so the decoding is not done by x264 i think.
The binary I build for my encoding is only about 850K. I disable everything I don't need apart from AVS input:
--disable-gpac
--disable-swscale
--disable-lavf
--disable-ffms

[zerowalker]

Ah, good to know:)

But, where can i find the "latest and greatest" x264?
Is the vanilla the best in quality terms?

Cause i don´t even know how good DarkShikari´s is.
I only know that it has OpenCL.

Thanks

[LoRd_MuldeR]

Don´t know, probably not.
Got the ffdshow decoder/encoder, but that´s probably not it.

Do i need them?
I use Avisynth when i encode, so the decoding is not done by x264 i think.

If you don't build x264 with FFMS2 plus libavcodec/libavformat (FFmpeg), then you can't use FFMS2/libavf input.

Also, if you don't build with GPAC, you can't use MP4 output...

And without PThread (pthreads-win32) you won't get multi-threading, which means x264 will be sloooow!

Note that "installing" those libraries/tools (as pre-compiled DLL/EXE files) isn't sufficient! You need to build those libraries yourself in order to get the required .a/.lib files as well as the corresponding header (.h) files. And these need to be put into the proper directories of your MinGW installation...

Note also that ./configure will pick up those "extra" libraries automatically, if available. Otherwise they just are disabled. So usually there's no need to enable/disable them explicitly.

But, where can i find the "latest and greatest" x264?

The x264 Git repository would be a good place to start :p

http://git.videolan.org/gitweb.cgi?p=x264.git

[zerowalker]

Well is that the one that´s the "best"?
Cause DarkShikari seems more updated, but don´t know if it´s just a test/modding of x264 from the vanilla.

[LoRd_MuldeR]

Well is that the one that´s the "best"?
Cause DarkShikari seems more updated, but don´t know if it´s just a test/modding of x264 from the vanilla.

There is no "best" one ;)

There is the official repository which I pointed to. And, of course, everybody can fork of his own repository for whatever reason. Such "clones" may just be exact 1:1 copies, they may contain experimental patches (custom modifications) or they may simply be very outdated. Also some x264 developers have their own "private" repository for testing out things before they get committed into the official x264 repository. These often contain stuff that is not ready for the masses yet. Thus, usually you want to stick with the official repository.

[zerowalker]

Yeah well i know, that´s why i used the "", i simply wanted to know if there is one that usually goes along smoother than the vanilla.
As it seems to be many mods out there, like MixAQ etc, not sure if they are awesome, or just plain bad though, as i just heard of these non-vanilla.

Is there any recommendations of modded x264 to use, or do you all just stick with the vanilla?

[LoRd_MuldeR]

Of course nothing "goes along smoother" than the official version, because that obviously is the most widely used and most tested version.

About "unofficial" patches: If a patch doesn't get merged into the official repository sooner or later, it means that the patch either didn't improve things in the general case (there may be special cases where it does, but also cases where it makes things worse) or it simply became obsolete. Well, or nobody really cared about testing and finalizing the patch. So, just throwing in random patches is a bad idea!

(If you include a specific patch, you should know what it does exactly and why you need that)

[zerowalker]

Makes sense, guess i will stick along the vanilla as usual.
As well DarkShikari´s build with OpenCL didn´t improve my speed much, if any at all.

Though i do think his build had better quality compared to the vanilla.
But as it was 16 crf, i can´t really compare them and say which is better, probably my eyes playing tricks on me.

[LoRd_MuldeR]

Though i do think his build had better quality compared to the vanilla.

Do you really think that if the x264 developers had new features ready that generally improve things they wouldn't merge them into the official repository ???

If something doesn't get merged (yet), then that's probably for a good reason. It means that the new feature needs more testing, it needs to be fixed/finalized before it's ready or it turned out to be a fail (and thus will be dropped). So, feel free to test new "experimental" stuff and help the development, but don't complain if you get unexpected results or even crashes ;)

But as it was 16 crf, i can´t really compare them and say which is better, probably my eyes playing tricks on me.


That's why we generally do comparisons with 2-Pass mode and compare only files of the same file size!

And even if you use 2-Pass mode, don't pick an absurdly high bitrate where both encodes look transparent, because this way you'll learn nothing ^^

[Dark Shikari]

Did you make sure to turn OpenCL on (and confirm that it actually was on)? It's not on by default.

x264-devel is a staging tree; eventually pretty much all the patches on it will reach the x264 tree. But it's just a mirror of my local tree, so all kinds of basroken/unfinished things might end up on it at any given time. I basically use it as a lazy pastebin in some respects.

I'd say "don't use it for serious encoding", but I do also need people to test the OpenCL builds, as I'm still hearing enough about problems with it that I feel a little uncomfortable pushing it to trunk.

[sl1pkn07]

the official git (videolan repository) and devel git (Dark Shikari github) don't like the ffms2 svn version (r753) build with latest ffmpeg git (both with static libs)

http://sl1pkn07.no-ip.com/paste/view/4b7b4777