x264 (MABS build) with integrated FFMS2 and LAVF [Archive]

LigH

26th February 2018, 17:31

LoRd_MuldeR pointed me at it, and I can only confirm:

The x264 builds created by media-autobuild_suite including FFMS2 and L-SMASH Source (video codecs only = mode 6/"fullv") can't open AVI sources and eventually fall back to AviSynth, trying to use AviSource.

x264 -o *.mp4 *.avi
ffms [error]: could not create indexer
lavf [error]: could not open input file
avs [info]: trying AVISource... succeeded
...

I will try to create a full build (mode 4/"full"), wondering if possibly the limiting to video codecs only may cause issues. Could anyone else with enough insight possibly check if MABS might be misconfigured for this case? Or is it possible that there is indeed a mistake in current x264 sources?
_

In the meantime, issue #758 (https://github.com/jb-alvarado/media-autobuild_suite/issues/758) appeared, and commit c566f85 (https://github.com/jb-alvarado/media-autobuild_suite/commit/c566f85ed18a791f16c03c63da136b3f0272c731); will build again...

LoRd_MuldeR

26th February 2018, 18:08

Just want to add that the problem is not limited to AVI. Happens with MP4 or MKV as well.

The problem is always the same: FFMS reports "could not create indexer", and LAVF reports "could not open input file". Then x264 falls back to AVS.

Builds from here (http://msystem.waw.pl/x265/) do not have FFMS enabled (unfortunately), but LAVF input does work.

LigH

26th February 2018, 18:46

I just updated MABS and recompiled. x264 in 32 bit is already done, and here FFMS2 starts indexing (to RAM, I'd assume).

So I will release a new set soon.

LoRd_MuldeR

26th February 2018, 18:51

I just updated MABS and recompiled. x264 in 32 bit is already done, and here FFMS2 starts indexing (to RAM, I'd assume).

So I will release a new set soon.

Great. BTW, index is written to file (or reused from file) when using "--index" option.

LigH

26th February 2018, 19:55

Updated on MediaFire. Regards to wiiaboo for a quick response.

Fun fact: They are even smaller now.

LoRd_MuldeR

26th February 2018, 20:26

It is working now, thanks!

mkver

2nd March 2018, 19:16

I didn't thought that others stumbled upon this problem, too. I actually thought that it never ever worked at all and that no one used it so no one complained. It seems that I stand corrected. Just out of curiosity: When did it stop working?
PS: That they are smaller now is probably due to the disabling of some audio codecs. (I tested an earlier version of MABS and there was code for disabling, but it didn't work.) One can reduce the size of the builds even further:
The size of my light x264 build with MABS: 17376256 B (all builds are x64).
After disabling all bitstream filters and enabling the extract_extradata-bsf (my test show this to be needed to actually get the codec parameters from transport streams; the h2645_mp4toannexb bsf are not needed for h2645 in mp4/Matroska) this is down to 17159680 B.
After also (trying to, see below) disabling subtitle decoders this is down to 17126912 B.
And looking at the list of disabled codecs I noticed that quite a few audio and subtitle decoders aren't disabled. The reason: MABS currently only disables decoders for which there is an encoder of the same name (I think I will report this). Fixing this brings the size down to 14960128 B. (Side issue: I have observed that if the input file has an mp2 audio track, lavf now emits a warning that it couldn't find the codec parameters for this stream. This might also happen for other codecs; similar things might also happen with the currently used list of codecs to deactivate. Does anyone know a way to stop lavf emitting warnings for non-video codecs?)
Finally, I also disabled some of the things that ffmpeg enables by default, but which is (to the best of my knowledge) unusable for lavf inside x264.exe: I added --disable-amf --disable-d3d11va --disable-dxva2 --disable-iconv --disable-schannel --disable-cuda --disable-cuvid. Now the size is only 13884928 B.
The relevant part of my script now looks like the following:

audio_codecs=(
$(sed -n '/audio codecs/,/external libraries/p' ../libavcodec/allcodecs.c | \
sed -n "s/^[^#]*extern.* *ff_$[^ ]*$_decoder;/\1/p")
)
LDFLAGS+=" -L$MINGW_PREFIX/lib" \
log configure ../configure "${FFMPEG_BASE_OPTS[@]}" \
--prefix="$LOCALDESTDIR/opt/lightffmpeg" \
--disable-{programs,devices,filters,encoders,muxers,debug,sdl2,network,protocols,doc,bsfs} \
--enable-protocol=file,pipe \
--disable-decoder="$(IFS=, ; echo "${audio_codecs }")" --enable-gpl \
--enable-bsf=extract_extradata \
--disable-amf --disable-d3d11va --disable-dxva2 --disable-iconv --disable-schannel --disable-cuda --disable-cuvid
unset audio_codecs

Any suggestions/comments/improvements?

LoRd_MuldeR

10th August 2018, 19:31

I just updated MABS and recompiled. x264 in 32 bit is already done, and here FFMS2 starts indexing (to RAM, I'd assume).

So I will release a new set soon.

Some new commits have arrived in the official development tree. Any chance for updated x264 builds? :)
https://git.videolan.org/?p=x264.git;a=summary

(Highlights seem to include "4:0:0 (monochrome) encoding support" and "Sony XAVC" support)

LigH

10th August 2018, 20:08

New upload: x264 core:157 r2932 303c484

x264 0.157.2932 303c484
(libswscale 5.2.100)
(libavformat 58.17.101)
(ffmpegsource 2.30.0.0)
Win32: built on Aug 8 2018, gcc: 7.3.0
Win64: built on Aug 8 2018, gcc: 8.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LoRd_MuldeR

10th August 2018, 20:53

Sparktank

10th August 2018, 21:11

Thanks for the update!

LigH

2nd November 2018, 15:14

New (and updated) upload: x264 core:157 r2935 545de2f (https://www.mediafire.com/file/ytyyzuy5w4czqp4/x264_c157_r2935_545de2f.7z)

x264 0.157.2935 545de2f
(libswscale 5.2.100)
(libavformat 58.19.102)
(ffmpegsource 2.30.0.0)
Win32: built on Nov 1 2018, gcc: 7.3.0
Win64: built on Nov 1 2018, gcc: 8.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

13th December 2018, 16:13

New (and updated) upload: x264 core:157 r2935 545de2f (https://www.mediafire.com/file/6mz6lo66kkamda9/x264_c157_r2935_545de2f.7z)

x264 0.157.2935 545de2f
(libswscale 5.4.100)
(libavformat 58.24.100)
(ffmpegsource 2.30.0.0)
Win32: built on Dec 13 2018, gcc: 7.4.0
Win64: built on Dec 13 2018, gcc: 8.2.1 20181207
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

manolito

14th December 2018, 07:05

Thanks for the new build,
for me it is the fastest of all the current r2935 builds (only tested 32-bit version).

(Probably stupid) question:
What do I do with the included ffmsindex.exe?
I use X264 under StaxRip with the latest stable ffms2 version 2.23.1. I only use the 32-bit versions.
Should I replace the 2.23.1 version of ffmsindex with the version which comes with your build? Is it compatible, is it necessary, what are the advantages?

Cheers
manolito

LigH

14th December 2018, 07:12

I am not sure myself how useful a separate indexer is, but MABS builds it along x264. So I assume that x264 can make use of the index files if they are provided together with a source file, and the FFMS2 demultiplexer is used in x264.

qyot27

15th December 2018, 22:26

ffmsindex isn't built alongside x264, it's part of the FFMS2 build. It does nothing with/for x264.

From x264's --fullhelp,
--index <string> Filename for input index file
I just tested it; that parameter makes x264 output the index from the initial pass to <output filename> rather it being used from RAM, and it also specifies a previously-generated index file to use, skipping the indexing step.

The FFMS2 version will have to match exactly for any index written by ffmsindex.exe or ffms2.dll (via AviSynth, for instance) to work with x264. And if the FFMS2 linked into x264 is static, then that only holds true for the exact binaries used there - if/when an update to ffms2.dll/ffmsindex.exe happens, FFMS2 will be newer than the one in x264 and force x264 to re-generate the index file rather than re-using it (or vice-versa; in my short test, x264 and its linked FFMS2 was newer - October 2018 - than the C-plugin build, from September).

In other words, only bother with ffmsindex if you're using FFMS2 as a plugin for AviSynth or VapourSynth, not when using the FFMS2 input on x264. If you're only using x264, stick with the indices it saves when using the --index parameter.

LigH

15th December 2018, 22:31

sigh

And ffms2.dll is not built by MABS.

OK, so I can omit the separate indexer safely.

LigH

6th February 2019, 18:34

New (and updated) upload: x264 core:157 r2935 545de2f (https://www.mediafire.com/file/6k456czv3fc4ev8/x264_c157_r2935_545de2f.7z)

x264 0.157.2935 545de2f
(libswscale 5.4.100)
(libavformat 58.26.100)
(ffmpegsource 2.30.0.0)
Win32: built on Feb 6 2019, gcc: 7.4.0
Win64: built on Feb 6 2019, gcc: 8.2.1 20181214
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

13th March 2019, 10:30

New upload: x264 core:157 r2945 72db437 (https://www.mediafire.com/file/4btortb464dk8bc/x264_c157_r2945_72db437.7z/file)

x264 0.157.2945 72db437
(libswscale 5.4.100)
(libavformat 58.26.101)
(ffmpegsource 2.30.0.0)
Win32: built on Mar 12 2019, gcc: 7.4.0
Win64: built on Mar 12 2019, gcc: 8.3.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later
_

But wait! There's more...

New upload: x264 core:157 r2969 d4099dd (https://www.mediafire.com/file/xbapw6ra58gtxk1/x264_c157_r2969_d4099dd.7z/file)

x264 0.157.2969 d4099dd
(libswscale 5.4.100)
(libavformat 58.26.101)
(ffmpegsource 2.30.0.0)
Win32: built on Mar 13 2019, gcc: 7.4.0
Win64: built on Mar 13 2019, gcc: 8.3.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Interesting commitdiff remark (https://git.videolan.org/?p=x264.git;a=commitdiff;h=d4099dd4c722f52c4f3c14575d7d39eb8fadb97f):

Remove compatibility workarounds

This will break decoding with older versions of FFmpeg/Libav.

So keep your decoders up to date. I don't know how old is "too old" here...

manolito

14th March 2019, 04:16

So keep your decoders up to date. I don't know how old is "too old" here...

Please I need some clarifications here...
This will break decoding with older versions of FFmpeg/Libav.

Does this only apply to the X264 input, or does this mean that older player software or hardware won't be able to decode files created with this version any longer?

Out of curiosity I encoded a file with this latest r2969 32-bit version and tested if all my playing or transcoding software could handle it. No problem whatsoever, even under XP where I need to use some older decoders. And my Xtreamer box (latest firmware from 2011) also had no problems decoding the file.

Looks like a non-issue to me...

Cheers
manolito

filler56789

14th March 2019, 04:38

Please I need some clarifications here...

Does this only apply to the X264 input, or does this mean that older player software or hardware won't be able to decode files created with this version any longer?

Applies to the 4:4:4 [i.e., without chroma subsampling] streams generated by the newer x264 binaries:

- if( i_csp >= X264_CSP_I444 && h->param.b_cabac )
- {
- /* Disable 8x8dct during 4:4:4+CABAC encoding for compatibility with libavcodec */
- h->param.analyse.b_transform_8x8 = 0;

manolito

14th March 2019, 05:06

Thanks, I don't care about 4:4:4 chroma so I won't be affected...

LigH

14th March 2019, 07:48

I assume that libav fixed the decoding of strict video streams already a while ago, so x264 can now safely remove the compatibility changes for libav before a threshold date. But I don't know which date.

MasterNobody

14th March 2019, 07:52

Remove compatibility workarounds
This will break decoding with older versions of FFmpeg/Libav.
So keep your decoders up to date. I don't know how old is "too old" here...
Too old versions would mean versions before June/July of 2017. Corresponding patches where:
FFmpeg
avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4 (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=840b41b2a643fc8f0617c0370125a19c02c6b586)
avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264 (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=06dda70f1e7c69a3b1684af5e6930431c62c527a)
Libav
h264_cabac: Fix CABAC+8x8dct in 4:4:4 (https://git.libav.org/?p=libav.git;a=commit;h=18d3f36d3c4d0f2c3e702f970ff8b457d7d5e39c)
h264dec: fix Lossless Decoding (Profile 244) for 8x8 Intra Prediction (https://git.libav.org/?p=libav.git;a=commit;h=79c6477c2abd8cfa41eef0c4ac39779dd8a9ec8e)

With old versions of FFmpeg/Libav you can have problems decoding lossless or 4:4:4+CABAC streams encoded with new x264.

LigH

14th March 2019, 11:02

Okay ...
versions before June/July of 2017
means that ffmpeg v3.4 (released shortly after) should have it fixed already, and v4.x quite certainly.

sneaker_ger

14th March 2019, 11:14

You can remain compatible to "old" and "new" lossless ffmpeg decoding by setting --no-8x8dct at <1% compression loss.

But: is "Remove compatibility workarounds" really in your builds? It's still only part of the "master", not the "stable" branch. Has been like that since almost 2 years now.

nevcairiel

14th March 2019, 11:35

But: is "Remove compatibility workarounds" really in your builds? It's still only part of the "master", not the "stable" branch. Has been like that since almost 2 years now.

Actually "Remove compatibility workarounds" was only in the experimental sandbox for 2 years, it moved to master 7 days ago, and will presumably be in the next stable push, unless they take it back out at some point, since stable is generally "just" an older master.

LigH

14th March 2019, 11:35

MABS update logs for x264-git report:

HEAD is now at d4099dd4 Remove compatibility workarounds

And it jumped from x264 0.157.2945 72db437 to x264 0.157.2969 d4099dd within few hours yesterday. So maybe there was a merge?

sneaker_ger

14th March 2019, 11:44

Actually "Remove compatibility workarounds" was only in the experimental sandbox for 2 years, it moved to master 7 days ago, and will presumably be in the next stable push, unless they take it back out at some point, since stable is generally "just" an older master.
I see.

Can confirm the changes are also already in the "official" binaries from videolan.

LigH

18th July 2019, 07:53

New upload: x264 core:157 r2971 98ee9d2 (https://www.mediafire.com/file/c00773j7gv5udig/x264_c157_r2971_98ee9d2.7z/file)

x264 0.157.2971 98ee9d2
(libswscale 5.4.101)
(libavformat 58.28.102)
(ffmpegsource 2.31.0.0)
Win32: built on Jul 17 2019, gcc: 9.1.0
Win64: built on Jul 17 2019, gcc: 9.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Luckily, there was quite recent activity (https://code.videolan.org/videolan/x264/commits/master).

manolito

18th July 2019, 16:04

Any reason why VideoLan still has r2969 as the latest stable version? Is r2971 not ready for prime time yet?

LoRd_MuldeR

18th July 2019, 18:40

Any reason why VideoLan still has r2969 as the latest stable version? Is r2971 not ready for prime time yet?

At this time, the x264 "master" branch is at r2984, and the "stable" branch is at r2980, both committed yesterday. VideoLAN apparently haven't updated their build since March 12th.

https://pastebin.com/HkvZdjnQ

LigH

18th July 2019, 19:24

Ah, I built mine the day before. Maybe I will update soon™ again.

manolito

18th July 2019, 20:00

Thanks for the info...

This leads to the question how well new commits are tested before they are called stable. From FFmpeg I learned it the hard way that it is a bad idea to always use the very latest "stable" build because thorough testing is not a particular strength of the FFmpeg devs.

Is this different for X264? Should I upgrade to a new stable build immediately after it is released, or is it wiser to stick with older versions until there is a real need for an upgrade (like support for new formats, important bug fixes etc) ?

MasterNobody

18th July 2019, 20:35

At this time, the x264 "master" branch is at r2984, and the "stable" branch is at r2980, both committed yesterday. VideoLAN apparently haven't updated their build since March 12th.

https://pastebin.com/HkvZdjnQ
If you were subscribed to the <x264-devel (at) videolan.org> mailing list, you would know (https://mailman.videolan.org/pipermail/x264-devel/2019-July/012705.html) that new binaries can be downloaded from the new URL:
https://artifacts.videolan.org/x264/

LoRd_MuldeR

18th July 2019, 21:26

If you were subscribed to the <x264-devel (at) videolan.org> mailing list, you would know (https://mailman.videolan.org/pipermail/x264-devel/2019-July/012705.html) that new binaries can be downloaded from the new URL:
https://artifacts.videolan.org/x264/

Thanks for the info! Maybe the link on the x264 web-site (http://www.videolan.org/developers/x264.html) should be updated to the new location then...

LigH

19th July 2019, 12:40

New upload: x264 core:158 r2984 3759fcb (https://www.mediafire.com/file/v73fdcspz5txe7h/x264_c158_r2984_3759fcb.7z/file)

x264 0.158.2984 3759fcb
(libswscale 5.4.101)
(libavformat 58.28.102)
(ffmpegsource 2.31.0.0)
Win32: built on Jul 19 2019, gcc: 9.1.0
Win64: built on Jul 19 2019, gcc: 9.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

filler56789

20th July 2019, 17:08

https://git.videolan.org/ says:

MOVING TO GITLAB
We're moving projects to code.videolan.org, notably:

- x264

- VLC for WinRT

- VLC for Android

- VLMC

- NPAPI-VLC

- libdvdread

- libdvdnav

- libdvdcss

- biTStream

- DVBlast

- libdvbpsi

- libbluray

- libudfread

- libaacs

- libdplus

Regarding x264 specifically (or at least), the problem is that it's impossible to clone the x264 repository on GitLab through git :–/

=> git clone git://code.videolan.org/videolan/x264.git
Cloning into 'x264'...
warning: blah-blah-blah
fatal: unable to connect to code.videolan.org:
code.videolan.org[0: 88.191.250.9]: errno=No error

Oh, yes, anyone can download the latest tarball or zipball through a web browser, but then the compiled binary doesn't show the correct version /commit number -_-

nevcairiel

20th July 2019, 18:04

filler56789

20th July 2019, 18:47

Did you construct that URL yourself? Because I don't see it anywhere on the GitLab page.
When you select the Clone button there, it'll give you a valid URL: https://code.videolan.org/videolan/x264.git - which works just fine with "git clone". The git protocol is being deprecated all over the web because its insecure and unscalable, in favor of HTTPS.

HTTPS+git has never worked for me on Windows...
In this case specifically:

$ git clone https://code.videolan.org/videolan/x264.git
Cloning into 'x264'...
fatal: unable to access 'https://code.videolan.org/videolan/x264.git/': error setting certificate verify locations:
CAfile: R:/MAKE6T4/usr/lib/ssl/certs/ca-bundle.crt
CApath: none

OTOH, the git protocol has always worked with the old URL, git.videolan.org/x264.git

EDIT 1:

Okay, I found a workaround, and now git finally 1) "understands" HTTPS and 2) found the damn certificate because I created the directory where the stupid application expected to find it.

</CASE_CLOSED>

EDIT 2:

So far Mercurial has never shown the limitations that git shows on Windows... Until 2 days ago, I had always used git with cmd.exe and in this way it only works with the git protocol... whereas Mercurial has always worked fine on the so-called command-prompt of Windows.

nevcairiel

20th July 2019, 19:54

Git has always worked fine for me on Windows, but I use the official Git for Windows, which I told to use the Windows SSL library, and not whatever mingw uses with its own certificate stuff.

filler56789

21st July 2019, 19:51

Git has always worked fine for me on Windows, but I use the official Git for Windows, which I told to use the Windows SSL library, and not whatever mingw uses with its own certificate stuff.

Well ++ FWIW ++ just-for-the-record:

I moved from MSYS1 to MSYS2 in 2016, and since then I have used only and always a sufficient subset of the ~portable git package~ downloaded from the official Git source :)

msysgit, and that tiny subset "just worked" as well.]

Because I just want to download source-code through git, and because I still hadn't found a git server that refuses the git protocol, there was no problem for me in using just some .EXEs instead of the entire git package.

Let's be honest, at least for needs like mine, git is BLOATWARE :mad: and bloatware is pure evil :D

Not to mention that its Windows port is not as good as their creators and maintainers believe...
for example, I don't see the point
(assuming there is a (good) point)
in hardcoding exec_path = /mingw##/libexec/git-core in the Windows releases.
Why didn't they choose /usr instead? :confused:

Anyway, fortunately I discovered that placing the folders *ssl* and *git-core* in the same parent directory is what git.exe requires for dealing with HTTPS
(both under the MSYS2 environment and under cmd.exe).

LigH

22nd July 2019, 09:35

The media-autobuild suite loads x264 nicely from the mentioned server. It runs Mercurial (hg) for x265 or git for x264, as required, in MSYS2/MinGW.

LigH

2nd January 2020, 20:21

New upload: x264 core:159 r2991 1771b55 (https://www.mediafire.com/file/nkf884e1hse9byr/x264_c159_r2991_1771b55.7z/file)

x264 0.159.2991 1771b55
(libswscale 5.6.100)
(libavformat 58.35.101)
(ffmpegsource 2.31.0.0)
built on Jan 2 2020, gcc: 9.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Happy New Year 2020

LoRd_MuldeR

3rd January 2020, 00:35

New upload: x264 core:159 r2991 1771b55 (https://www.mediafire.com/file/nkf884e1hse9byr/x264_c159_r2991_1771b55.7z/file)

Happy New Year 2020

:thanks:

LigH

17th April 2020, 12:13

New upload: x264 core:160 r3000_33f9e14 (https://www.mediafire.com/file/emu0ntukrasrn2m/x264_c160_r3000_33f9e14.7z/file)

x264 0.160.3000 33f9e14
(libswscale 5.6.101)
(libavformat 58.42.100)
(ffmpegsource 2.31.0.0)
built on Apr 16 2020, gcc: 9.3.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LoRd_MuldeR

17th April 2020, 20:06

LigH

19th May 2020, 10:50

Updated archive: x264 core:160 r3000_33f9e14 (https://www.mediafire.com/file/105p4mb7e6qh5ek/x264_c160_r3000_33f9e14.7z/file)

x264 0.160.3000 33f9e14
(libswscale 5.6.101)
(libavformat 58.43.100)
(ffmpegsource 2.31.0.0)
built on May 18 2020, gcc: 10.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

manolito

19th May 2020, 13:08

Thanks for the update...

The only differences I can see is a new gcc version and a newer libavformat version. X264 itself has not changed, so does the new build make a difference for real life encodes?

LigH

19th May 2020, 14:17

I doubt; just for the people who can't sleep without bleeding edge software.

manolito

19th May 2020, 16:41

This excludes me...

LigH

25th June 2020, 07:57

New upload: x264 core:160 r3009 4c9b076 (https://www.mediafire.com/file/xaha9bun0knwarj/x264_c160_r3009_4c9b076.7z/file)

x264 0.160.3009 4c9b076
(libswscale 5.8.100)
(libavformat 58.47.100)
(ffmpegsource 2.31.0.0)
built on Jun 22 2020, gcc: 10.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

benwaggoner

26th June 2020, 20:09

New upload: x264 core:160 r3009 4c9b076 (https://www.mediafire.com/file/xaha9bun0knwarj/x264_c160_r3009_4c9b076.7z/file)
Is this a new release? I've not been able to find any current changelog or release notes.

LoRd_MuldeR

26th June 2020, 22:15

Is this a new release? I've not been able to find any current changelog or release notes.

TTBOMK, x264 doesn't really have "releases", just a bunch of commits pushed the official Git repository every know and then. But yes, there have been a few fixes recently.

You can simply look at the Git log:
https://code.videolan.org/videolan/x264/-/commits/master

...or just:
https://gist.github.com/lordmulder/659f10c33cd9e47400c990c0312c0763

masterkivat

4th July 2020, 02:49

I don't want to steal LigH's protagonism in providing builds, but I just set up MABS here in my machine and I'm enjoying it, it's a great tool for people like me who know "nothing" about compiling audio/video encoders.
Anyways, I noticed that a new rev for x264 was up and I decided to upload the build I got from MABS: x264 0.161.3015 4c2aafd (https://drive.google.com/file/d/1i_C7DZrPqFMJUnWxoozqF2WkQqE4RXMw/view?usp=sharing)

>x264 --version
x264 0.161.3015 4c2aafd
(libswscale 5.8.100)
(libavformat 58.48.100)
(ffmpegsource 2.31.0.0)
built on Jul 3 2020, gcc: 10.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Hope everything went fine with it :)

LigH

4th July 2020, 19:42

I do not mind at all. So I have less pressure.

:thanks:

masterkivat

15th July 2020, 08:36

x264 0.161.3018 db0d417 (https://drive.google.com/file/d/1BLxqUnDJ7OEsBNAygJBV35Cy5HOvHOd5/view?usp=sharing)

>x264 -V
x264 0.161.3018 db0d417
(libswscale 5.8.100)
(libavformat 58.50.100)
(ffmpegsource 2.31.0.0)
(lsmash 2.16.1)
built on Aug 11 2020, gcc: 10.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

15th July 2020, 13:15

New upload: x264 core:161 r3018 db0d417 (https://www.mediafire.com/file/gighyvj11eic3vy/x264_c161_r3018_db0d417.7z/file)

x264 0.161.3018 db0d417
(libswscale 5.8.100)
(libavformat 58.48.100)
(ffmpegsource 2.31.0.0)
(lsmash 2.16.1)
built on Jul 15 2020, gcc: 10.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

25th August 2020, 14:52

Updated archive: x264 core:161 r3018 db0d417 (http://www.mediafire.com/file/52jccaqwfwr46ig/x264_c161_r3018_db0d417.7z/file)

x264 0.161.3018 db0d417
(libswscale 5.8.100)
(libavformat 58.51.100)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on Aug 25 2020, gcc: 10.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

masterkivat

27th October 2020, 04:24

x264 0.161.3027 4121277 (x64) (https://drive.google.com/file/d/13225xIoyguwclhZZJbjxQ-MkCzmQxqwi/view?usp=sharing)

>x264 -V
x264 0.161.3027 4121277
(libswscale 5.8.100)
(libavformat 58.63.100)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on Oct 26 2020, gcc: 10.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

17th November 2020, 09:02

New upload: x264 core:161 r3027 4121277 (https://www.mediafire.com/file/u37ttprv2xdprxz/x264_c161_r3027_4121277.7z/file)

x264 0.161.3027 4121277
(libswscale 5.8.100)
(libavformat 58.64.100)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on Nov 16 2020, gcc: 10.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

masterkivat

4th January 2021, 09:11

Happy New 2021, dear friends! :D

x264 0.161.3030 8bd6d28 (x64) (https://drive.google.com/file/d/1WmB6h-lPy3KOL6F_KXrkhbGWH7SypVBT/view?usp=sharing)

>x264 -V
x264 0.161.3030 8bd6d28
(libswscale 5.8.100)
(libavformat 58.65.101)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on Jan 4 2021, gcc: 10.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

masterkivat

24th January 2021, 21:15

x264 0.161.3039 544c61f (x64) (https://drive.google.com/file/d/1AcsBBJqJFqSrsB5i6lQFQwFqsmQu28Jz/view?usp=sharing)

>x264 -V
x264 0.161.3039 544c61f
(libswscale 5.8.100)
(libavformat 58.65.101)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on Jan 24 2021, gcc: 10.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

masterkivat

5th February 2021, 05:25

x264 0.161.3043 59c0609 (x64) (https://drive.google.com/file/d/1AGc_JmELtBb4ITnneQjhFW6GUjgM5HrO/view?usp=sharing)

>x264 -V
x264 0.161.3043 59c0609
(libswscale 5.8.100)
(libavformat 58.66.100)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on Feb 5 2021, gcc: 10.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

17th February 2021, 13:06

New upload: x264 core:161 r3048 b86ae3c (http://www.mediafire.com/file/3bqj11613lvaixy/x264_c161_r3048_b86ae3c.7z/file)

x264 0.161.3048 b86ae3c
(libswscale 5.8.100)
(libavformat 58.67.100)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on Feb 15 2021, gcc: 10.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

masterkivat

15th April 2021, 07:40

x264 0.161.3053 c347e7a (x64) (https://drive.google.com/file/d/1khw5OwRYpRLbeSI10zJzxOP4ICmu_7Vl/view?usp=sharing)

>x264 -V
x264 0.161.3053 c347e7a
(libswscale 5.10.100)
(libavformat 58.78.100)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on Apr 15 2021, gcc: 10.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

masterkivat

27th May 2021, 13:10

got a bit busy IRL but I just updated MABS here :D

x264 0.163.3059 b684ebe (x64) (https://pixeldrain.com/u/1i1D1ds3)

>x264 -V
x264 0.163.3059 b684ebe
(libswscale 6.0.100)
(libavformat 59.2.101)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on May 27 2021, gcc: 10.3.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

29th May 2021, 20:42

Updated build and link:

x264 core:161 r3048 b86ae3c (https://www.mediafire.com/file/i6w8x7x1z0pu7kz/x264_c163_r3059_b684ebe.7z/file) (Win32 + Win64)

x264 0.163.3059 b684ebe
(libswscale 6.0.100)
(libavformat 59.2.101)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on May 30 2021, gcc: 10.3.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

tormento

3rd June 2021, 10:10

Updated build and link:
Does it include HBD support with dithering?

masterkivat

20th June 2021, 07:49

x264 0.164.3065 ae03d92 (x64) (https://pixeldrain.com/u/jCUSn3by)

>x264 -V
x264 0.164.3065 ae03d92
(libswscale 6.0.100)
(libavformat 59.3.100)
(ffmpegsource 2.40.0.0)
(lsmash 2.16.1)
built on Jun 20 2021, gcc: 10.3.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

20th June 2021, 11:13

Does it include HBD support with dithering?

I have no clue. Not even how to discover that. Does it need any config parameter set? Is that a recent addition, additional patch?

I only know it contains 8 and 10 bit encoder cores.

tormento

20th June 2021, 12:46

Not even how to discover that. Does it need any config parameter set? Is that a recent addition, additional patch?
Look from this post (https://forum.doom9.org/showthread.php?p=1937617#post1937617) on.

LigH

21st June 2021, 17:44

Aha. So I am quite sure my MABS builds don't contain a patch for this case.

MasterNobody

21st June 2021, 19:08

Aha. So I am quite sure my MABS builds don't contain a patch for this case.

As I already said in this post (https://forum.doom9.org/showthread.php?p=1938033#post1938033): vanilla builds doesn't include "avisynth 16bit hack" patch so there is nothing to fix in them. So if MABS compiles vanilla builds than it doesn't need any patches to fix tormento's problem.

tormento

22nd June 2021, 10:33

vanilla builds doesn't include "avisynth 16bit hack"
Thanks for your clarification. Can you tell if they include the Sierra dithering when feeded with HBD source and 8bit output is asked?

MasterNobody

22nd June 2021, 20:34

Thanks for your clarification. Can you tell if they include the Sierra dithering when feeded with HBD source and 8bit output is asked?
Yes, Sierra-2-4A error diffusion dithering (https://code.videolan.org/videolan/x264/-/blob/ae03d92b52bb7581df2e75d571989cb1ecd19cbd/filters/video/depth.c#L78) is part of depth filter of vanilla x264 builds. In vanilla x264 builds you can't disable it.

tormento

23rd June 2021, 07:54

Yes, Sierra-2-4A error diffusion dithering (https://code.videolan.org/videolan/x264/-/blob/ae03d92b52bb7581df2e75d571989cb1ecd19cbd/filters/video/depth.c#L78) is part of depth filter of vanilla x264 builds. In vanilla x264 builds you can't disable it.

Thanks!

It would be really useful to have a list of x264 builds having or not those two, at least for builders on this forum.

LigH

9th December 2021, 17:00

New upload: x264 core:164 r3079 d9a19f0 (https://www.mediafire.com/file/osxct6ir8jvg55w/x264_c164_r3079_d9a19f0.7z/file)

x264 0.164.3079 d9a19f0
(libswscale 6.1.101)
(libavformat 59.9.102)
(ffmpegsource 3.0.1.0)
(lsmash 2.16.1)
built on Dec 9 2021, gcc: 11.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

filler56789

9th December 2021, 21:07

New upload: x264 core:164 r3079 d9a19f0 (https://www.mediafire.com/file/osxct6ir8jvg55w/x264_c164_r3079_d9a19f0.7z/file)

Thanks! :thanks:

LigH

28th May 2022, 22:22

New upload: x264 core:164 r3094 bfc87b7 (https://www.mediafire.com/file/qml6w48l7hk9zvq/x264_c164_r3094_bfc87b7.7z/file)

x264 0.164.3094 bfc87b7
(libswscale 6.6.100)
(libavformat 59.24.100)
(ffmpegsource 3.0.1.0)
(lsmash 2.16.1)
built on May 28 2022, gcc: 12.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

kebulek

30th May 2022, 13:16

Thanks! :thanks:

LigH

30th July 2022, 20:09

New upload: x264 core:164 r3095 baee400 (https://www.mediafire.com/file/oi5bzvskoavfati/x264_c164_r3095_baee400.7z/file)

x264 0.164.3095 baee400
(libswscale 6.8.101)
(libavformat 59.29.100)
(ffmpegsource 3.0.1.0)
(lsmash 2.16.1)
built on Jul 30 2022, gcc: 12.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

10th September 2022, 11:26

New upload: x264 core:164 r3098 7628a56 (https://www.mediafire.com/file/ehwi7vmwosb4tuc/x264_c164_r3098_7628a56.7z/file)

x264 0.164.3098 7628a56
(libswscale 6.8.108)
(libavformat 59.30.101)
(ffmpegsource 3.0.1.0)
(lsmash 2.16.1)
built on Sep 9 2022, gcc: 12.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

28th October 2022, 11:50

New upload: x264 core:164 r3101 b093bbe (https://www.mediafire.com/file/k48joaa5sck6puh/x264_c164_r3101_b093bbe.7z/file)

x264 0.164.3101 b093bbe
(libswscale 6.8.112)
(libavformat 59.34.101)
(ffmpegsource 3.0.1.0)
(lsmash 2.16.1)
built on Oct 27 2022, gcc: 12.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

23rd February 2023, 00:45

New upload: x264 core:164 r3106 eaa68fa (https://www.mediafire.com/file/a0d5nt06ssfl7m1/x264_c164_r3106_eaa68fa.7z/file)

x264 0.164.3106 eaa68fa
(libswscale 7.2.100)
(libavformat 60.4.100)
(ffmpegsource 3.0.1.0)
(lsmash 2.16.1)
built on Feb 21 2023, gcc: 12.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

17th July 2023, 21:35

New upload: x264 core:164 r3107 a8b68eb (https://www.mediafire.com/file/r4cp8icj8lzo0ar/x264_c164_r3107_a8b68eb.7z/file)

x264 0.164.3107 a8b68eb
(libswscale 7.3.100)
(libavformat 60.10.100)
(ffmpegsource 3.1.1.0)
(lsmash 2.16.1)
built on Jul 17 2023, gcc: 13.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

20th February 2024, 16:22

New upload: x264 core:164 r3179 12426f5 (https://www.mediafire.com/file/52glyk5nr6afq2d/x264_c164_r3179_12426f5.7z/file)

x264 0.164.3179 12426f5
(libswscale 7.6.100)
(libavformat 60.21.101)
(ffmpegsource 3.1.1.0)
(lsmash 2.16.1)
built on Feb 20 2024, gcc: 13.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

1st March 2024, 21:39

New upload: x264 core:164 r3182 be4f020 (https://www.mediafire.com/file/7du2yb0uc1shwna/x264_c164_r3182_be4f020.7z/file)

x264 0.164.3182 be4f020
(libswscale 7.6.100)
(libavformat 60.22.101)
(ffmpegsource 5.0.0.0)
(lsmash 2.16.1)
built on Feb 29 2024, gcc: 13.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

FranceBB

2nd March 2024, 00:28

Thanks for the new build. :)

LigH

21st May 2024, 21:41

New upload: x264 core:164 r3191 4613ac3 (https://www.mediafire.com/file/6vxa74hzi4pl1ya/x264_c164_r3191_4613ac3.7z/file)

x264 0.164.3191 4613ac3
(libswscale 8.2.100)
(libavformat 61.3.103)
(ffmpegsource 5.0.0.0)
(lsmash 2.16.1)
built on May 20 2024, gcc: 14.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

LigH

19th July 2024, 20:31

New upload: x264 core:164 r3191 4613ac3 (https://www.mediafire.com/file/a5eizx3kmagxtq4/x264_c164_r3191_4613ac3.7z/file)

x264 0.164.3191 4613ac3
(libswscale 8.2.100)
(libavformat 61.5.101)
(ffmpegsource 5.0.0.0)
(lsmash 2.16.1)
built on Jul 18 2024, gcc: 14.1.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Same x264 code as last build, updated libav components

FranceBB

22nd July 2024, 07:51

Since x264 itself was unchanged, I'll skip it this time round, but thank you anyway. :)

LigH

7th November 2024, 23:47

New upload: x264 core:164 r3198 da14df5 (https://www.mediafire.com/file/6ti4p85ur9cxczj/x264_c164_r3198_da14df5.7z/file)

x264 0.164.3198 da14df5
(libswscale 8.9.101)
(libavformat 61.9.100)
(ffmpegsource 5.0.0.0)
(lsmash 2.16.1)
built on Oct 29 2024, gcc: 14.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

FranceBB

9th November 2024, 00:29

Looks like there aren't many changes between x264 0.164.3191 and x264 0.164.3198 when it comes to Windows and x86.

Commits:

configure: Check for SVE support in MS armasm64 via as_check

aarch64: Use elf_aux_info() for CPU feature detection on FreeBSD/OpenBSD

Provide x264_getauxval() wrapper for getauxvaul() and elf_aux_info()

configure: Add DragonFly support

Fix build with Android NDK and API < 24 for 32-bit targets

Use getauxval() on Linux and elf_aux_info() on FreeBSD/OpenBSD on arm/ppc

Make use of sysconf(3) _SC_NPROCESSORS_ONLN and _SC_NPROCESSORS_CONF

I wonder if they're ever gonna introduce 10bit planar input support from Avisynth.
I know that x264 currently supports 16bit planar input from Avisynth and I can always bring everything to 16 bit and then let it dither down, but if I'm not making any calculations at 16 bit and my sources are all 10 bit, having to go to 16 only to get back to 10 feels a bit... convoluted. Another thing I'd love to see is AVX512 for the 10 bit version. Currently only the 8bit version supports AVX512 while the 10bit version stops at AVX2. Arguably the 10bit version would benefit more from AVX512 assembly optimizations.

Anyway we'll see if someone is gonna have the time and will to do that.

Thank you for the build, as always. ;)