x264 rev2148+643 tMod ( Unofficial –device, now supports multiple device settings )
Sources on GitHub: https://github.com/astrataro/x264_tMod.
Use win32thread and fprofiled:
– 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.
00:L-Smash（including audio encoding）;
01:More detailed version head
02:Add back “touhou” tune
03:Film Grain Optimization
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
10:filters hqdn3d pad vflip yadif patch
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
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）
VSFilter svn-r3698 (MPC-HC)
opencore-amr-0.1.2 r178 git-08d6986
My other tools list ( including some of the x264 builds ) : MediaFire