L-SMASH Source

[MeteorRain]

Yea that was what I immediately noticed when I was encoding some stuff.

[Natty]

Originally Posted by MeteorRain

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

Stop indexing progress spamming

-- Now only refresh at every 1%.

[Atak_Snajpera]

@MeteorRain
Quick question: Why LSMASHSource.dll is 2 times smaller than HolyWu's version?

[DJATOM]

Different compilers or some features disabled at configuring time?

[MeteorRain]

Originally Posted by Atak_Snajpera

@MeteorRain
Quick question: Why LSMASHSource.dll is 2 times smaller than HolyWu's version?

Size of ffmpeg makes huge differences. I disabled lots of features, and that's probably why.

Last build was on VS 2017 n4.1.3. I'll probably do a refresh VS 2019 n4.2.0 soon for the next build.

"C:\Programs (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars32.bat"
chcp 65001
./configure --toolchain=msvc --prefix=/ffmpeg-msvc32 --cpu=i686 --arch=i386 --target-os=win32 --disable-pthreads --disable-bzlib --disable-iconv --disable-lzma --disable-xlib --disable-zlib --disable-muxers --disable-encoders --disable-network --enable-gpl --enable-version3 --disable-programs --disable-doc


"C:\Programs (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"
chcp 65001
./configure --toolchain=msvc --prefix=/ffmpeg-msvc64 --arch=x86_64 --target-os=win64 --disable-pthreads --disable-bzlib --disable-iconv --disable-lzma --disable-xlib --disable-zlib --disable-muxers --disable-encoders --disable-network --enable-gpl --enable-version3 --disable-programs --disable-doc

[ChaosKing]

@MeteorRain It would be nice if you could also add vapoursynth support in your next LSmash release on github

[MeteorRain]

@ChaosKing, support of what? Current release had no problem running under VapourSynth. Any particular thing I should be aware of?

[ChaosKing]

The current r935+2 release on github only supports avisynth and it would be nice if the next release (r935+X) in your github repo could also include vapoursynth support
I ask because I would like to add it to vsrepo.
Currently it is included in avsrepo https://github.com/theChaosCoder/avs...al/lsmash.json

[MeteorRain]

Oh you meant github release. Yea definitely.

Also please be aware it's not the original / official release, but rather a fork.

[HolyWu]

L-SMASH-Works_20190903.7z

• Fix abnormal loading time.
• Improve progress printing.
• Use both file size and partial checksum (xxhash) for file signature comparison in index file.
• LWLibav: Fix inaccurate framerate in some files.
• VapourSynth: Replace configure with Meson build system.
• VapourSynth: Fix missing setError invocation when there is an error.
• Fix frame corruption in some VC-1 files by a workaround. Tested Atak_Snajpera's sample by seek-test.py and confirmed to be frame accurate.

[Atak_Snajpera]

Originally Posted by HolyWu

L-SMASH-Works_20190903.7z

• Fix abnormal loading time.
• Improve progress printing.
• Use both file size and partial checksum (xxhash) for file signature comparison in index file.
• LWLibav: Fix inaccurate framerate in some files.
• VapourSynth: Replace configure with Meson build system.
• VapourSynth: Fix missing setError invocation when there is an error.
• Fix frame corruption in some VC-1 files by a workaround. Tested Atak_Snajpera's sample by seek-test.py and confirmed to be frame accurate.

Can you reduce size of .dll like MeteorRain did here https://forum.doom9.org/showthread.p...99#post1883899

[FranceBB]

Originally Posted by HolyWu

L-SMASH-Works_20190903.7z

• Fix abnormal loading time.
• Improve progress printing.
• Use both file size and partial checksum (xxhash) for file signature comparison in index file.
• LWLibav: Fix inaccurate framerate in some files.
• VapourSynth: Replace configure with Meson build system.
• VapourSynth: Fix missing setError invocation when there is an error.
• Fix frame corruption in some VC-1 files by a workaround. Tested Atak_Snajpera's sample by seek-test.py and confirmed to be frame accurate.

Thank you!

[HolyWu]

Originally Posted by Atak_Snajpera

Can you reduce size of .dll like MeteorRain did here https://forum.doom9.org/showthread.p...99#post1883899

I don't understand. Does a size difference of 10 MB really matter on current HDD or internet bandwidth?
Anyway, the culprit is not in FFmpeg as I already knew of disabling unused features when I began providing my builds ages ago.

The main reasons are that different compiler being used and two additional libraries being linked in, one is libaom and the other is libmfx.
For libaom it's used for AV1 decoding. I think I will just ditch it since it's way slower than libdav1d. Just use FFMS2 for AV1 and VP9 decoding as it passed random seek test after some proper patching. Unfortunately for AVC and HEVC decoding it still has random seek issue with some samples even using StvG's latest build, while LWLibav passed.
For libmfx it's used for Intel Quick Sync Video decoding. I need someone with capable Intel GPU to test whether the _qsv decoders also have random seek issue like the _cuvid decoders do, so as to decide whether I should keep it or ditch it.

[Atak_Snajpera]

Originally Posted by HolyWu

I don't understand. Does a size difference of 10 MB really matter on current HDD or internet bandwidth?
Anyway, the culprit is not in FFmpeg as I already knew of disabling unused features when I began providing my builds ages ago.

The main reasons are that different compiler being used and two additional libraries being linked in, one is libaom and the other is libmfx.
For libaom it's used for AV1 decoding. I think I will just ditch it since it's way slower than libdav1d. Just use FFMS2 for AV1 and VP9 decoding as it passed random seek test after some proper patching. Unfortunately for AVC and HEVC decoding it still has random seek issue with some samples even using StvG's latest build, while LWLibav passed.
For libmfx it's used for Intel Quick Sync Video decoding. I need someone with capable Intel GPU to test whether the _qsv decoders also have random seek issue like the _cuvid decoders do, so as to decide whether I should keep it or ditch it.

Yes it matters if you use distributed encoding in ripbot264 where all tools and plugins are being downloaded from host PC. I just want to reduce starting time as much as possible on ~80Mbps (10MiB/s) LAN/Wi-FI. I'm already using compressed (by upx) ffmpeg.exe (20MiB),x264(8MiB) and x265(7MiB) in order to reduce encoding delay. I also decided to compress index file with 7zip in order to reduce index file from ~30MiB to ~1MiB.


example script

#VideoSource
LoadPlugin("\\HOST-PC\RipBot264temp\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("\\HOST-PC\RipBot264temp\job1\video.mkv",threads=0,cachefile="\\HOST-PC\RipBot264temp\job1\video.mkv.lwi")

cmd.

"\\HOST-PC\Ripbot264temp\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "\\HOST-PC\RipBot264temp\job1\Chunks\1.avs" -strict -1 -f yuv4mpegpipe - | "\\HOST-PC\Ripbot264temp\tools\x264\x264_x64.exe" --stdin y4m --output "\\HOST-PC\RipBot264temp\job1\Chunks\1.264" -

[StvG]

Originally Posted by HolyWu

I don't understand. Does a size difference of 10 MB really matter on current HDD or internet bandwidth?
Anyway, the culprit is not in FFmpeg as I already knew of disabling unused features when I began providing my builds ages ago.

The main reasons are that different compiler being used and two additional libraries being linked in, one is libaom and the other is libmfx.
For libaom it's used for AV1 decoding. I think I will just ditch it since it's way slower than libdav1d. Just use FFMS2 for AV1 and VP9 decoding as it passed random seek test after some proper patching. Unfortunately for AVC and HEVC decoding it still has random seek issue with some samples even using StvG's latest build, while LWLibav passed.
For libmfx it's used for Intel Quick Sync Video decoding. I need someone with capable Intel GPU to test whether the _qsv decoders also have random seek issue like the _cuvid decoders do, so as to decide whether I should keep it or ditch it.

Disabling aom AV1 encoder and aom tests will save space if you didn't do it already.

Can you share those AVC and HEVC samples that have seeking issues with ffms2?
Thanks.

[videoh]

Originally Posted by StvG

Can you share those AVC and HEVC samples that have seeking issues with ffms2?

I second that request. I would like to test them with DG tools.

[HolyWu]

https://github.com/HolyWu/L-SMASH-Works/releases/latest

Uploaded new binary which ditches libaom and is built by clang-cl. The binary size is smaller than the previous ICL build and decoding speed seems to be marginally faster.

Originally Posted by StvG

Can you share those AVC and HEVC samples that have seeking issues with ffms2?
Thanks.

No problem. Here.

[videoh]

Thank you, HolyWu.

[Reel.Deel]

Originally Posted by HolyWu

L-SMASH-Works_20190903.7z

• Fix abnormal loading time.
• Improve progress printing.
• Use both file size and partial checksum (xxhash) for file signature comparison in index file.
• LWLibav: Fix inaccurate framerate in some files.
• VapourSynth: Replace configure with Meson build system.
• VapourSynth: Fix missing setError invocation when there is an error.
• Fix frame corruption in some VC-1 files by a workaround. Tested Atak_Snajpera's sample by seek-test.py and confirmed to be frame accurate.

The list here seem to suggest that MeteorRain's changes are also include. Yet the L-Smash GitHub repo says otherwise, am I missing something?

MeteorRain's L-Smash GitHub repo is up-to-date minus the your recent commits.

[HolyWu]

Originally Posted by Reel.Deel

The list here seem to suggest that MeteorRain's changes are also include. Yet the L-Smash GitHub repo says otherwise, am I missing something?

The changes were simply melded into the original commits since there was not a release yet on my repo.