x264 rev2148+643 tMod ( Unofficial –device, now supports multiple device settings )
Sources on GitHub: https://github.com/astrataro/x264_tMod.
Use win32thread and fprofiled:
tMod／tMod-10bit／tMod+MixAQ／tMod+OreAQ:
Download: x264_rev2148+643_tMod.7z、GitHub-Mirror、nmm-hd-Mirror、Uploading.to-Mirror
Latest updates:
– Update x264 to git-devel rev2148, fix trellis 2 + subme >= 8 introduced in rev2143.
– Update –device, now supports multiple device parameters like “–device psp,iphone” or “–device psp+iphone+ps3”, parameters will be restricted by all the device limits. My patch does not restrict on resolution as I mentioned before, while the official –device does. The reason is some devices not only restricts highest resolution but also specifies the only resolutions to be handled. For example, PSP accepts resolution lower than 720×480, but XMB player can only decode resolution at 480×272/640×480/720×480, videos at resolutions like 704×480 won’t be played unless you use third-part players like PPA. Even the official –device does not handle this case ( it does not need, as it restricts PSP’s resolution to 480×272 ). It is much more complicated to implement auto-resizing, auto-padding, and auto-sar, for all devices with such restriction, and I don’t have so many devices to test on, so I simply dropped resolution checking and restriction.
– About two days ago libav began to use a new API for audio encoding, and this would break x264-audio’s capability. Till now not many useful updates are committed after that, and I’m too lazy to change API calling in x264-audio, so I still use the last revision of libav before this API change.
– Edit (on 20 Jan): Update l-smash for some bug fixes and supporting muxing DTS into mp4. It only works with –audiofile “raw DTS file.dts” –ademuxer lsmash –acodec copy. Muxing DTS into mp4 from lavf demuxer is not finished, so does extracting moov data from lsmash demuxer, so only raw DTS with lsmash demuxer works. Muxing DTS into mkv does not have this restriction.
– Edit (on 22 Jan): Add a patch from BugMaster to fix bug in packed YUV 4:2:2, and update l-smash which allows linking latest libav with changed audio encoding API.
—– 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 always takes place in 8-bit colorspaces.
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 subtitles[/Other video filters] [Other x264 options] –output “output.mp4″ “input.mkv”
——– Attention on high bit depth usage ——–
Several days before madshi pointed out that x264′s internal low bit depth to high bit depth conversion and high bit depth to low bit depth dithering is incorrect. The present converting and dithering algorithms seem to work correctly on full range sources of RGB and Y plane of YUV. Till now neither x264 nor swscale has a correct chroma upscaling algorithm for full range sources, and I didn’t make one. Anyway, the converting algorithm of x264 is absolutely wrong on limited range sources, according to ITU-R 601/709′s standard, in which the conversion should be done by simply appending LSBs of zero to the source. The dithering algorithm may also causes overflow on limited range source. So I hacked on my tMod builds to solve this issue.
When the input and output bit depth are the same, no conversion or dithering will be apllied. Otherwise when used with “–fullrange on”, the conversion and dithering will be exactly the same with x264′s original algorithm, which is still not reliable for YUV sources, so it is recommanded to use your own reliable approaches to convert those sources by yourself before passing them to my x264 builds; if used without “–fullrange on”, the conversion will be done by shifting according to the standard, and the dithering algorithm is fixed as well, so that the result should be absolutely right.
astrataro@gmail.com
——————–
Patches:
–—––—–Download（L-Smash not included）: patches-rev2148.7z, nmm-hd-Mirror
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:Correct the limited-range 8->10 conversion algorithm Now
18:Print video info with lavf/ffms demuxer
19:lto & Ofast
20:AviSynth 16bit hack
21:Skip bit depth filter when possible
22:Video filter: subtitles
23:Detect color matrix with lavf/ffms demuxer
24:Fix AviSynth color space converting matrix
25:High-precision fps
26:Unofficial –device (update!!)
27:More detailed “zones” help
28-1:MixAQ-core;（only in tMod+MixAQ version, remove AQDebug）
28-2:OreAQ-core.（only in tMod+OreAQ version, remove AQDebug）
Compiler：
mingw-gcc 4.6.2
Libpack info：
libav-v0.8-5-git-r31811(b263bf6)
ffms svn-r635
VSFilter svn-r3698 (MPC-HC)
lame 3.99-3
libvorbis-aotuv_b6.03 (libvorbis-1.3.2)
opencore-amr-0.1.2 r178 git-08d6986
vo-aacenc-v0.1.1-13-g9adecf2
vo-amrwbenc v0.1.1-6-git-dfc1623
aacplus 2.0.2
faac 1.28
qtsdk 7.3
—————————————————-
My other tools list ( including some of the x264 builds ) : MediaFire
天山牛棚 
thanks for new fixed build. 🙂
Need some help:
Can i use –no-mbtree with aq 0.7(10bit) to encode anime(BD source) with low bitrate?
Should i use high value for scenecut [60], rc_lookahead [60], keyint [300], keyint_min [30].
Is is good to use aq 3 ?
Now i m use this setting for encoding anime content(with low bitrate), please suggest me if anything need to be changed.
cabac=1 / ref=9 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.00 / psy_rd=0.20:0.00 / mixed_ref=1 / me_range=20 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-1 / threads=3 / sliced_threads=0 / nr=200 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=24.9 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=3:0.50
It is still content dependent. 10-bit encoding seldom introduces banding or blocking with a normal bitrate, so there is usually no need to turn mbtree off for low bitrate encoding, unless you need to retain much more details in non-noticeable areas, but that is often used with relatively higher bitrate. aq value is also dependent on content. Setting it higher with auto-variance aq mode may sometimes save bitrate for anime with little loss in quality. You can test on your sources, as many animes are actually quite grainy and may not fit for anime tune.
scenecut=40~50 should already be enough for scene change detection of anime content. Setting rc-lookahead higher can expand the lookahead of mbtree and may raise compression rate, but it won’t help much when set it higher than 60~72, and for now it is even harmful to set it too high, say, 250. keyint restricts the longest GOP length, so setting it higher or to infinite can avoid using unnecessary I frames which consume bitrate, but may also result in long GOPs and thus makes a playback waiting for a long time when seek to the frames in those GOPs. keyint-min decides whether an key frame should be IDR or non-IDR frame, and the frames before/after this frame can be referenced after/before this frame. It usually has very little effects to change this value. If needed, lower it to allow short GOP, which won’t cost much bitrate indeed.
If you like to keep the complexity in content, maybe it is useful to raise psy-rd/trellis. Or if you don’t care about that and like to degrain on the source, do it in avisynth instead of using –nr. –nr is fast, but its quality is usually not satisfying, in terms of both degraining strength and precision in grain/detail separating. There are many fast degrain filter like ff3dgpu/PNLM/TTempSmooth in avs. Even internal hqdn3d in my builds is better than –nr.