LAVFilters tMod

22nd October 2014, Wednesday Leave a comment

Actually I’ve been building LAVFilters before it has a video decoder, but I haven’t put it here because they were built for my own use with minor changes that I thought no one cares. But since my builds are public in nmm-hd, and they were mentioned in the official thread of doom9 recently, I think I should give some INFOs to avoid misusing them.

If you still want to use LAVFilter tMod after reading the following introduction, the DOWNLOAD link is here:

LAVFilters tMod builds were NOT built from official sources. They were patched for my own needs. The differences are:

0. No official coding signature, of cause.

1. Support reading Matroska Tags as media tags. But I didn’t do a mkv-tag to normal metadata mapping, but simply convert mkv-tags into lower case, which in most cases equal to metadata. You can get most tags correctly, like ‘TITLE’, ‘ARTIST’. It is good enough for me, so currently I don’t have any plan on doing a full mapping or something like matroska_convert_tag in FFmpeg.

2. Support trying DXVA2(native), then other HW decoder if DXVA2(native) fails, and then SW decoder if fails again. If you need either DXVA2(native) or other HW decoder, leave them as-is, and tMod would perform identical to the vanilla build. I need this mainly because I was using DXVA2(native) when I do not use DirectVobSub, but I wanted CUVID/QuickSync/DXVA2(copy-back) if the video comes with subtitles. But if you had already been using XySubFilter for a while, you definitely don’t need this feature.

Because of this change, tMod used to be not safe to replace MPC-HC’s internal LAVFilters (when opening the LAV Video setting page from Options, it’ll crash). But now I use some other method, and you can replace MPC-HC’s LAVF with tMod safely. All settings will be converted to tMod’s with no mass in your registry.

3. You can find git revision number anywhere the version number exists. This might be useful for bug reporting.

4. The priority of output colorspace is somewhile different from vanilla builds. (x:y:z below refers to YUV)
For 8-bit 4:2:0 input, tMod prefers
4:2:0-8bit > 4:2:0-10bit > 4:2:0-16bit > RGB-16bit > 4:4:4-16bit > 4:4:4-10bit > RGB-8bit > 4:4:4-8bit > 4:2:2-16bit > 4:2:2-10bit > 4:2:2-8bit, instead of official
4:2:0-8bit > 4:2:0-10bit > 4:2:0-16bit > 4:2:2-16bit > 4:2:2-10bit > 4:2:2-8bit > RGB-8bit > RGB-16bit > 4:4:4-16bit > 4:4:4-10bit > 4:4:4-8bit
For 10-bit 4:2:0 input, tMod prefers
4:2:0-10bit > 4:2:0-16bit > RGB-16bit > 4:4:4-16bit > 4:4:4-10bit > RGB-8bit > 4:4:4-8bit > 4:2:0-8bit > 4:2:2-16bit > 4:2:2-10bit > 4:2:2-8bit, instead of official
4:2:0-10bit > 4:2:0-16bit > 4:2:0-8bit > 4:2:2-16bit > 4:2:2-10bit > 4:2:2-8bit > RGB-8bit > RGB-16bit > 4:4:4-16bit > 4:4:4-10bit > 4:4:4-8bit
The rules are changed for all 4:2:0, 4:2:2 and 4:4:4 input colorspaces. The key principal is to use as few chroma-subsampling and YUV<->RGB conversion as possible (this takes YUV->RGB conversion into account), and always prefers highest bit-depth when conversion is needed.

Anyway, if you use madVR, this change is never useful. But if you are using EVR or some renderers that do not support high bit-depth input, this change gives you a way to prefer NV12/YV12 for 4:2:0 8-bit input, while use RGB32 for 4:2:0 10-bit input, which avoids yuv420p10->yuv420p8->RGB chains, but only do yuv420p10->RGB conversion once. The best quality is always preserved. But if you’re using an old machine that cannot handle RGB32 before the renderer, you may want to untick RGB32 box in output colorspace, which actually you should also do in vanilla builds.

5. Some colorspace conversion inside LAV Video does not have custom optimization and uses libswscale routine. I changed the prefered kernel from Bilinear to Bicubic, which has a better quality.

6. The priority of ALAC was raised in the selection of audio stream based on quality for it’s a lossless codec.

7. YV16 output colorspace is added. Actually it has been in LAV Video for a long time, but was hidden for future use. However madVR can deal with it with no pain….

8. Changes from MPC-HC, like exhibiting Matroska attachments through DSM resource bag API, so you can view them in MPC-HC/MPC-BE.

9. For some reason one Matroska file may contain only one hidden edition, but the chapter is not hidden. Vanilla builds shows the non-hidden chapter, but tMod hidden them. I do this because when the only hidden edition is used, everything in the edition section should be hidden, except for the video/audio/subtitles streams. I usually use a hidden edition with chapters to regenerate the long looping Menu Video of Blu-ray Discs. The chapter is invisible but accessible, but one do not need to read the edition info. And this is what I understand from Matroska specs.

10. Some other minor changes that does not affect end users.

Categories: Uncategorized

avs4x26x 0.10.0 ( x265, AviSynth+, x64, DGSourceIM, etc. )

28th August 2014, Thursday 10 comments

After the silence of nearly one year.

Download links ( source codes are here): avs4x26x


Changelog since 0.9.1:

1. Fix automatically invoking Source Filter for media input files with AviSynth+, using the same patch from BugMaster for x264.

2. Support x265, x264 and x262. That is why we change the name from avs4x264 to avs4x26x. Actually avs4x264mod already supports x265 by simply using --x264-binary, but now if your output file is *.265/*.h265/*.hevc, avs4x26x will launch “x265.exe” even without --x26x-binary or -L. Still, “x264_64″ for other output for backward compatibility.

Note that x265 introduce another method: x265 input output. This would not be supported for the x264/x265 recognition. Either avs4x26x input.avs --output output.265 or avs4x26x input.avs -Lx265 output.265 or avs4x26x input.avs --x26x-binary x265 is OK. But if you write avs4x26x input.avs output.h265, x264_64 is implied.

3. Support automatically invoke DGSourceIM, if DGSource failed for “*.dgi” input

4. Since x265 does not support avs input yet, x64 version is reasonable for those who want to use x64 AviSynth with x64 x26x. Now here comes the x64 version, to be used with x64 avisynth.dll.


Recently I’m preparing for my wedding ceremony, x264-tMod might be delayed for several weeks.

Categories: avs4x26x, encode, x264

x264 rev2431 tMod

24th April 2014, Thursday 25 comments

Sources on GitHub:,
and on BitBucket:

Ad: new binary host is


Only regular updates as always. Find more details on official x264-devel mail-list.
Nothing changed in tMod

Categories: encode, x264, x264-bin

x264 rev2409 tMod

17th March 2014, Monday 26 comments

Sources on GitHub:,
and on BitBucket:

Ad: new binary host is


Only regular updates as always. Find more details on official x264-devel mail-list.
Nothing changed in tMod, except for some minor patch updates for x264 plain branch.

Edited on UTC 11:30 17 Mar 2014:
fixed a bug (patch/audio-support) that Matroska video length was not written after encoding, causing total length not available in MediaInfo or other players and editors. Thanks to reekilynn for reporting.

Edited on UTC 06:00 18 Mar 2014:
Automatically invoke AutoLoadPlugins() if available when using avs demuxer to open non-avs scripts. For AviSynth+. Patch from BugMaster.

Categories: encode, x264, x264-bin

x264 rev2389 tMod

12th February 2014, Wednesday 4 comments

Sources on GitHub:,
and on BitBucket:

Ad: new binary host is

Download: x264_rev2389_tMod.7z

1. x264-audio is too broken to be used, so set default acodec to “none” to avoid errors. Currently only “none” and “copy/raw” (in full version) are available.
2. <patches/ntsc-fps correction> Added an option --no-fps-correction to disable automatic fps correction. For those who need to use non-standard fps like 2997/125 and don’t want it to be corrected to 24000/1001.

Categories: encode, x264, x264-bin

x264 rev2377 tMod

7th November 2013, Thursday 7 comments

Sources on GitHub:,
and on BitBucket:

Ad: new binary host is

Download: x264_rev2377_tMod.7z

1. Removed all audio codecs, except for --acodec copy/raw. x264 officially uses l-smash mp4 muxer, but I still keep x264-audio stuffs, though many does not function correctly as in previous versions (after libav/ffmpeg’s API updates). You may still build your own x264-tMod with qtaac/faac/lame/lavc support.
2. <patches/decoder> Added an option to select decoder of lavf. Only works for --demuxer lavf. For example, --demuxer lavf --decoder libvpx-vp9 uses libvpx to decode vp9, while by default lavf uses native vp9 decoder (implies --decoder vp9). Currently only vp9 (vp9/libvpx-vp9) and utvideo (utvideo/libutvideo) are tweakable. If QSV or some other decoders were added in lavf, one might select them to boost decoding mpeg-2, vc-1, h.264, etc.
3. Many other patches updated for x264, as now I use official branch as code base instead of x264_l-smash.

Categories: encode, x264, x264-bin

avs4x264mod 0.9.1

31st August 2013, Saturday 1 comment

Download links ( source codes are here): avs4x264mod-0.9.1-git-r64(105c53a).7z

1. Prefers to use VapourSource for vpy input, as it is a native VapourSynth source filter. Put VapourSource.dll in AviSynth’s auto-load folder, or else x264 would try AVISource/HBVFWSource as before. Keep in mind that unlike HBVFWSource which will automatically imply –input-depth 16, with VSImport x264 wouldn’t know if the vpy output clip is 8-bit or not, so it is needed to manually set --input-depth depth if depth is not 8.
2. Prefers to use LSMASHVideoSource/LWLibavVideoSource as source filter than FFMS2 for many input formats, e.g., mp4/mov/mkv/m2ts/…. Still able to fall back to FFMS2 if LSMASH/LWL fails.

Categories: avs4x26x, encode, x264

Get every new post delivered to your Inbox.

Join 281 other followers