LAVFilters tMod

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:
LAVFilter-tMod

---

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.