L-SMASH Source

[FranceBB]

Can I safely ignore this for the 32-bit version, or am I playing with fire?

I remember the version you are talking about, as it was the one I was using. One of the things I'm thinking about is that with the old version, whenever a bit-depth higher than 8bit was detected, it used to output 16bit stacked or interleaved by default, while FFMpegSource2 had an option to allow the "10bit hack", otherwise everything was going to be outputted in 8bit by default. Later on, when Avisynth+ came out, ffms2 was updated to support higher regular planar bit depth available on Avisynth+ and the 10bit hack was removed, therefore the poor Avisynth users were left with 8bit only capabilities.
Now, I have no idea whether LWLibavVideoSource has been updated the same way ffms2 has been updated back in the days, but if it was, I'm afraid Avisynth 2.6.1 won't have high bit depth available (I haven't tested the new version, though).

Anyway, I know that you don't really encode high bit depth stuff and you don't make use of particular color curves and so on, so, if this is the only difference between the old and the new version, it might work for what you have to do as well.

[qyot27]

while FFMpegSource2 had an option to allow the "10bit hack", otherwise everything was going to be outputted in 8bit by default. Later on, when Avisynth+ came out, ffms2 was updated to support higher regular planar bit depth available on Avisynth+ and the 10bit hack was removed
The 10bit hack was a patch that was only ever present in SAPikachu's builds. It was never present in upstream FFMS2's codebase, and was therefore not 'removed' when support for all* of AviSynth+'s pix_fmts was added.

*for a given value of 'all'. Not even FFmpeg supports all the pix_fmts AviSynth+ does, and FFMS2 is obviously limited to just what FFmpeg supports.

[StainlessS]

What confused me is that the readme says that this is a plugin for AVS+ and VapourSynth, no mention of classic AVS. Can I safely ignore this for the 32-bit version, or am I playing with fire?

Unless it says something like "Specifically AVS+ only", then is OK on AVS Standard.
Avs+ (and usually AVS+ plugins) are backward compatible to avs 2.60/61. [there is little reason not to be compatible]

EDIT: I just happened to stumble across this, not long after posting above.

RawSourcePlus
Loading raw video data from files

for Avisynth+ r2150 or greater
This filter is only for Avisynth+MT. Avisynth2.6 is not supported.
requirements

Windows Vista sp2 or later
Avisynth+ r2150 or greater
Visual C++ Redistributable Packages for Visual Studio 2015

Dont think I've ever seen any AVS+ specific filters before.

[Groucho2004]

This post says otherwise:
https://forum.doom9.org/showthread.php?p=1768843#post1768843

[StainlessS]

Sorry, that was from Version 2016-08-14,
Chikuzen post from 28th May 2016, so is earlier than my quote.

From rawsourceplus-20160814.zip RawSourcePlus.html
This filter is automatically registerd as MT_SERIALIZED.
You don't have to set it yourself.
original author:Ernst Peché, 2005-10-13
modified by Oka Motofumi, 2011-06-14

Version 2016-07-07 - Modified RawSource26 to Avisynth+ plugin. Version 2016-08-14 - Update for Avisynth+ r2150 or later.

EDIT:Here:- https://github.com/chikuzen/RawSource_2.6x/releases
Chikuzen link to Binary has it on GitHub.

[Groucho2004]

Sorry, that was from Version 2016-08-14,
Chikuzen post from 28th May 2016, so is earlier than my quote.

From rawsourceplus-20160814.zip RawSourcePlus.htmlI don't see anything in the code (on github) that would suddenly stop it from working with AVS2.6. That could be tested easily, I guess.

[StainlessS]

Yup, I aint tested it, aint even tried it.
Me gots several hundreds of dlls to be tried, one day.
[probably got a dozen or so of yours, which actually just need dumping as using later ones]

[Groucho2004]

Me gots several hundreds of dlls to be tried, one day.Bloody hell :scared:

[StainlessS]

Bloody hell :scared:

A slight underestimation actually (some of below are probably non avs dll's, maybe avs tools or zips which I'm not sure of the contents, but most are avs dll zips[some may be extracted]).

https://i.postimg.cc/prftLTVF/Not-Yet-Added.jpg (https://postimages.org/)

EDIT: Some of the folders are collections, eg mg262 colection, or D.Horman [alas, no longer with us] etc.
EDIT: More than once, someone has made a request for source or dll, and nobody else seemed to have it.
(actually got about 3 or four more Firefox download folders which contain loads of stuff, and as yet uncatagorised, will be loads more dll's/zips in those too).

[Atak_Snajpera]

A slight underestimation actually (some of below are probably non avs dll's, maybe avs tools or zips which I'm not sure of the contents, but most are avs dll zips[some may be extracted]).

https://i.postimg.cc/prftLTVF/Not-Yet-Added.jpg (https://postimages.org/)

EDIT: Some of the folders are collections, eg mg262 colection, or D.Horman [alas, no longer with us] etc.
EDIT: More than once, someone has made a request for source or dll, and nobody else seemed to have it.
(actually got about 3 or four more Firefox download folders which contain loads of stuff, and as yet uncatagorised, will be loads more dll's/zips in those too).

That wallpaper screams Ａ ｅ　ｓ　ｔ　ｈ　ｅ　ｔ　ｉ　ｃ　ｓ ;)

[StainlessS]

Arh, a fellow sybarite, then here just for you, my beloved W95 Red Tile[Admin] + about 4/5 more colors (~=2KB)

http://www.mediafire.com/file/sx5rgzun3y4gb4n/TILES.7z/file

[StainlessS]

I don't see anything in the code (on github) that would suddenly stop it from working with AVS2.6. That could be tested easily, I guess.

OK, Tried RawSoucePlus() on avs v2.60 standard, crashes.


00000100 16:28:48.211 GetSeq: Multi-SourceFilter Attempt open of Video File
00000101 16:28:48.211 GetSeq: 'D:\GetSeq_Test\TEST\elephants_dream_480p24.y4m'
00000102 16:28:48.398 GetSeq: Has 1 Video streams.
00000103 16:28:48.398 GetSeq: Has 0 Audio streams.
00000104 16:28:48.398 GetSeq: Attempt Open Video with RawSourcePlus.
00000105 16:28:48.414 GetSeq: *** Catch *** Evaluate: Unrecognized exception!
00000106 16:28:48.414 GetSeq: ([GScript], line 83)
00000107 16:28:48.414 GetSeq: ([GScript], line 86)
00000108 16:28:48.414 GetSeq:
00000109 16:28:48.414 GetSeq: !!! Set !!! ... FFMS CacheFile = C:\Users\root\AppData\Local\Temp\elephants_dream_480p24.y4m.ffindex
00000110 16:28:48.414 GetSeq: Attempt Index Video for FFVideoSource.
00000111 16:28:52.142 GetSeq: Attempt Open Video with FFVideoSource.
00000112 16:28:52.158 GetSeq: OK ... FFVideoSource opened Video.
00000113 16:28:52.158 GetSeq: Time taken to Open clip = 3.952888 Seconds(0.065881 Mins)

[Groucho2004]

OK, Tried RawSoucePlus() on avs v2.60 standard, crashes.Script?

[StainlessS]

c = vFn.RawSourcePlus(fpsnum=num,fpsden=den)

[Groucho2004]

c = vFn.RawSourcePlus(fpsnum=num,fpsden=den)
I don't get what GScript and FFVideoSource have to do with it...

[StainlessS]

I'm using it in GetSeq(), via this lot

# END OF GetSeq.avsi
#Import(".\GetSeq.avsi")

#FN="E:\Starwars\SW.avi"
#FN="D:\Parade.avi"
#FN=".\TEST\10Bit_Standard8_Scan_16FPS.avi" # This 10 bit dont load with Avisource(), [and no audio]
#FN=".\TEST\ALTEST2.mp4"
#FN=".\TEST\heima_720p_500.mp4"
#FN=".\TEST\tears_of_steel_1080pwebm.webm"
#FN=".\TEST\1.wmv"
#FN=".\TEST\2018_0525_135958_020.MOV"
#FN=".\TEST\1.flv"
#FN=".\TEST\CrowdRun_2160p50.x264.CRF25.mkv"
#FN=".\TEST\DJI Inspire Drone Video Long GOP Jerkiness .MOV"
FN=".\TEST\elephants_dream_480p24.y4m"
#FN=".\TEST\1.mpg"

PREF="R" ] order of sourcefilters tried
Getseq(FN,Pref=Pref,fpsnum=33000,fpsden=1001,Debug=True) # Test 33000/1001

which called


RawSoucePlus(FN,fpsnum=33000,fpsden=1001)



/*
Req:- RT_Stats, FFMS, LSmash. CallCmd, MediaInfo CLI v0.7.83+ (may work with later versions)

Function GetSeq(String "vFn",String "aFn",String "Pref"="",Val "fpsNum",Val "fpsDen",bool "Debug"=False,Bool "Verbose"=False)


Pref, Default "" {Same as "AIFLDR"). Order in which source filters are tried.
"A" = AviSource() (Only if extension is *.AVI).
"I" = LSmashVideoSource() (Only if extension is an ISO type file, ie mov, mp4, m4v, 3gp, 3g2, mj2, dvb, dcf, m21.).
"F" = FFVideoSource().
"L" = LWLibavVideoSource(), from LSMash.
"D" = DSS2()
"R" = RawSourcePlus().

Specify FrameRate using fpsnum (Numerator) and fpsden (Denominator) # *** INGNORED if AVI ***
num only, eg fpsnum=25.0, FrameRate = 25.0 FPS
num & den, eg fpsnum=24000 fpsden=1001, FrameRate = 23.976 FPS (Both should be type Int).
neither specified FrameRate = UnDefined, ie whatever source filter thinks it is.
ALWAYS:- use named args if using fpsnum/fpsden, argument order may change.





FFMS Cachefile (used for .ffindex file) directory can be set using global variable GLB_GETSEQ_FFMS_CACHE_DIR, NO trailing backslash.
Global GLB_GETSEQ_FFMS_CACHE_DIR = RT_GetSystemEnv("TEMP") # Set to the Current User's Temp directory.

If Global variable GLB_GETSEQ_DEL_INDEX_ON_CLOSE is True, then will auto Delete both FFMS and LSMash indexes on clip closure.
Global GLB_GETSEQ_DEL_INDEX_ON_CLOSE = True # If true, Auto delete indexes on clip closure. # Could create stub which sets True/False depending upon your own arg.

*/


The file itself is from one of the samples in the Avisynth Usage forum stickies (Consolidated list of test video clip resources).

EDIT: Under Avs v2.60 Standard with GScript. (thats why GScript flagged). [RawSourcePlus works fine under AVS+, where using GetSeq() without GScript]
EDIT: Its a bit big to post GetSeq.avsi and the required MIFO_LIB.avsi. (MediaInfo Library of script functions)
EDIT: Tests only done on Win7 not XP.

[Atak_Snajpera]

Is this known issue that VC-1 decoding is totally broken with this plugin?
https://i.imgsafe.org/1a/1abfa504c8.png

[LigH]

Yes, a little while ago:

Yeah the newest L-smash does not work for VC-1 at all,at least not in avs+. Getting super corrupt frames with grey bits everywhere.

[Doriandal]

Why LSMASHVideoSource displays/decodes inmediatly on my PC while LSMASHAudioSource takes more time? If i load an only-video AVS it takes a split-second to load the player, but if i add LSMASHAudioSource it takes like 4 or 5 seconds to load.

I'm working with Apple ProRes, sound is PCM.

Not a big deal but i'm curious about that.

[poisondeathray]

Why LSMASHVideoSource displays/decodes inmediatly on my PC while LSMASHAudioSource takes more time? If i load an only-video AVS it takes a split-second to load the player, but if i add LSMASHAudioSource it takes like 4 or 5 seconds to load.

I'm working with Apple ProRes, sound is PCM.

Not a big deal but i'm curious about that.

It's indexing the audio

LSmashVideoSource does not require indexing for ISO Base formats (MP4, MOV)

[StainlessS]

PDR, confirmation please,
LSMASHAudioSource will sometimes index audio [EDIT: in an ISO container] (as well as LWLibavAudioSource), and not just fail on that audio.

[EDIT: Something I may need to anticipate in multi-source script function]

EDIT: Are there any circumstances in which LSmashVideoSource will index video ?

[StainlessS]

Thanks HolyWu.

ChaosKing,
I think you were keeping list of file extensions that LSmashVideoSource could deal with.
Playing with MediaInfo 19.07, I noticed this

00000108 07:25:42.729 MIFO_Get: General
00000109 07:25:42.729 MIFO_Get: Count : 322
00000110 07:25:42.729 MIFO_Get: StreamCount : 1
00000111 07:25:42.729 MIFO_Get: StreamKind : General
00000112 07:25:42.729 MIFO_Get: StreamKind/String : General
00000113 07:25:42.729 MIFO_Get: StreamKindID : 0
00000114 07:25:42.729 MIFO_Get: VideoCount : 3
00000115 07:25:42.729 MIFO_Get: AudioCount : 3
00000116 07:25:42.729 MIFO_Get: Video_Format_List : AVC / AVC / AVC
00000117 07:25:42.729 MIFO_Get: Video_Format_WithHint_List : AVC / AVC / AVC
00000118 07:25:42.729 MIFO_Get: Video_Codec_List : AVC / AVC / AVC
00000119 07:25:42.729 MIFO_Get: Audio_Format_List : AAC / AAC / AAC
00000120 07:25:42.729 MIFO_Get: Audio_Format_WithHint_List : AAC / AAC / AAC
00000121 07:25:42.729 MIFO_Get: Audio_Codec_List : AAC LC / AAC LC / AAC LC-SBR
00000122 07:25:42.729 MIFO_Get: CompleteName : D:\MintSource\TEST\VAVAVA.mp4
00000123 07:25:42.729 MIFO_Get: FolderName : D:\MintSource\TEST
00000124 07:25:42.729 MIFO_Get: FileName : VAVAVA
00000125 07:25:42.729 MIFO_Get: FileExtension : mp4
00000126 07:25:42.729 MIFO_Get: Format : MPEG-4
00000127 07:25:42.729 MIFO_Get: Format/String : MPEG-4
00000128 07:25:42.729 MIFO_Get: Format/Extensions : mp4 m4v m4a m4b m4p 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma f4v
00000129 07:25:42.729 MIFO_Get: Format_Commercial : MPEG-4
00000130 07:25:42.729 MIFO_Get: Format_Profile : Base Media
00000131 07:25:42.729 MIFO_Get: InternetMediaType : video/mp4
00000132 07:25:42.729 MIFO_Get: CodecID : isom
00000133 07:25:42.729 MIFO_Get: CodecID/String : isom (isom/avc1)

So I've added missing ones to my list of ISO file extensions that LSmashVideoSource/LSmashAudioSource can open.
Complete list.

Function IsISOFileName(String s) {s=RT_GetFileExtension(s) Return(s==".mov"||s==".mp4"||s==".m4v"||s==".3gp"||s==".3gpp2"||s==".3g2"||s==".mj2"||s==".dvb"||
\ s==".dcf"||s==".m21"||s==".m4a"||s==".m4b"||s==".m4p"||s==".k3g"||s==".jpm"||s==".jpx"||s==".mqv"||s==".ismv"||s==".isma"||s==".f4v")}


Or bare.

mov, mp4, m4v, 3gp, 3gpp2, 3g2, mj2, dvb, dcf, m21, m4a, m4b, m4p, k3g, jpm, jpx, mqv, ismv, isma, f4v

[Selur]

thanks, btw. a small tool to create the cache file (like fmsindex for ffvideosource) would be nice :)

[FranceBB]

L-SMASH-Works-r935+26-win64-20190808 (https://www.mediafire.com/file/4o4ivbpz68brfo4/L-SMASH-Works-r935+26-win64-20190808.7z/file)


Update to FFmpeg 4.2.
Add parameter cachefile.


Uh... may I ask you an x86 version, please? :P

[Atak_Snajpera]

L-SMASH-Works-r935+26-win64-20190808 (https://www.mediafire.com/file/4o4ivbpz68brfo4/L-SMASH-Works-r935+26-win64-20190808.7z/file)


Update to FFmpeg 4.2.
Add parameter cachefile.


Thank you for cachefile file option!

[LigH]

@Selur: In the meantime, you may use avsr (by Groucho2004) with a minimal script, if applicable...

[Groucho2004]

@Selur: In the meantime, you may use avsr (by Groucho2004) with a minimal script, if applicable...What do you mean by "minimal script"? All you have to do is use the "-i" switch with avsr and the cache/index file will be created. There's no progress indicator though...

[stax76]

Add parameter cachefile

Thanks for adding this. :thanks:

[Atak_Snajpera]

What do you mean by "minimal script"? All you have to do is use the "-i" switch with avsr and the cache/index file will be created. There's no progress indicator though...

Perhaps something like this?

LoadPlugin("LSMASHSource.dll")
LWLibavVideoSource("video.mkv")
Trim(0,-1)

[MeteorRain]

Perhaps something like this?

avs4x26x-x64 video.mkv

[LigH]

Yes, I mean that only for indexing, none of the filters for the final video need to be included ("minimal" in the sense to only load the [audio and] video). Like Atak_Snajpera suggested.

[Groucho2004]

Yes, I mean that only for indexing, none of the filters for the final video need to be included ("minimal" in the sense to only load the [audio and] video). Like Atak_Snajpera suggested.Right. As I mentioned, since one most likely already has a script, indexing will be triggered by using avsr with the switch "-i" which simply displays the clip properties.

[MeteorRain]

What do you mean by "minimal script"?

Right. As I mentioned, since one most likely already has a script,

Having non-minimal script could significantly increase loading time if complicated filters are used, such as waifu or QTGMC.

I always use a bare source script to generate the index, and later a fully functional script to do the actual encode.

Anyway, you can always use avs4x26x like I mentioned above to automatically create the script (in memory) and generate the index.

[LigH]

Praise the HolyWu! :D

[Taurus]

Link updated in the previous post. The other thread as well.
:thanks::thanks::thanks:

[Atak_Snajpera]

I have another feature request.
Store index file in compressed form. Currently index file can be extremely large in comparison to .ffindex.
video.mkv is remuxed Alien Covenant DVD (2h movie). Just take a look how tiny .ffindex is
https://i.imgsafe.org/2b/2b22e3a221.png

Large index file is not a problem if you load that file locally from SSD. Normally It should take less than 1s. However it is a different story if you have to load that file directly via network 100Mbps LAN or wi-fi n.

video=LWLibavVideoSource("\\XEON-PC\RipBot264temp\job1\video.mkv",threads=0,cachefile="\\XEON-PC\RipBot264temp\job1\video.mkv.lwi")

That large uncompressed index file significantly delays starting of encoding process. It gets even worse if more than one server is downloading that file.

example
https://i.imgur.com/RLzjto9.jpg

Now 6 servers are downloading 200MiB index file at the same time. (1.2GiB total). Assuming that real transfer rate for LAN100Mbps is only ~10MiB/s we can easily predict that encoding process will be delayed by about 2 minutes!

So my suggestion is to always compress index file with some basic zip algorithm. LZMA (normal) can compress that index file to ~5MiB while Zip to ~10MiB.
Time saving will be immediately noticeable. Delay will be measured in seconds instead of minutes.

[Myrsloik]

I have another feature request.
Store index file in compressed form. Currently index file can be extremely large in comparison to .ffindex.
video.mkv is remuxed Alien Covenant DVD (2h movie). Just take a look how tiny .ffindex is
https://i.imgsafe.org/2b/2b22e3a221.png

Large index file is not a problem if you load that file locally from SSD. Normally It should take less than 1s. However it is a different story if you have to load that file directly via network 100Mbps LAN or wi-fi n.



That large uncompressed index file significantly delays starting of encoding process. It gets even worse if more than one server is downloading that file.

example
https://i.imgur.com/RLzjto9.jpg

Now 6 servers are downloading 200MiB index file at the same time. (1.2GiB total). Assuming that real transfer rate for LAN100Mbps is only ~10MiB/s we can easily predict that encoding process will be delayed by about 2 minutes!

So my suggestion is to always compress index file with some basic zip algorithm. LZMA (normal) can compress that index file to ~5MiB while Zip to ~10MiB.
Time saving will be immediately noticeable. Delay will be measured in seconds instead of minutes.

FFMS2 uses zlib and preprocessing of the data (store the differences between timestamps/frame numbers instead of absolute timestamps/frame numbers). Huffman coding based things already work wonders on that kind of data. Just a hint.

[FranceBB]

Link updated in the previous post. The other thread as well.

Thank you! :D

[Morku]

Edit: Nevermind.

[stax76]

Did you verify that it actually outputs double width? There was a patch for native high bit depth support.

[MeteorRain]

I have another feature request.
Store index file in compressed form. Currently index file can be extremely large in comparison to .ffindex.
video.mkv is remuxed Alien Covenant DVD (2h movie). Just take a look how tiny .ffindex is
https://i.imgsafe.org/2b/2b22e3a221.png

Large index file is not a problem if you load that file locally from SSD. Normally It should take less than 1s. However it is a different story if you have to load that file directly via network 100Mbps LAN or wi-fi n.



That large uncompressed index file significantly delays starting of encoding process. It gets even worse if more than one server is downloading that file.

example
https://i.imgur.com/RLzjto9.jpg

Now 6 servers are downloading 200MiB index file at the same time. (1.2GiB total). Assuming that real transfer rate for LAN100Mbps is only ~10MiB/s we can easily predict that encoding process will be delayed by about 2 minutes!

So my suggestion is to always compress index file with some basic zip algorithm. LZMA (normal) can compress that index file to ~5MiB while Zip to ~10MiB.
Time saving will be immediately noticeable. Delay will be measured in seconds instead of minutes.

Removing audio part (I do all the time) will save tones of space. Not just transferring, but loading and parsing the index itself could take up to minutes for a large file, until you remove the audio part from the index.

It's as simple as removing lines containing Type=1 or Channel. You can use sed to manipulate the file.

[Atak_Snajpera]

Removing audio part (I do all the time) will save tones of space. Not just transferring, but loading and parsing the index itself could take up to minutes for a large file, until you remove the audio part from the index.

It's as simple as removing lines containing Type=1 or Channel. You can use sed to manipulate the file.

Thanks for your tip! After processing by sed I got indeed much smaller file

https://i.imgsafe.org/54/545e93fdf0.png

Nevertheless It is still too much for me. (4s extra delay on LAN100). Additionally to your 'hack' I decided to keep that index file in compressed form (LZMA-normal) for encoding server app. So instead of using index file directly now server has to first decompress index file to some temp folder.

[Atak_Snajpera]

L-SMASH-Works-r935+31-20190817 (https://www.mediafire.com/file/ip53lynpkvk8l3q/L-SMASH-Works-r935+31-20190817.7z/file)


LWLibavVideoSource no longer indexes audio streams. It reduces both the file size and parsing time of the index file. LWLibavAudioSource will re-create the index file for the source file which was already indexed by LWLibavVideoSource so as to index audio streams.
Print indexing progress to stdout.
Tell lavf to discard unwanted packets so they needn't be demuxed.
Remove InputFilePath field from the index file. It's unnecessary and troublesome when users rename or move the source file.
Automatically re-create the index file when the file size or the last modification time of the source file doesn't match.


LOL! You are reading in my mind! I had to always change that from local path (c:\something\...) to network path (\\XEON-PC\...)

Now only one thing is missing. Compression of index file like in FFMS2 index file. Thank you.

[stax76]

@HolyWu

Very exciting improvements. I'm sure it's not only GUI authors that have been waiting for this long time. :thanks:

[ChaosKing]

L-SMASH-Works-r935+31-20190817 (https://www.mediafire.com/file/ip53lynpkvk8l3q/L-SMASH-Works-r935+31-20190817.7z/file)


LWLibavVideoSource no longer indexes audio streams. It reduces both the file size and parsing time of the index file. LWLibavAudioSource will re-create the index file for the source file which was already indexed by LWLibavVideoSource so as to index audio streams.
Print indexing progress to stdout.
Tell lavf to discard unwanted packets so they needn't be demuxed.
Remove InputFilePath field from the index file. It's unnecessary and troublesome when users rename or move the source file.
Automatically re-create the index file when the file size or the last modification time of the source file doesn't match.


THX
Would it be possible to add a gpu parameter? I saw that there is a supported HW decoders list, so maybe just a cuvid_gpu/qsv_gpu = true/false parameter could be added to avoid nvidia intel gpu detection? It should then set the hevc, h264, mjpeg, etc. decoder accordingly.

[Atak_Snajpera]

Sorry. It probably won't happen, at least from me.

Ok. No problem.

[FranceBB]

Thank you for the update, once again! :)

[real.finder]

HolyWu, why not use github?

and the changes you made has no public source code?

[jpsdr]

Thanks for your builds.
A while ago, i used to make builds using the method described here (with VS 2015 at the time) : https://github.com/BrunoReX/build-scripts/blob/master/L-SMASH/readme.md
Unfortunately, one day, the part with VS201x x86 Native Tools Command Prompt suddenly stoped working. Didn't know if it was something in msys2 or VS which has changed.
A little question : Your release said r935+31, and your link showes 6 patches, when, i was expected 31.
The only source i know is this one : https://github.com/VFR-maniac/L-SMASH-Works/branches
Is there another one ?

[DJATOM]

There are also https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works