Home > encode, x264, x264-bin > x264 rev2197+664 tMod ( Update VSFilter )

x264 rev2197+664 tMod ( Update VSFilter )

18th April 2012, Wednesday Leave a comment Go to comments

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

Use win32thread and fprofiled:

tMod/tMod-10bit/tMod+MixAQ/tMod+OreAQ:
Download:
x264_rev2197+664_tMod-v2.7z : NMMMediaFire
x264_rev2197+664_tMod-v2-Special_offer.7z : NMMMediaFire

Special offer has only tMod+MixAQ-8bit and tMod-10bit with 4:2:0 chroma subsampling, no interlaced/audio/lavf/swscale/ffms support, smaller in size and might be faster in speed.

Latest updates:
– Updated to x264-devel.
– Updated “High-precision fps, encoded file size & estimated total size” patch.
– Updated libav to fix a regressive crash on 10-bit H.264 decoding.
– Updated VSFilter to latest MPC-HC svn-r4429, also added icl 12.1 build of VSFilter.dll.
– Replaced “libvo-aacenc” by “libaacplus”. The quality of the former is too poor (even worse than faac at most bitrate level), while the later is somehow useful for low bitrate aac. But libaacplus and libvo-aacenc cannot be linked together. Even if I do some hack to make both of them linked in the binary, at least one of them cannot work, so I dropped libvo-aacenc. Also note that libaacplus always uses SBR (and sometime with PS, if the bitrate is even lower), and the maximum bitrate of libaacplus is 72kbps.

Also add support for “high10″/”high422″/”high444p” and Level 5.2 in TAEC.py / avc_refclac.py

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

Patches:
–—––—– Download(L-Smash not included): patches-rev2197.7z: NMMMediaFire
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:Video filter: subtitles
22:Detect color matrix with lavf/ffms demuxer
23:Fix AviSynth color space converting matrix
24:High-precision fps, encoded file size & estimated total size (Update!!)
25:More detailed “zones” help
26:Unofficial --device
27:Add “libaacplus” (New!!)
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.7.0

Libpack info
libav-v0.8-1492-git-r33298(d7458bc)
ffms svn-r673
VSFilter-2.41 (MPC-HC v1.6.2 svn-r4492)
lame 3.99-5
libvorbis-aotuv_b6.03 (libvorbis-1.3.3)
opencore-amr 0.1.3 git-r189(958395d)
vo-amrwbenc v0.1.2-3 git-r52(6ffcea9)
libaacplus-2.0.2
faac 1.28
qtsdk 7.3

—————————————————-
My other tools list ( including some of the x264 builds ) : MediaFire

Categories: encode, x264, x264-bin
  1. esquall
    20th April 2012, Friday at 11,44am UTC

    thanks of the updates🙂

  2. Curious
    20th April 2012, Friday at 11,18pm UTC

    I wonder why but when I encode with your build, it consume more time than using vanilla build. My spec is intel core i5.

    • 22nd April 2012, Sunday at 05,56pm UTC

      It is possible. tMod adds too many features, which may slow down the encoding. But I don’t think there’s large difference in speed, say, up to 3%, with moderate preset like “medium”. If there is, it is most probably caused by compiling configurations which are not optimized best for your OS/hardware, such as pthread vs win32thread, but not those patches. And if you only need avisynth input, 4:2:0 output, no audio/swscale support, try special offer to see if it is by any chance faster.

  3. Curious
    22nd April 2012, Sunday at 10,05pm UTC

    Did different of -march parameter while compilng also affect the speed, beside win32thread/pthread? As I know we can optimize them for specific system like amdfarm, p3 but what is suit best for intel core i5 processor?
    I’m thinking to try compile x264 myself🙂
    Just curious

    • 23rd April 2012, Monday at 12,58am UTC

      Yes, it may have some effect, core i5 processor might benefit from -march=corei7, but don’t expect too much. IIRC, a report from ffmpeg mail-list said that -march=corei7/core2 build may sometimes be even slower than generic build, as x264 has already been fully assembly optimized with CPU runtime detection, so forcing a march can only affect those codes without CPU runtime detection, which are only very few parts in x264 and have nearly no noticeable effect on overall speed. And as I released my builds, I have to make sure it can run on most machines, so they were built only with -mtune=generic and -msse2, and some other parameters that should not affect encoding speed.

      BTW, what is the speed of vanilla build and my tMod on your machine? I did ~60 rough tests on my i7, and tMod-rev2197(which was exactly the one I released here, without any further native optimization) was faster than vanilla-rev2184 in every running test. For example, with --preset placebo, the average speed of five runs of vanilla was 1.38fps, while tMod was 1.46fps, and tMod-special_offer was 1.47fps; with --preset medium, vanilla was 30.62fps, tMod was 31.67fps, and tMod-special_offer was 31.74fps. On other settings the results were same, and tMod’s actual CPU time was also shorter than vanilla’s. I know it is unfair as rev2197 uses latest devel-git version and has more assembly optimization, such as “Faster chroma weight cost calculation”. I just mean that I cannot re-produce a tMod-slower-than-vanilla case on my machine.

  4. rehan
    23rd April 2012, Monday at 05,49am UTC

    hmm. interesting! remember rev2183 that uses pthread, i thought that was working faster for my AMD phenom ii x4 955 BE. well, i will also try the special offer of this version.
    btw, can u build rev2197 using pthread so that i can make another comparison to see which one is faster, if u have time that is🙂

  5. 22nd December 2015, Tuesday at 05,50am UTC

    if I render the subs within your x264 mod instead of within avs will I be able to prevent the subs from interfering with x264’s calculations? Since I’ve heard hardsubs totally screw up x264’s bitrate calculations.

  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: