L-SMASH Source

[HolyWu]

Change the printing of index progress from stdout to stderr so as to avoid corrupting pipe data accidentally. Link in the previous post updated.

Originally Posted by ChaosKing

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.

Too less interest for me.

[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-sc...MASH/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/HomeOfAviSynthPlu.../L-SMASH-Works

[Reel.Deel]

Originally Posted by DJATOM

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

Obviously now outdated due to the recent changes made by HolyWu. But according to MeteorRain, his version is:

Originally Posted by MeteorRain

The same patch set HolyWu used, which was copied from enccc, and one more patch to use swresample instead of avresample, which was copied from l33tmeatwad.

I've started a section in the LSMASHSource wiki noting some of these changes. I hope I did not miss anything, I went back and tried to see if there's anything else but it seems some of HolyWu's earlier posts are gone .

[MeteorRain]

Since Holy released all the patches, I'll (after a vacation unfortunately) try to integrate them into the repo.

Lots of works are piled up on me, so please be patient. (Also there's work to do on f3kdb and minideen etc.)

[Atak_Snajpera]

Originally Posted by HolyWu

L-SMASH-Works-r935+31-20190818

• 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 stderr.
• 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.

Could you remove that checking of "Last modification time"?
It is annoying that lsmash now always re-indexes file which was just copied.

original
video=LWLibavVideoSource("original_video.MP4",cachefile="C:\index.lwi")

Copy
video=LWLibavVideoSource("C:\copy_of_original_video.MP4",cachefile="C:\index.lwi")

The same file but with different modification time. For example FFMS2 does not care about "Last modification time". I think it only checks file size.

[MeteorRain]

Atak,

Although I agree there's other ways of doing the check, I don't think Windows file copy actually changes the mtime.

If you use cp, you can use --preserve=timestamps.

I might want to change it to some quick partial checksum if mtime mismatches.

[Atak_Snajpera]

The issue is that i AM copying files using my own custom code (streams and no win api). In this case last modification date is different. I think that Simple check for file size is enough.

[HolyWu]

Originally Posted by Atak_Snajpera

For example FFMS2 does not care about "Last modification time". I think it only checks file size.

FFMS2 also checks partial SHA-1 hashing in addition to file size, but I really don't bother to do it. After all video files aren't like text files that normal users would open them in Notepad++ and edit some random bytes. Hence I agree that simply checking file size should be sufficient for most users. Redownload from the usual post.

[Taurus]

@HolyWu
Tried to redownload your build from the mediafire link.
"Download not available"....
Thanks for your efforts!
Aaah, I just saw it is working again,
maybe a mediafire hiccup ;-)

[Atak_Snajpera]

Originally Posted by HolyWu

FFMS2 also checks partial SHA-1 hashing in addition to file size, but I really don't bother to do it. After all video files aren't like text files that normal users would open them in Notepad++ and edit some random bytes. Hence I agree that simply checking file size should be sufficient for most users. Redownload from the usual post.

Once again thank you for this quick change

[jpsdr]

As isaid, i used to make builds using the method described here (with VS 2015 at the time) : https://github.com/BrunoReX/build-sc...MASH/readme.md
I've been able to find out the main issue, it's probably a change in msys2 behavior, which doesn't keep the %PATH% by default.
I fixed it, make all the gcc builds, but when compiling the VS project, i have the following error :
LINK : fatal error LNK1104: unable to open file 'lsmash.lib'

I take any idea or advice.

[MeteorRain]

Originally Posted by HolyWu

Hence I agree that simply checking file size should be sufficient for most users.

Not exactly correct. A potential issue is that user try to cut a mpeg-ts file at fixed length and overwrite to the same output file. Re-opening such segment the second time will probably crash the code.

I second the idea of checksuming, and if you don't bother doing that, I might.

[MeteorRain]

LSMASHSource-Release_r935+33.zip
Commit Diff

I have changed the logic. If size and timestamp match, assume unchanged. If size matches but not timestamp, hash (first 1MiB + last 1MiB) and compare with recorded hash. If file is too small, only first up to 1MiB counts. Hash method is xxhash which is extremely fast.

A missing hash record will not force regenerating the index file as long as size and timestamp match.

Let me know how that works.

I also include an easy-compiling branch and a cmake build script. Get VS 2017 / 2019 and cmake installed, and use the following batch file to build your copy.

@echo off

mkdir build\x86
pushd build\x86
cmake -DCMAKE_GENERATOR_PLATFORM=Win32 -D_DIR=x86 ..\..\
popd
mkdir build\x64
pushd build\x64
cmake -DCMAKE_GENERATOR_PLATFORM=x64 -D_DIR=x64 ..\..\
popd
cmake --build build\x86 --config Release
cmake --build build\x64 --config Release

[Atak_Snajpera]

Do you guys know why decoding VC-1 using vc1_cuvid is also broken? Unlike software decoder frames are not corrupted but they are decoded in incorrect order.
sample -> https://www.mediafire.com/file/dldzx...ample.mkv/file

script
LoadPlugin("LSMASHSource.dll")
video=LWLibavVideoSource("vc1_sample.mkv",cachefile="vc1_sample.mkv.lwi",decoder="vc1_cuvid")

Decoding works fine in MPC-HC with these settings


PS. yes I have latest driver installed.

[DJATOM]

@Atak_Snajpera
HW decoder is actually inactive on your screenshot.

[Atak_Snajpera]

Originally Posted by DJATOM

@Atak_Snajpera
HW decoder is actually inactive on your screenshot.

But CPU usage is 3 times lower so it works.


Also there is H/W indicator

[MeteorRain]

https://down.7086.in/AviSynthPlus%20...-r935%2B34.zip

Stop indexing progress spamming

-- Now only refresh at every 1%.

[stax76]

@HolyWu

With my 49 PGS subtitle 50 GB file using your last build I'm getting 60 seconds load time, with MeteorRain's build it's only 10 seconds.

edit:

both was tested with 20 PGS subtitles, with 49 PGS subtitles MeteorRain's build took 30 seconds and yours 7 minutes.