Home > encode, x264, x264-bin > x264 rev2183+656 tMod ( Use pthread to avoid the crash )

x264 rev2183+656 tMod ( Use pthread to avoid the crash )

11th March 2012, Sunday Leave a comment Go to comments

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

Use pthread and fprofiled:

tMod/tMod-10bit/tMod+MixAQ/tMod+OreAQ:
Download:
x264_rev2183+656_tMod-pthread.7z: MediaFireGitHubnmm-hd
x264_rev2183+656_tMod-pthread-Special_offer.7z: MediaFireGitHubnmm-hd

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 x264 to rev2183: newsletter.
– Disabled useless libs in libav, reduced binary size.
– Updated libav/ffms/libvo-amrwbenc.
– Uses pthread instead of win32thread. rev2183 results in crash of win32thread build.
– Re-activated avi output support as komisar fixed the new libav’s API usage.

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

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

Compiler:
mingw-gcc 4.7.0

Libpack info:
libav-v0.8-1004-git-r32810(442c3a8)
ffms svn-r658
VSFilter svn-r3698 (MPC-HC)
lame 3.99-5
libvorbis-aotuv_b6.03 (libvorbis-1.3.2)
opencore-amr 0.1.3 git-r189(958395d)
vo-aacenc v0.1.2-6 git-r85(c6bad70)
vo-amrwbenc v0.1.2-3 git-r52(6ffcea9)
faac 1.28
qtsdk 7.3

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

Categories: encode, x264, x264-bin
  1. 11th March 2012, Sunday at 02,38pm GMT+0000

    Just want to ask, what is different using pthread (I think it default, eh?) and win32thread? Is using win32thread achieve superior performance than pthread?

    • 11th March 2012, Sunday at 02,56pm GMT+0000

      pthread is a multi-platform thread management, while win32thread is Windows’ native one. Speed of these two varies in different project. According to kemuri-9’s simple test, win32thread is a little bit faster than pthread in x264, so I usually use win32thread.

  2. rudie
    12th March 2012, Monday at 01,17am GMT+0000

    The test looks promising, Is ‘vanilla’ build on x264.nl also used win32thread too?

    • 12th March 2012, Monday at 01,26am GMT+0000

      At least vanilla rev2183 built by jeeb uses pthread, otherwise it should have crashed without a modified threading workaround.

  1. No trackbacks yet.

Leave a comment