Sources on GitHub: https://github.com/astrataro/x264_tMod.
Use win32thread and fprofiled:
x264_rev2200+666_tMod-Libav.7z : NMM、GitHub、MediaFire
x264_rev2200+666_tMod-FFmpeg.7z : NMM、GitHub、MediaFire
x264_rev2200+666_tMod-Lite.7z : NMM、GitHub、MediaFire
x264_rev2200+668_tMod-opencl.7z (Lite version with opencl lookahead, only 8-bit, experimental, for test only. Built with AMD APP v2.6, should also works on NVidia GPUs with OpenCL support) : NMM、MediaFire
— Differences between FFmpeg/Libav version —:
Built with FFmpeg or Libav (also ffms was built with FFmpeg/Libav accordingly).
1. FFmpeg version uses libutvideo to decode utvideo, while Libav version uses libavcodec’s internal utvideo decoder. libavcodec has not implemented SIMD optimizations and is slower than libutvideo decoder. In some rare cases libavcodec fail to decode correct frame (not sure, I would like to report this to Libav/FFmpeg projects if I confirmed it is libavcodec’s issue), and libutvideo doesn’t have such problem.
2. FFmpeg version can decode celt audio via libcelt. celt codec doesn’t ensure capability with old version, and the libcelt in FFmpeg version is latest v0.11.3-19-git-r1588(e18de77) (standalone encoder/decoder binaries included). However, libcelt has stopped its development and moved to opus, and this final version of git should never be changed any more.
3. FFmpeg version supports more input-csp for raw input: rgba64be, rgba64le, bgra64be, bgra64le, 0rgb, rgb0, 0bgr, bgr0, yuva444p.
4. FFmpeg version accepts hacked high bit depth yuv4mpeg ( 420p9, 420p10, 420p16, 422p9, 422p10, 422p16, 444p9, 444p10, 444p16, which are not documented, and shouldn’t be used normally ) with
5. Some other differences can be found on Libav’s homepage.
Lite version (formerly Special_offer) has only tMod+MixAQ-8bit and tMod-10bit with 4:2:0 chroma subsampling, no interlaced/audio/lavf/swscale/ffms/avi-output support, smaller in size and might be faster in speed.
— Latest updates —:
– Updated to x264 to latest git-r2200.
– Added “Use f3kdb for bit depth conversion when needed” patch. SAP’s avisynth 16bit-hack patch always treats high bit depth avisynth input as 16-bit, even if you have specified
--input-depth=9~15, except for when input-depth equals to x264 binary’s output-depth, in which case bit depth conversion is simply skipped and this issue is avoided. E.g., 10-bit x264 only read 8/10/16 bit avisynth correctly, and if it read 9/11~15 bit avisynth script, it treated them as 16 bit without even a warning, and the result would be incorrect. Now with the new patch, x264 will call f3kdb to convert bit depth internally when input-depth does not equal to 8/16/output-depth, and the result should be correct. f3kdb’s dithering algorithm is hard-coded to 3 ( Floyd-Steinberg dithering ). Make sure flash3kyuu_deband.dll is in avisynth’s auto plugin loading directory.
– Updated “Fix AviSynth color space converting matrix” patch, in which incorrect high bit depth conversion is deleted. Also added “Fix swscale color space converting matrix”, but don’t rely on it. swscale is hell.
– Added “Support ‘dgi’ file extension” patch. Vanilla x264 automatically calls “mpeg2source” with avs demuxer when extension of input file is d2v, and calls “AVCSource” with avs demuxer when extension of input file is dga. And I think DGDecodeNV/DGAVCDecodeDI has also been widely used and should be added. Now x264-tMod will call “DGSource” when input extension is dgi.
— How to load subtitles internally —
These builds ported subtitles video-filter from direct264, and are able to render subtitles internally.
To render subtitles in this way, demuxer must be libav/ffms. Raw/avs demuxer is not supported for now. And VSFilter.dll(for 32-bit builds) or VSFilter64.dll(for 64-bit builds) must be placed together with the x264 binary or in the system path. Do NOT change filenames of them.
Rendering multiple subtitles is possible. Now you can render at most 16 subtitles simultaneously by calling
--sub for each subtitles. Note that the later calling of
--sub overlays the subtitles after previous calling of
--sub, so if several subtitles are in the same position, the last one should overlays on all those rendered before.
The VSFilters are modified to add custom csri API. Patches can be found in svn of direct264 project. Therefore do NOT replace them with other builds. BT.709/BT.601 is auto detected according to video resolution. For HD videos BT.709 is used and for SD videos BT.601 is used.
Both 8-bit and 10-bit builds can use subtitles rendering, but rendering should only take place in 8-bit colorspaces. For example, if the input video is 10-bit, which would be converted to yuv420p16le internally before encoding, you need to use “resize” filter to downscale it to 8-bit before “subtitles” filter:
--video-filter resize:csp=i420:8/subtitles --sub "subtitles.ass".
ICL build of VSFilter(64).dll might be faster than VC2010 build on Intel CPU, as VSFilter uses some intrinsic functions which are more optimized by ICL compiler. Rendered frames should be identical.
The commandline example to render subtitles:
x264_32_tMod-8bit-420.exe --sub "subtitles-1.ass" --sub "subtitles-2.ass" --sub "subtitles-3.ass" --video-filter [Other video filters/]subtitles[/Other video filters] [Other x264 options] --output "output.mp4" "input.mp4"
–—––—– Download: patches-rev2200.7z: NMM、MediaFire
00: L-Smash（including audio encoding）;
01: More detailed version head
02: Add back “touhou” tune
03: Film Grain Optimization
04: Fade Compensation
05: Remove stats before renaming
06: Add a parameter to set level of writing options in User Data Unregistered SEI
07: Utilize internal threading in lavf/ffms
08: Auto VBV settings
09: AVI output
10: filters hqdn3d pad vflip yadif patch
11: Log file
12: Encoding time
13: Level force
14: Profile force
16: New experimental AQ mode (modification of Auto-variance AQ)
17: Print video info with lavf/ffms demuxer
18: lto & Ofast
19: AviSynth 16bit hack
20: Skip bit depth filter when possible
21: Use f3kdb for bit depth conversion when needed (New!!)
22: Video filter: subtitles
23: Detect color matrix with lavf/ffms demuxer
24: Fix AviSynth color space converting matrix (Updated!!)
25: Fix swscale color space converting matrix (New!!)
26: Support “dgi” file extension (New!!)
27: High-precision fps, encoded file size & estimated total size
28: More detailed “zones” help
29: Add “libaacplus”
30: Unofficial –device
31-1: MixAQ-core;（only in tMod+MixAQ version, remove AQDebug）
31-2: OreAQ-core.（only in tMod+OreAQ version, remove AQDebug）
VSFilter-2.41 (MPC-HC v1.6.2 svn-r4886)
opencore-amr 0.1.3 git-r189(958395d)
vo-amrwbenc v0.1.2-5 git-r54(7d4ee39)
My other tools list ( including some of the x264 builds ) : MediaFire
Download links ( source codes are here):
excalibur version is a totally re-written experimental version by msg7086, and support
--x264-affinity. You can find more info running it with no options.
– Fix capability with high bit depth avs.
– Add parameter to customize x264 binary.
– Print full command line used by x264.
– Delete ugly blank space in command line, which was generated in v0.1 if “
– Fix invalid x264 binary path when both avs4x264 and x264 binary is given by full path
– Add switch
-L as a short name of
-L C:\x264.exe is equal to
– Directly output i422/i444 with AviSynth 2.6 new csp YV16/YV24. No forced ConvertToYV12 for these two csp any more. Thanks to SAPikachu.
– Display version and help info when run with no options.
– Improve capability with more styles of parameters in x264.
– Fix pipe error with YV12. This bug was introduced in v0.4.
– Do not add
--input-csp if already defined.
– Correct number of frames to be handled when
--frames is defined. Now you can specify frame numbers to be encoded without getting errors.
--frames when used with
--seek if no timecodes defined.
– Show more script information when opening avs.
"--seek-mode" paramters, and some minor bug fixes.
– Fix crash on XP/Server 2003, thanks to maki_rxrz.
– Made a mistake in my last “Fix crash on XP/Server 2003”, details: here. Thanks for bug report.
– Automatically add “
--timebase” when using “
--tcfile-in“. When timebase is not specified, x264 reads timebase from input source. For avisynth input, the timebase numerator should equal to framerate denominator, but for piped raw input without “
--fps“, the assumed timebase will turn to be strange values, and causes timecodes parsing process generates strange timebase too. Adding “
--timebase 1001” to NTSC 24000/30000 vfr source can solve such problems. I’ve been considering this fix for some time. I used to think people should always add
--tcfile-in by themselves, as automatically adding
--timebase may sometimes gives unwanted results. E.g., after tivtc’s automatic vfr, if you don’t call AssumeFPS, the fps of avisynth script may be unnormal, say 345023/12111, and avs4x264mod adds 12111 as timebase numerator, which I’m sure you don’t want to see. Or sometimes the input script is 24000/1001fps, but your timecodes file is _for_some_strange_reason_ 25/1fps, so adding
--timebase 1001 gives strange result. But anyway, avs4x264mod aims at completely replacing x264_64.exe in command line, and x264 itself has the same problems in these cases, so I decide to let avs4x264mod follow the same behavior. One can still override avs4x264mod’s decision by adding
--timebase manually in your command line, just as he should do with x264 when he doesn’t add AssumeFPS after tivtc’s vfr process.
— Call VersionString() instead of VersionNumber() in version detect, as there are too many builds with same version number, like SEt’s mt/2.6 builds.
"--seek-mode" ( string, "fast"/"safe", only affects how to deal with "--seek" )
– “fast” mode is similar to x264′s internal method of avs demuxer: skip frames until the frame
--seek indicates. However, when used with
--qpfile/--tcfile-in, it won’t skip but add a “FreezeFrame(0, seek, seek)” to avs script to actually skip the process of those frames. I have to play this trick because x264 regards qpfile/tcfile-in as qpfiles/timecodes of input files, not output files, so the frame numbers of input piped raw ( can be only linearly seeked in x264 ) has to be left untouched.
– “safe” mode uses a safer but slower method: delivering every untouched frame to x264. When the process of frames before “
--seek” frame is heavy, the “useless” running time of processing those frames will be much longer than “fast” mode, but the result is safer for scripts like TDecimate(mode=3), which can only be seeked in a linear way.
The x264 opencl lookahead patch has been tested for months on x264dev’s IRC, but it lacked too many features compared to currect x264, e.g., the weightp was still not supported at the beginning of May. However, it is glad to see the latest patch was released on doom10 yesterday, in which most features has been implemented (but only 8-bit, high bit-depth has not been supported). So a test build should be available here.
Based on tMod+MixAQ branch (rev2197+666+30). Compiled with fprofile and win32thread, and AMD APP v2.6, which may require OpenCL v1.1 runtime to enable opencl lookahead. Lavf/ffms/swscale/interlaced was disabled, and chroma format was set to 4:2:0. Tested on AMD HD6770M and NVidia GTX460, not sure if it can run on Ivy Bridge or not.
Download: MediaFire, NMM-Mirror
See the latest x264 build page for newer builds.
Attention: the patch may not be stable enough for everyday use, so this build should only be used for test purpose. Not only speed but also encoded results are not identical with or without opencl.