L-SMASH Source

[foxyshadis]

Looks like WebM/VP9 decoding is completely broken in the latest builds. Oh well, I have a copy from 2013 that seems to work right, I can use that just for webm.

[Are_]

Not a single problem here at my linux box with my own compiles. Linked against ffmpeg and using vapoursynth filter.

[Reel.Deel]

Looks like WebM/VP9 decoding is completely broken in the latest builds. Oh well, I have a copy from 2013 that seems to work right, I can use that just for webm.

Do you know which version from 2013?

[VFR maniac]

Looks like WebM/VP9 decoding is completely broken in the latest builds. Oh well, I have a copy from 2013 that seems to work right, I can use that just for webm.

I had already gotten a report and a sample of VP9-in-WebM from someone through ask.fm and 2ch.
And he says that binaries linked with ffmpeg have the problem but with libav have no.
I'll look into this later.

[fvisagie]

You can get my L-SMASH-Works builds here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0). Require Visual C++ Redist 2013 (32-bit (http://go.microsoft.com/?linkid=9832156), 64-bit (http://go.microsoft.com/?linkid=9832146))

Also my L-SMASH builds can be found here (https://www.dropbox.com/sh/7jjrz5i4wcxhf49/AADZlN98OhKAvLHVwfaXYK4da?dl=0).

Many thanks for helping keep this alive :).

What is the difference between the builds in the top-level folder linked (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0) and those in the with-Libav (https://www.dropbox.com/sh/3i81ttxf028m1eh/AABKDekYfeh-6Lv6Pkz_eLcEa/with-Libav?dl=0) subfolder? They both seem to support the LWLibav...Source() functions, so I'm a little confused by the distinction between these different builds.

[the_weirdo]

What is the difference between the builds in the top-level folder linked (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0) and those in the with-Libav (https://www.dropbox.com/sh/3i81ttxf028m1eh/AABKDekYfeh-6Lv6Pkz_eLcEa/with-Libav?dl=0) subfolder? They both seem to support the LWLibav...Source() functions, so I'm a little confused by the distinction between these different builds.

Those builds in top folder are linked with FFmpeg libraries, while those builds in "with-Libav" are linked with... Libav libraries. You can read the differences between FFmpeg and Libav here (https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav). However, in general, they should work the same. Some cases, FFmpeg builds may be better than Libav builds, or vice versa.

[fvisagie]

Thanks, that explains a lot.

I'd like to stick with what worked for me from the now-dead download link (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing) before. Comparing the LSMASHSource.dll size of L-SMASH-Works_r725-g92d69d8.7z I got from there and also looking at the build_info.txt shipped with that version
L-SMASH-Works r725 ( lwinput.aui, lwmuxer.auf, lwdumper.auf, lwcolor.auc, LSMASHSource.dll, vslsmashsource.dll )

Source:
L-SMASH-Works: git-92d69d8 ( https://github.com/VFR-maniac/L-SMASH-Works )
L-SMASH: git-4433160 ( https://github.com/l-smash/l-smash )
FFmpeg: git-87f2d80 ( http://git.videolan.org/?p=ffmpeg.git )

seem to suggest it was built with FFmpeg, correct?

[foxyshadis]

Do you know which version from 2013?

r688v2 from this thread (https://www.dropbox.com/s/pok2p8kygc06t5d/L-SMASH-Works_r688v2.7z). It's dated August 30, 2013, but it was just the first that came up when I searched for old versions.

[the_weirdo]

seem to suggest it was built with FFmpeg, correct?

AFAIK, yes.

[fvisagie]

AFAIK, yes.

Thank you.

[fvisagie]

How much might a media file filter (and Avisynth) benefit from hardware accelerated decoding? On the face of it, more CPU power should become available for actual script processing?

It seems FFmpeg has been supporting hardware acceleration since around March 2014, although the documentation (http://ffmpeg.org/ffmpeg-all.html#Advanced-Video-options) is very modest about performance. Would it be feasible supporting that in L-SMASH Source, and would it be worthwhile?

[LigH]

There is already e.g. DGDecNV using Nvidia PureVideo decoder chips V2+, but it has already been reported that V2 and V3 chips are so slow, they just even decode in realtime. Pure software decoding, multithreaded on a multi-core CPU, can be several times faster. So if there is only little filtering, AviSynth has to wait a lot until the decoder chip sends the video data, and if there is a lot of elaborate filtering, the decoding time is marginal in relation to the filtering. With the current fast CPUs and the good multithreaded decoding routines, hardware decoding with these decoder chips is not really worth being called acceleration; but it can be a quite robust and feature-complete alternative decoder (e.g. the libav decoder lacked support for interlaced VC-1 for a long time).

Decoding by PureVideo V5 chips is quite a bit faster, and with QuickSync (DGDecIM) probably even more. They could well be good hardware to assign decoding to. Yet they may not be noticably faster, because there is also some overhead of moving data between system RAM and video RAM. And the more elaborate the filtering, the less impact the decoding will have on the whole filtering time.

[Music Fan]

Another solution to use hardware decoder with avisynth is LAV filter when set on DXVA2 Copy-Back (which doesn't work with XP, you need Vista, Win 7 or more).
Use directshowsource() in avisynth. I read that DSS2() could also work with Haali Splitter.
You may need Win7DSFilterTweaker to choose LAV's directshowsource filter instead of Windows.

One can see if the script is faster with AVSMeter.

[[ReX]]

I originally intended to write a compilation guide for L-SMASH and L-SMASH Works, but it got too long for a forum post.
After lots of pain and agony (:p), I managed to compile everything using GCC and VS2013, you can read the guide here (https://github.com/BrunoReX/build-scripts/blob/master/L-SMASH/readme.md).

[LigH]

Thank you for your efforts. A pity it seems to require Visual Studio, so it won't be possible to integrate it into the media-autobuild_suite easily (which relies on GCC only). Or is that relevant for the *Synth DLLs only?

[[ReX]]

Thank you for your efforts. A pity it seems to require Visual Studio, so it won't be possible to integrate it into the media-autobuild_suite easily (which relies on GCC only). Or is that relevant for the *Synth DLLs only?

Yes, only the AviSynth plugin requires Visual Studio.

[fvisagie]

I'm having trouble getting the plugin to load on 64-bit Windows 8.1.

On a 32-bit Windows 7 Pro SP 1 system it loads fine. On the Windows 8.1 system LoadPlugin() fails with "...error=0xc1".

It makes no difference having the supplied msvcr120.dll in the plugins subfolder or in System32. The supplied DLL has exactly the same File and Product version as the existing one in System32 as well as the same datestamp, but the timestamps differs by 2h40m and the file sizes by 8KB.

EDIT: I should perhaps mention that I tried both the 32-bit as well as the 64-bit DLLs, being uncertain whether the 64-bit version is indicated for 64-bit Avisynth (the version installed is 32-bit), or for 64-bit Windows. The results above pertain to the 64-bit DLL. With the 32-bit DLL the error code is 0x7e, also regardless of whether the supplied 32-bit msvcr120.dll is put in the plugins subfolder or in System32.

What is the cause of this problem and how do I fix it?

Thanks!

[LigH]

Again, and again, and again ...

Applications should never provide a copy of msvc*.dll files, because a) just putting them somewhere may not be enough, and b) they belong to different places, depending on having either a 32-bit or a 64-bit Windows:

Windows 7/8 32-bit: 32-bit DLLs belong to \Windows\System32
Windows 7/8 64-bit: 32-bit DLLs belong to \Windows\SysWOW64 (by overwriting the existing file in \Windows\System32 on a 64-bit Windows, you exchanged the 64-bit DLL with a 32-bit DLL, so 64-bit MSVC 2013 applications will now probably crash from now on)
To avoid any trouble here: Always download the 32-bit Microsoft Visual C++ 2013 Runtime (Redistributable) and run the installer to support 32-bit applications and DLLs built with MSVC 2013 on both 32-bit and 64-bit versions of Windows reliably; it will put at least MSVCR120.DLL and MSVCP120.DLL into the correct directory, depending on your Windows version. For a 64-bit Windows, there are both 32-bit and 64-bit MSVC Runtime installers, with their own set of DLLs.

[foxyshadis]

There are also multiple versions of some msvc* files, since each service pack can get its own despite the identical file name. If the manifests don't match, it won't load. Installing the correct redist will get you everything.

This is supposed to change with MSVC 14 (2015), all future versions will be compatible with any msvcr140 (etc) dlls unless there's a breaking change.

[StainlessS]

With Toolkit 2003 and VS dot net 2003, MS suggest/advise applications each having their own copy of redistributables in their own
directories and not putting them in system32 due to version differences, you can usually find quite a few versions of redistributables
with similar names spread throughout your "Program Files" directory.
You sometimes come across a program or eg Avisynth filter that fails because of missing runtimes, I usually (against MS advise) copy
a collection of these files

mfc70.dll 1,024,000 bytes
mfc71.dll 1,060,864 bytes
msvcp70.dll 487,424 bytes
msvcp71.dll 499,712 bytes
msvcr70.dll 344,064 bytes
msvcr71.dll 348,160 bytes

EDIT: Added files sizes. The 70 variations are from VS dot net 2002.

into system32, I'm not aware of ever having any problems because of this, but I always use the same files (from an old version of nero, I think about v5.0).
EDIT: Think I probably chose the most recent versions that I had available.

[Groucho2004]

With Toolkit 2003 and VS dot net 2003, MS suggest/advise applications each having their own copy of redistributables in their own
directories and not putting them in system32 due to version differences
Do you have a link to that MS statement?

The whole point of using dynamic linking is to have one runtime used by all programs. Well, one runtime for each compiler version.

Instead of putting the runtimes in the program directory one should simply statically link with the appropriate libraries.

[StainlessS]

I dont know where I read that but that is the reason that many copies will be found in Program Files.
According to the first google link I looked at:
There never was a Microsoft Visual C++ 2003 redistributable package released. However, because of the DST changes the US
government made in 2007, Microsoft released a hotfix which includes the 2003 C/C++ runtime in March 2007.
You can download the runtime from the link provided in this thread.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/f6220619-3999-4489-ba5f-09d38dfaefcf/visual-c-2003-71-redistributable-package-x86
EDIT: Link fixed, original posted link would not properley connect for some reason. The download mentioned in above quote is no longer available.

so it looks like they never were considered redistibutable. (at least not in a standard one size fits all)


Just found, this looks similar to what I was talking about but is I think not the original link that I referred to (twas a long time ago).
http://support2.microsoft.com/kb/326922

From above link,
Summary:

When you build an application in Microsoft Visual Studio, and the application uses the C run-time libraries (CRT),
distribute the appropriate CRT DLL from the following list with your application:

Msvcr90.dll for Microsoft Visual C++ 2008
Msvcr80.dll for Microsoft Visual C++ 2005
Msvcr71.dll for Microsoft Visual C++ .NET 2003 with the Microsoft .NET Framework 1.1
Msvcr70.dll for Microsoft Visual C++ .NET 2002 with the Microsoft .NET Framework 1.0

For Msvcr70.dll or for Msvcr71.dll, you should install the CRT DLL into your application program files directory.
You should not install these files into the Windows system directories. For Msvcr80.dll and for Msvcr90.dll, you
should install the CRT as Windows side-by-side assemblies.


More Information:

The shared CRT DLL has been distributed by Microsoft in the past as a shared system component. This may cause
problems when you run applications that are linked to a different version of the CRT on computers that do not
have the correct versions of the CRT DLL installed. This is commonly referred to as the "DLL Conflict" problem.

To address this issue, the CRT DLL is no longer considered a system file, therefore, distribute the CRT DLL with
any application that relies on it. Because it is no longer a system component, install it in your applications
Program Files directory with other application-specific code. This prevents your application from using other
versions of the CRT library that may be installed on the system paths.

Visual C++ .NET 2003 or Visual C++ .NET 2002 installs the CRT DLL in the System32 directory on a development system.
This is installed as a convenience for the developer. Otherwise, all projects that are built with Visual C++ that
link with the shared CRT require a copy of the DLL in the build directory for debugging and execution. Visual C++ 2005
and Visual C++ 2008 install the CRT DLL as a Windows side-by-side assembly on Windows XP and later operating systems.
Windows 2000 does not support side-by-side assemblies. On Windows 2000, the CRT DLL is installed in the System32 directory.

When you distribute applications that require the Shared CRT library in the CRT DLL, we recommend that you use the CRT.msm
merge module that is included with Visual C++ instead of directly distributing the DLL file.


EDIT:
The whole point of using dynamic linking is
Yep, I know. Looks to me like MS made a hash of it and the above advise was their way of fixing the cock-up.

EDIT: As far as the MS 71 (2003) dll's in my system32 are concerned, they are the same as given sizes (in prev post), so looks like
I copied VS ToolKit 2003 dll's to my repository at some point (I usually do the copy to system32 on new system install along with
other standard configurations that I make [I used to also copy gdiplus.dll to system32 but do not remember why].
The copied dll's would not be used by programs that installed their own copies in Program Files application directory, only
by those that were supplied without the dll's, as noted by MS above).

[fvisagie]

Again, and again, and again ...

Thanks, this helped explain and fix the problem.

(by overwriting the existing file in \Windows\System32 on a 64-bit Windows, you exchanged the 64-bit DLL with a 32-bit DLL, so 64-bit MSVC 2013 applications will now probably crash from now on)

Fortunately I was sensible enough to save and restore original files as I went along :).

[StainlessS]

I've only just started playing with L-SMASH source filter and downloaded a couple of test clips to try out.
The first clip in the list here:- http://samples.mplayerhq.hu/asf-wmv/
ie "Alice Deejay - Back In My Life.asf" 13MB
EDIT: Above sample list posted by D9 moderator, so I assume its kosha (not a rule breaker, EDIT: Actual post was parent ie http://samples.mplayerhq.hu/).

MediaInfo:

General
Complete name : D:\CROPTEST\AliceDeejay-BackInMyLife.asf
Format : Windows Media
File size : 13.0 MiB
Duration : 3mn 28s
Overall bit rate : 523 Kbps
Maximum Overall bit rate : 524 Kbps
Movie name : Alice Deejay - Back In My Life
Performer : Presented by http://come.to/mp3mtvhits
Encoded date : UTC 2000-01-05 15:00:32.820

Video
ID : 2
Format : MPEG-4 Visual
Codec ID : MP43
Codec ID/Info : Microsoft MPEG-4 v3 (pre-standard)
Codec ID/Hint : Microsoft
Description of the codec : Microsoft MPEG-4 Video Codec V3
Duration : 3mn 28s
Bit rate : 430 Kbps
Width : 320 pixels
Height : 240 pixels
Display aspect ratio : 4:3
Frame rate : 25.000 fps
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.224
Stream size : 10.7 MiB (82%)

Audio
ID : 1
Format : WMA
Format version : Version 2
Codec ID : 161
Codec ID/Info : Windows Media Audio
Description of the codec : Windows Media Audio V2 - 64 kbps, 44 kHz, stereo
Duration : 3mn 28s
Bit rate : 64.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Stream size : 1.59 MiB (12%)


Opens OK via
FN="AliceDeejay-BackInMyLife.asf"
V=LWLibavVideoSource(FN)
A=LWLibavAudioSource(FN)
AudioDubEx(V,A)


But the audio is cut off after about 4.2 seconds. FFMpegSource plays OK.

[GMJCZP]

I'm starting to use L-Smash and I'm noticing, as with FFMpegSource, the frames of the original video does not match exported, for example, an original video MP4 on your frame 404 coincided with the frame 408 of L-Smash (for Incidentally, as with FFMpegSource), a difference of 4 frames(!). Never have that problem with AviSource, the frames match perfectly.

Why is this so and how can it be remedied?

Edit: with VirtualDub MP4 opening directly apparently decoded correctly. It seems absurd to convert the video to a file Avi lossless and then use AviSource. That's why I'm here.

[LigH]

There are different "splitters" in different source filters: AviSource uses the VfW system of Windows; FFMS2 and L-SMASH Works both use different versions of splitters from libav libraries (ffmpeg or libav variants). As already reported several times, FFMS2 only supports the MKV container reliably (but has some issues with different other containers, even when the Haali Media Splitter is installed, which is used as helper). L-SMASH Works even has two different splitters available: Either LAV Filters for LwLibavVideoSource(), or the L-SMASH splitter for LSMASHVideoSource() — the latter only for ISO Media containers like MP4 or MOV.

Different splitters may treat containers more or less correctly, and some may have issues with specific structures in containers, so they may possibly ignore a few frames in the beginning. But as long as they do that reliably, and ignore always the same frames in both first and second pass of a 2-pass encode, it should at least allow a reliable conversion. With some DirectShow filters, different frames may have skipped between first and second pass, therefore DirectShowSource() may be a risk for 2-pass encoding even.

[GMJCZP]

There are different "splitters" in different source filters: AviSource uses the VfW system of Windows; FFMS2 and L-SMASH Works both use different versions of splitters from libav libraries (ffmpeg or libav variants). As already reported several times, FFMS2 only supports the MKV container reliably (but has some issues with different other containers, even when the Haali Media Splitter is installed, which is used as helper). L-SMASH Works even has two different splitters available: Either LAV Filters for LwLibavVideoSource(), or the L-SMASH splitter for LSMASHVideoSource() — the latter only for ISO Media containers like MP4 or MOV.

Different splitters may treat containers more or less correctly, and some may have issues with specific structures in containers, so they may possibly ignore a few frames in the beginning. But as long as they do that reliably, and ignore always the same frames in both first and second pass of a 2-pass encode, it should at least allow a reliable conversion. With some DirectShow filters, different frames may have skipped between first and second pass, therefore DirectShowSource() may be a risk for 2-pass encoding even.

I noticed this problem a while and now when I'm trying to take action on the matter.

So far the historical sequence in my learning curve with MP4 videos goes like this:
DirectShowSource - FFSource - L-Smash Source.

I tried both flavors of L-Smash source and the result is the same.

[LigH]

Are you able to upload a short sample which provokes this difference, which we can use to compare? It may be necessary to report the exact version numbers of the plugins you are using.

[GMJCZP]

Are you able to upload a short sample which provokes this difference, which we can use to compare? It may be necessary to report the exact version numbers of the plugins you are using.

I use the r729 version. Certainly cost me a lot to get it, did not know there was a wiki page.

For now it's hard to upload a sample, sorry.

[LigH]

Accidently asked elsewhere already ... LAV Filters support VFR when an AVI contains drop frames; for LwLibavVideoSource instead, it would be more useful to repeat the last decoded frame with a constant frame rate, because AviSynth supports only CFR as well.

In the german doom9/Gleitz forum, a user complained that L-SMASH Works instead returns an average frame rate, not repeating the previous of a drop frame, thus creating sync issues. I don't have such samples, but I believe some webcams will use this technique, so I would like someone here to test it or provide a sample for testing. And I hope VFR maniac or anyone with some source code insight can check how the current behaviour is, especially regarding the indexer module for AVIs.

[Lenmaer]

Hi, can someone explain me what's the difference between L-SMASH-Works-r729-20141025 and L-SMASH-Works-r729-20141025-Libav from the_weirdo's dropbox link?

[LigH]

Explained one page ago (http://forum.doom9.org/showthread.php?p=1693941#post1693941).

[Lenmaer]

Oh, thanks a lot.
I missed that.

[GMJCZP]

Correct me if I'm wrong, but with L-Smash I can not adjust the input fps, but I can FFMS, actually once had to resort to the latter for the reason cited.

[Music Fan]

You can just add assumefps(x), the result should be the same.

[the_weirdo]

Correct me if I'm wrong, but with L-Smash I can not adjust the input fps, but I can FFMS, actually once had to resort to the latter for the reason cited.

Currently, L-SMASH Works filters don't support VFR to CFR convertion if that's what you mean.

[LigH]

But does it support drop frames as implemented in AVI (expand the display duration of the previous frame by not changing the output for another frame duration)? Or does it ignore drop frames and treat all remaining non-drop frames (no matter how many drop-frames separated each of them) with equal average duration?

[Lenmaer]

It also doesn't support 3:2 pulldown. One of the nourin BDMVs had one m2ts like that.

[LigH]

Well, IVTC (if it was hard telecine encoded) can be applied later, after decoding, bacause it is (hopefully) a regular field/frame pattern in a CFR video.

But respecting AVI drop frames would have to be supported during the indexing, because it will probably be irregular, and no filter after the decoder will know about the positions of drop frames in the AVI container.

[Lenmaer]

I was able to fix it by changing the framerate of that m2ts to 23.976 with tsmuxer, otherwise it was off.

[GMJCZP]

And what is DSS2?

Here. (https://code.google.com/p/xvid4psp/downloads/detail?name=DSS2%20mod%20%2B%20LAVFilters.7z&can=2&q=) Another link? I got it! Here. (http://forum.doom9.org/showthread.php?p=1699301#post1699301)

To LigH: here (http://forum.gleitz.info/archive/index.php/t-38053.html)

And here (http://docs.aegisub.org/manual/Video) additional information.

In the last link says: "Do note that DSS2 converts variable framerate files to constant"
What do you think? This is what I want but...

[LigH]

DSS2 is a part of the Haali Media Splitter. DSS2Mod added support for LAV Filters as alternative decoders.

"Do note that DSS2 converts variable framerate files to constant" ... But how does it do that? By assuming an equal distance between frames which should have a varying distance instead? Then you will get sync errors.

The usual DirectShowSource(convertfps=true) does this by "resampling" the video, so you may get doubled or missing frames. But at least it will be in sync.

[TheFluff]

DSS2 does the same thing as DSS with convertfps=true. The other alternative would pretty useless.

[GMJCZP]

Here is a testimonial about DSS2:

Here (http://forum.doom9.org/showthread.php?p=1699121#post1699121)

I think the more options about source filters the better.

[cagali]

Hi, I am new to Lsmash.
Just 1 quick question.
Is these 2 avs going to output the same thing for x264-10bit to encode?

I tried and what I get are 2 files with <1% difference in peak bitrate.
I am using megui. The source clip is a YV12/yuv420p8 short segment from a BD m2ts.
Thank you.

avs file 1:
LoadPlugin("LSMASHSource.dll")
LWLibavVideoSource("clip.mkv")

avs file2:
LoadPlugin("ffms2.dll")
FFVideoSource("clip.mkv", threads=1)

And the versions are:
L-SMASH-Works-r729-20141025-32bit
ffms2-2.20-msvc

[LigH]

The source clip is a YV12/yuv420p8 short segment from a BD m2ts.

Uhm, no. There is no raw YV12 on a BD. There may be e.g. MPEG-2, AVC or VC-1 video streams contained in the M2TS. MediaInfo should be able to report important details.

Still, regarding your question: There may be slight differences between decoders in ffmpeg or libav libraries used by either source plugin. Therefore, there may not be a guarantee for bit-identical decoding results; but the differences should be marginal.

[cagali]

Uhm, no. There is no raw YV12 on a BD. There may be e.g. MPEG-2, AVC or VC-1 video streams contained in the M2TS. MediaInfo should be able to report important details.

Still, regarding your question: There may be slight differences between decoders in ffmpeg or libav libraries used by either source plugin. Therefore, there may not be a guarantee for bit-identical decoding results; but the differences should be marginal.

Right. The clip is a AVC clip with colorspace with this info:
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits

[foxyshadis]

Hm, if it was MPEG-2 it would be perfectly understandable, but as it's AVC it should be bit-identical or it's out of spec. I wonder which one is the buggy one? Of course, peak bitrate doesn't tell us anything, actually comparing the two against each other (with mt_makediff) is the only way to tell for sure.

It could also be that x264 didn't encode them identically; while x264 is supposed to be deterministic, in rare cases of lots of threads it can change slightly.

[LigH]

@ the_weirdo:


L-SMASH-Works-r733-20141121-32bit.7z
with-Libav\L-SMASH-Works-r729-20141117-32bit-Libav.7z

Is the revision gap correct?

And do you know if either one has issues with Dolby TrueHD+Atmos audio tracks? I don't have such material, but a user in the german forum may have...

[the_weirdo]

@LigH
Because the VP9 decoding issue when linked with FFmpeg libs has been fixed, I just feel that there's no good reason to use Libav builds over FFmpeg builds anymore, so I don't update them. Only FFmpeg has supported TrueHD streams with Atmos substream, however, I'm not sure if L-SMASH Works builds linked with FFmpeg libs can decode TrueHD+Atmos or not.

EDIT: I can confirm that builds linked with FFmpeg libs have issues with media files that contain TrueHD+Atmos tracks.
EDIT2: Please disregard previous statement. I was wrong about that. It's because my builds being broken. Builds linked with FFmpeg libs can work with those files just fine.