Home > Uncategorized > LAVFilters tMod

LAVFilters tMod

22nd October 2014, Wednesday Leave a comment Go to comments

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.

Categories: Uncategorized
  1. jpsdr
    18th November 2014, Tuesday at 10,28am UTC

    Congrats on your wedding. Any rough ETA for x264_tmod ?

  2. jpsdr
    21st December 2014, Sunday at 11,35pm UTC

    Hi.
    I’m struggling like hell to be able to build ffmpeg/l-smash and ffmpegsource and to have them properly detected/used when configuring x264.
    I’ve the felling i’m almost close to reach my goal, but i’m not able to get the last part, google search helped, but only at 95%…
    Can you provide me the configuration command line you’re using to build ffmpeg/l-smash and ffmpegsource for compiling the full x264 t_mod version ? Thanks.

  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: