Home > encode, x264, x264-bin > x264 rev2144+631 tMod ( Unofficial –device, this build may break frames )

x264 rev2144+631 tMod ( Unofficial –device, this build may break frames )

12th January 2012, Thursday Leave a comment Go to comments

Sources on GitHub: https://github.com/astrataro/x264_tMod.

Use win32thread and fprofiled:


Don’t use this build. It may break some frames (seems to be a bug in CABAC trellis). So does the latest rev2145 vanilla build.

Latest updates:

– Update x264 to git-devel rev2144, this version is much faster than rev2120, especially for 10-bit x64 build with –trellis 2.

– Other main changes are here.

—– 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.




–—––—–Download(L-Smash not included): patches-rev2140.7znmm-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 (new!!)
26:Unofficial –device (new!!)
27:More detailed “zones” help (new!!)
28-1:MixAQ-core;(only in tMod+MixAQ version, remove AQDebug)
28-2:OreAQ-core.(only in tMod+OreAQ version, remove AQDebug)

mingw-gcc 4.6.2

Libpack info:
libav git-r31722(3faa303)
ffms svn-r628
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-7-git-07931e3
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 ) : MediaFirenmm-hd

Categories: encode, x264, x264-bin
  1. david
    13th January 2012, Friday at 04,25am UTC

    in mediainfo when i encoded something it lists it as x264 core 120 r2144+631+27 e82835f tMod [10-bit@all X86_64] not 2145 like you have in the topic

  2. 13th January 2012, Friday at 06,31am UTC

    Oh yes, my mistake. It is rev2144.

  3. Mark080
    15th January 2012, Sunday at 02,35am UTC

    thanks 🙂
    i always use your builds.
    Can u give give some tips about some parameters of x264 for encoding(low bitrate) anime content(especially dark scene)?

    Should i use MixAQ-core for encoding anime.

    • 16th January 2012, Monday at 10,44am UTC

      If your bitrate is not TOO low, using 10-bit x264 will effectively reduce banding/blocking in dark areas.

      If capability with some hardware playback is needed, then maybe raising aq or using MixAQ is a good try. MixAQ can keep a better quality in flat dark/blue areas. VAQ is good enough for dark scene but may not be able to avoid banding in blue scenes. VAQ’s aq-mode=2 sometimes produces ugly blocking artifacts in dark areas, which is said to be somehow fixed in experimental aq-mode=3, but I’m not sure with it. Test by yourself.

      Another choice is using OreAQ with negative value ( to lower qp in dark/M.dark areas and raise qp in middle areas ). Positive value of OreAQ always gives poor quality in dark areas, but in some tests negative valuse is awesome. According to me, at least negative value for dark/m.dark areas and positive value for middle/bright areas worth a try.

      Some settings in –tune grain also results in better quality in dark areas by better detail retaining and thus less banding. For example, higher psy-rd/trellis, negative deblocking, lower deadzone(if not using trellis). But these tweaks usually helps with more detailed/texture sources. If your source is typical animation with many flat scenes, it may still be better to choose a higher aq instead for low bitrate encoding. –tune grain’s settings requires much higher bitrate value along with better quality, and I’m not sure if it is in your target bitrate range or not.

      And if your target bitrate limits is not too low, sometimes –no-mbtree can reduce banding artifacts significantly. But if you need an insane small size result, say, 70MB per episode for 720p 8-bit anime, forget it.

  4. Mark080
    16th January 2012, Monday at 12,07pm UTC

    Thanks 06_taro 🙂
    I will use 10-bit x264.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: