Home > encode, x264, x264-bin > x264 rev2200+666 tMod

x264 rev2200+666 tMod

26th May 2012, Saturday 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_rev2200+666_tMod-Libav.7z : NMMGitHubMediaFire
x264_rev2200+666_tMod-FFmpeg.7z : NMMGitHubMediaFire
x264_rev2200+666_tMod-Lite.7z : NMMGitHubMediaFire
x264_rev2200+668_tMod-opencl.7z (Lite version with opencl lookahead, only 8-bit, experimental, for test only. Built with AMD APP v2.6, should also works on NVidia GPUs with OpenCL support) : NMMMediaFire

— Differences between FFmpeg/Libav version —:
Built with FFmpeg or Libav (also ffms was built with FFmpeg/Libav accordingly).
1. FFmpeg version uses libutvideo to decode utvideo, while Libav version uses libavcodec’s internal utvideo decoder. libavcodec has not implemented SIMD optimizations and is slower than libutvideo decoder. In some rare cases libavcodec fail to decode correct frame (not sure, I would like to report this to Libav/FFmpeg projects if I confirmed it is libavcodec’s issue), and libutvideo doesn’t have such problem.
2. FFmpeg version can decode celt audio via libcelt. celt codec doesn’t ensure capability with old version, and the libcelt in FFmpeg version is latest v0.11.3-19-git-r1588(e18de77) (standalone encoder/decoder binaries included). However, libcelt has stopped its development and moved to opus, and this final version of git should never be changed any more.
3. FFmpeg version supports more input-csp for raw input: rgba64be, rgba64le, bgra64be, bgra64le, 0rgb, rgb0, 0bgr, bgr0, yuva444p.
4. FFmpeg version accepts hacked high bit depth yuv4mpeg ( 420p9, 420p10, 420p16, 422p9, 422p10, 422p16, 444p9, 444p10, 444p16, which are not documented, and shouldn’t be used normally ) with --demuxer lavf.
5. Some other differences can be found on Libav’s homepage.

Lite version (formerly Special_offer) has only tMod+MixAQ-8bit and tMod-10bit with 4:2:0 chroma subsampling, no interlaced/audio/lavf/swscale/ffms/avi-output support, smaller in size and might be faster in speed.

— Latest updates —:
– Updated to x264 to latest git-r2200.
– Added “Use f3kdb for bit depth conversion when needed” patch. SAP’s avisynth 16bit-hack patch always treats high bit depth avisynth input as 16-bit, even if you have specified --input-depth=9~15, except for when input-depth equals to x264 binary’s output-depth, in which case bit depth conversion is simply skipped and this issue is avoided. E.g., 10-bit x264 only read 8/10/16 bit avisynth correctly, and if it read 9/11~15 bit avisynth script, it treated them as 16 bit without even a warning, and the result would be incorrect. Now with the new patch, x264 will call f3kdb to convert bit depth internally when input-depth does not equal to 8/16/output-depth, and the result should be correct. f3kdb’s dithering algorithm is hard-coded to 3 ( Floyd-Steinberg dithering ). Make sure flash3kyuu_deband.dll is in avisynth’s auto plugin loading directory.
– Updated “Fix AviSynth color space converting matrix” patch, in which incorrect high bit depth conversion is deleted. Also added “Fix swscale color space converting matrix”, but don’t rely on it. swscale is hell.
– Added “Support ‘dgi’ file extension” patch. Vanilla x264 automatically calls “mpeg2source” with avs demuxer when extension of input file is d2v, and calls “AVCSource” with avs demuxer when extension of input file is dga. And I think DGDecodeNV/DGAVCDecodeDI has also been widely used and should be added. Now x264-tMod will call “DGSource” when input extension is dgi.

— 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: patches-rev2200.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: Use f3kdb for bit depth conversion when needed (New!!)
22: Video filter: subtitles
23: Detect color matrix with lavf/ffms demuxer
24: Fix AviSynth color space converting matrix (Updated!!)
25: Fix swscale color space converting matrix (New!!)
26: Support “dgi” file extension (New!!)
27: High-precision fps, encoded file size & estimated total size
28: More detailed “zones” help
29: Add “libaacplus”
30: Unofficial –device
31-1: MixAQ-core;(only in tMod+MixAQ version, remove AQDebug)
31-2: OreAQ-core.(only in tMod+OreAQ version, remove AQDebug)

Compiler
mingw-gcc 4.7.0

Libpack info
ffmpeg-n0.8-10097-git-r41033(c0b47d1)
libav-v0.8-1849-git-r33655(177bcc9)
ffms svn-r683
VSFilter-2.41 (MPC-HC v1.6.2 svn-r4886)
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-5 git-r54(7d4ee39)
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. Mark
    29th May 2012, Tuesday at 12,09am GMT+0000

    Is there any quality difference between by using lite or normal version only difference in speed. I use MeGUI for encoding…can i use lite version.(my source is BD)

  2. 29th May 2012, Tuesday at 12,30am GMT+0000

    No quality difference. Only different in speed and functionality. If you don’t care lavf/ffms demuxer or avi muxer, don’t resize in x264, don’t use interlaced encoding, don’t mux or encode audio inside x264, and only encode avisynth input and 4:2:0 progressive output, then lite version is enough for you.

  1. No trackbacks yet.

Leave a comment