L-SMASH Source

[LigH]

Of course, even if there are special source plugins supporting playlists like MPLS or D2V, making L-SMASH Works (as well as FFMS2) support it too would just add flexibility. So far they support only single source files, which forces people to use alternatives if they have a sequence of source files. And if it is easy to implement, even better (at least interpreting the playlists; handling a sequence is still another step).

[dipje]

Use Vapoursynth and code the MPLS support yourself inside your Python script? :)

[LigH]

Some people prefer AviSynth, with or without the plus. The reason why this request got exhumed was a recent issue of another user in the German doom9/Gleitz forum with StaxRip x64, which does not support VapourSynth, and possibly does not yet support DGMPGDec x64 either (and since stax76 abandoned the project, it may not anymore). So, no more conversion of DVDs ripped to VOB segments with StaxRip x64 anymore... their users would have to change their workflow to extracting a continuous video stream to be able to handle it using L-SMASH Works (or FFMS2) until support for d2v index files may get implemented.

[Groucho2004]

StaxRip x64, which does not support VapourSynth
What? Have you looked at the first post in the staxrip 64 thread?

Some people prefer AviSynth, with or without the plus. The reason why this request got exhumed was a recent issue of another user in the German doom9/Gleitz forum with StaxRip x64, which does not support VapourSynth, and possibly does not yet support DGMPGDec x64 either (and since stax76 abandoned the project, it may not anymore).
I know that staxrip does not use JoshyD's DGMPGDec x64, most likely because it is ridiculously buggy.

As for handling D2V files, see this post (https://forum.doom9.org/showthread.php?p=1766297#post1766297). Note that d2vsource expects the .d2v files in a specific format, one can't just use any version of DGIndex.

I know virtually nothing about staxrip but a few minutes of searching sometimes helps. :rolleyes:

[LigH]

OK, sorry, I was about to leave when I wrote that... :o

And stax76 just wrote to support MPEG2DecPlus in the future.

[gaak]

Quick question: Does LWLibavVideoSource() support .vc1?

[sneaker_ger]

Yes. But ffmpeg's VC-1 decoder is kinda buggy so I would recommend a different decoder like DGDecNV or even LAV (with MS or DXVA2).

[gaak]

Yes. But ffmpeg's VC-1 decoder is kinda buggy so I would recommend a different decoder like DGDecNV or even LAV (with MS or DXVA2).

Thanks!

[VFR maniac]

If QSV is available in your environment, decoder="vc1_qsv" is an option I think.

[wellivea1]

I am new to encoding, and found myself wanting to filter something with avisynth, then encode. My friend who was helping me instructed me to use LSMASH to decode the source (BD). This ends in a "C++" error every time (https://puu.sh/tgkBz/3a91a071a1.png) I have tried a lot of things to to get it to work, to no avail. My friend also said I may be missing some kind of dependency, but I have all the plugins I need, and there is no dll or anything referenced in the documentation. PLEASE HELP!!!!
p.s here's the script (https://puu.sh/tgkJf/8d83171f0b.avs)

[LigH]

I doubt the reason is in L-SMASH Works, I rather suspect the other plugins (what is SuperGrainBros ?!) which are not explicitly loaded, which may be the reason why there is an "unhandled C++ exception" supposedly in line 1, although it is possibly even before (in the plugin autoloading).

I guess AVSMeter may help discovering the reason, but I am not sure if it has to be called with parameters to be more detailed and verbose...

Also try to comment out every line except the first (only LwLibavVideoSource, no other filter) and see if there is still the same error.

[wellivea1]

After clearing out my plugins folder, and reinstalling the necessary vsredist packages, the script now runs perfectly. Also my friend said this about SuperGrainBros "its a quick and lazy mod of AdaptDBMC to combine it with zzz_denoise to re-use the motion vectors and provide internal 16-bit processing, set up with defaults tailored to that specific encode, or something like that" but he said not to use it lol. Also for some reason the error still appears on mpc-hc, I don't know why, because it disappeared everywhere else.

More screenshots:

AVSmeter output: https://puu.sh/thmDU/e6f6bd50f5.png

Script: https://puu.sh/thmFQ/c0d541255c.png

[LigH]

Is your MPC-HC the 32-bit or the 64-bit version? Remember, MPC-HC 64 bit would try to use the 64 bit version of AviSynth+, while other 32 bit applications would use the 32 bit version of AviSynth+.

By the way, you will find much more recent AviSynth+ versions than r1779 in this board, see this post (http://forum.doom9.org/showthread.php?p=1792671#post1792671) for the latest test build or earlier releases by pinterf (https://github.com/pinterf/AviSynthPlus/releases).

[kuchikirukia]

Any idea how to fix this? Avisynth running QTGMC seems to create a major problem for input filters (ffms2 and LSMASH) which absolutely torpedoes frame rates -- but only if you start at the first few frames. Set something like trim(10,0) and it doesn't run into issues.
Is this an avisynth bug or could something be done to LSMASH to stabilize it?

https://picload.org/image/rogcpdpl/untitled.png

[MysteryX]

The latest version of L-SMASH Source is giving me some audio/video sync issue on some videos. The previous version of L-SMASH I had doesn't have this issue, and most videos are playing fine.

This is the script I'm running

P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"TimeStretch.dll")
file="Angerme - A Mystery Night.mkv"
LWLibavVideoSource(file, cache=False)
AudioDub(LWLibavAudioSource(file, cache=False))
Preroll(int(FrameRate*3))
ResampleAudio(48000)
TimeStretchPlugin(pitch = 100.0 * 0.98181819915771484)


Here's a video that has sync issue with the latest version. I'm using the build with a single DLL.
https://mega.nz/#!6V4x0A5Z!yqFI6k09lsf8KHCycSYRTyf7ABVUSnvAsPmgxYwHtMk

Btw, I know the static build has a disadvantage... what is that disadvantage exactly? Is it something serious?

Edit: just tried the non-static build, and it has the same problem. I'll have to keep using the old DLL for now.

[jpsdr]

To build lsmash source, i was using what described here (https://github.com/BrunoReX/build-scripts/blob/master/L-SMASH/readme.md).
Now, with the actual version of msys2, i have issue with this step :

rename link.exe in msys32\usr\bin in link.exe.bak

Building for x86:
Open Visual Studio 2013 -> Visual Studio Tools -> VS2013 x86 Native Tools Command Prompt
Type C:\msys2\mingw32_shell.bat
Type cd "c:\work\ffmpeg"
Type mkdir build32-msvc && cd build32-msvc
Type ../configure --toolchain=msvc --prefix=/mingw32/local-msvc --enable-avresample --disable-programs --disable-doc --disable-swresample --disable-encoders --disable-hwaccels --disable-filters --disable-debug
Type make && make install

Whatever i use either VS2013 or VS2015, it seems that now, when i start the mingw console window, the paths from within the VS2013 x86 Native Tools Command Prompt are lost. cl or link become unknow commands, when they still work directly within the VS2013 x86 Native Tools Command Prompt. It wasn't like that with "old" version of msys2. I think it's like this since one year or two, but no more.
Does anyone know what i have to do for this working again ?

[Morku]

Can you have a look into this?
https://forum.doom9.org/showpost.php?p=1798208&postcount=369
I can't decode audio with latest r924 (LSMASHAudioSource("x.mov")).
Previous version is fine.

[MysteryX]

Here the latest build is 20161226. Where did you get build 20170219?
https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0

[Morku]

No, MeGUI uses the Avisynth Plugin version and the latest version was provide 3 days ago. It came with MeGUI update and it's the same file on Dropbox. I use 64-bit version.

[LigH]

Then we all wonder how MeGUI gets this new version delivered. Can Zathor build it? Or which build did he select?

[sneaker_ger]

The new builds are in the dropbox just like Morku said. MysteryX seems to have overlooked them for some reason.

[MysteryX]

Oh, now I see the 2 lower files were released 3 days ago. I'm a bit confused about the 2 upper files vs 2 lower files.

[LigH]

Different build methods, I suppose; will have a reason to point at using MSVC.

[LigH]

Would it be easy/complicated/expensive/illegal to have L-SMASH Works support HWAccel (https://trac.ffmpeg.org/wiki/HWAccelIntro) features of ffmpeg for decoding?

[stax76]

Would it be easy/complicated/expensive/illegal to have L-SMASH Works support HWAccel (https://trac.ffmpeg.org/wiki/HWAccelIntro) features of ffmpeg for decoding?

It supports it already using the decoder param:

+ decoder (defalut : "")
Names of preferred decoder candidates separated by comma.
For instance, if you prefer to use the 'h264_qsv' and 'mpeg2_qsv' decoders instead of the generally
used 'h264' and 'mpeg2video' decoder, then specify as "h264_qsv,mpeg2_qsv". The evaluations are done
in the written order and the first matched decoder is used if any.

It didn't work last time I tried it.

[raffriff42]

It supports it already using the decoder param
...
It didn't work last time I tried it.
Both these work for me:
LWLibavVideoSource("file.mp4", decoder="h264_nvenc")
LSMASHVideoSource("file.mp4", decoder="h264_nvenc")

This does not work (error = "LWLibavVideoSource: failed to get the video track"),
but that is expected because QuickSync is disabled on the PC I am using:
LWLibavVideoSource("file.mp4", decoder="h264_qsv")

EDIT this does not work, which seems like a bug:
LWLibavVideoSource("file.mp4", decoder="h264_qsv,h264")
LSMASHVideoSource("file.mp4", decoder="h264_qsv,h264")

EDIT but this does work:try {
LWLibavVideoSource("file.mp4", decoder="h264_qsv") ## ERROR for me
}
catch (err_msg) {
LWLibavVideoSource("file.mp4", decoder="h264") ## FALLBACK
Subtitle(err_msg) ## (for testing only, normally ignore the error)
}

[stax76]

h264_nvenc works indeed which is exciting. With QuickSync is disabled you mean not supported by your hardware? I thought almost all Intel CPUs support QS avc decoding.

[raffriff42]

I disabled it because I (perhaps irrationally) don't care for it, and I don't want any program using it "behind my back" :)

[dipje]

I thought almost all Intel CPUs support QS avc decoding.

Intel Core i-series 2000 and up. And even on the 2000 series you need to actually have a monitor connected to the iGPU (or some dummy monitor of course) to enable it. I believe from the 3000 series or even the 4000 series and up it's (easily) enabled even when using an external GPU.

A lot of people with socket 775 systems (core 2 duo , core 2 quad) out there or systems like mine (overclocked first i7 series) without QuickSync :).

As a side note, I believe the Core ixxxx -K series (overclock enabled) had their iGPU disabled / removed, right? Or was that one a certain model? Also a lot of Xeon cpu's out there without iGPU's and thus without QuickSync. Fancy dual-socket workstation boards that can't have QuickSync to do a quick render.. but then again, people like that often have external GPUs who can do (sort of) what QuickSync can.

edit: On my recent ffmpeg builds I don't see 'h264_nvenc' anymore in the decoder list? Only in the encoders.
I see 'h264', 'h264_qsv' and 'h264_cuvid' (the last being nvidia related). So is 'h264_nvenc' as a decoder even supposed to work at all?

[Selur]

@stax76: Are you sure it works for you?
Over here I got the same CPU usage when I use any of the following:
LWLibavVideoSource("H:\1080p60_AVC_SAMPLE.ts",cache=false,stacked=true,format="YUV420P8", decoder="h264_nvenc",repeat=true)
LWLibavVideoSource("H:\1080p60_AVC_SAMPLE.ts",cache=false,stacked=true,format="YUV420P8", decoder="h264_qsvenc",repeat=true)
LWLibavVideoSource("H:\1080p60_AVC_SAMPLE.ts",cache=false,stacked=true,format="YUV420P8",repeat=true)
and I one have a Geforce GTX 980 Ti as graphic card in my system. (I benchmarked the calls using AVSMeter)


Cu Selur

Ps.: I did the same thing quite a while back and never added it in Hybrid since back then I got the result: no noticeable difference.

As a side note, I believe the Core ixxxx -K series (overclock enabled) had their iGPU disabled / removed, right
My old i7-4770k worked fine with it's iGPU.

On my recent ffmpeg builds I don't see 'h264_nvenc' anymore in the decoder list?
I think they never were listed under decoder, but under 'hwaccel' (https://www.ffmpeg.org/ffmpeg-all.html).
'ffmpeg -hwaccels' should list the supported hardware acceleration methods supported by the used ffmpeg version. (for me it's dxva2 and cuvid)

[stax76]

70% CPU usage according to avsmeter using a 4k hevc sample. :(

[raffriff42]

70% CPU usage according to avsmeter using a 4k hevc sample. :(

This might be why:https://ffmpeg.org/ffmpeg-all.htmlNote that most acceleration methods are intended for playback and will not be faster than software decoding on modern CPUs.
Additionally, ffmpeg will usually need to copy the decoded frames from the GPU memory into the system memory, resulting in further performance loss.
This option is thus mainly useful for testing.

[dipje]

although you must not look at the cpu usage for stuff like that (because a lot of it might just be 'waiting for response from gpu' in which time other filters might happily run) it's a bit hit or miss here as well.

'h264' vs 'h264_cuvid' on my gtx1060, pure decoding of 1920x1080 h264 4:2:0 8bit, vapoursynth benchmark -> +/- 125fps vs 190fps. If I resample the file to 4:4:4: 16bit, then run f3kdb on it with a 'dither down back to 10bit' I get 35.2fps vs 39.8 fps. So a boost, but a small one.

Then, a 1920x1080 HEVC 4:2:2 10bit file, 'hevc' vs 'h265_cuvid'. Software decoding reaches 19.7 fps, then if I switch to 'hevc_cuvid' I get around 4.5 fps... which keeps on dropping bit by bit till it goes less than 1 fps then Vapoursynth crashes. So something is not right there :P. (LAVFilters refuses to use cuvid for the same file btw, so who knows they know it shouldn't work at all?)

[sneaker_ger]

NVDECODE 10 bit needs the not yet released Video Codec SDK 8.0.

(Or has it been (https://developer.nvidia.com/designworks/video_codec_sdk/downloads/v8.0)?)

[stax76]

for me it's dxva2 and cuvid

dxva2 and qsv for me

OS : Windows 10 Pro
CPU : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
GPU : NVIDIA GeForce GTX 1060 6GB, Intel(R) HD Graphics 530

[poisondeathray]

"h264_cuvid" works for me, much lower CPU usage, and it translates to faster actual encoding (tested with no filters, just decoding/encoding).

But issues with frames out of order, stuck frames (duplicates), etc.. ie. unreliable. I have similar experiences with full GPU encode/decode with ffmpeg or rigaya's nvencc also - the issue is the decoding part for all of them - because replacing with sw decoding works. lsmash "h264_cuvid" seems completely unreliable in terms of 1:1 frame consistency. It doesn't matter if threads=1 or indexed.

Even DirectShowSource() with a configured GPU decoder through lav or .grf is more reliable. That is saying a lot (!)

I couldn't get "h264_qsv" to work, it looks like software decoding speed and cpu usage (it even shows correct frames :) ). This was on r929 from the_weirdo

[B.F.]

Is there any way to get fpsnum/fpsden commands working?
No matter what I tryed, this settings just ignored.

[sneaker_ger]

It should "just work". Post a sample of your source and your complete script.

[B.F.]

https://www.dropbox.com/s/pigfbxmkaegc0ew/321.mkv?dl=0
LWLibavVideoSource("321.mkv", fpsnum = 24000, fpsden = 1001)
It works on other source files, but not on this one.

[poisondeathray]

https://www.dropbox.com/s/pigfbxmkaegc0ew/321.mkv?dl=0
LWLibavVideoSource("321.mkv", fpsnum = 24000, fpsden = 1001)
It works on other source files, but not on this one.

interesting that fpsnum , fpsden work with ffms2 but not lsmash on that one

[sneaker_ger]

Mkvextract says first video timecode at 10003ms, no audio timecodes. I'd say the file can be considered broken. If you created it yourself I'd open a ticket on the respective bug tracker (ffmpeg?).

[B.F.]

No, thats not my file, thats small piece of one of the files I need to encode.
And there is a lot of files like that in the internets.
And if ffms2 works on that one, L-SMASH should work too.

[poisondeathray]

Several lsmash versions (I didn't check very old versions), both avisynth and vpy, crash when opening ULRG (UT Video Codec RGB24), but ffms2 is able to open no problems . I know there are differences between original VFW and ffmpeg/libav versions in terms of decoders, but not sure about encoder. Eitherway, it doesn't matter if it was written by the ffmpeg/libav implementation, or with the VFW version they all induce crash

EDIT: probably don't need a sample but just in case


colorbars()
Trim(0,1)
showframenumber()
converttorgb24()


Both ffmpeg and vfw encoder versions included
https://www.mediafire.com/?914801rwjq07k22

[Groucho2004]

Several lsmash versions (I didn't check very old versions), both avisynth and vpy, crash when opening ULRG (UT Video Codec RGB24), but ffms2 is able to open no problems .
AVISource() also has no problems with this. I always use it for UTVideo.

[poisondeathray]

AVISource() also has no problems with this. I always use it for UTVideo.

Same here, the VFW version has the fastest decoder > libavcodec version . The later is about 2/3 speed and apparently doesn't have all the optimizations yet . But that doesn't help , say linux or mac users using vpy . But if ffms2 can do it, lsmash should be able to I woudl think

[speedyrazor]

I have been using LibavSMASHSource in VapourSynth 64 for a while, very successfully. I am now trying to use this on the below XDCAM HD 422 file, but I get an error, any suggestions please:

General
Complete name : M:\797.mov
Format : QuickTime
Format/Info : Original Apple specifications
Commercial name : XDCAM HD422
File size : 22.8 GiB
Duration : 59 min 0 s
Overall bit rate : 55.4 Mb/s
Encoded date : UTC 2014-02-15 02:48:42
Tagged date : UTC 2014-02-15 02:48:42
Writing application : Omneon OmMedia.dll 6.4.0.5 02-27-2012 18:28:44,ex={0,-1},rng={0,-1,0},trimAu,exPre

Video
ID : 1
Format : MPEG Video
Commercial name : XDCAM HD422
Format version : Version 2
Format profile : 4:2:2@High
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Format settings, picture structure : Frame
Codec ID : xd5c
Duration : 59 min 0 s
Bit rate mode : Constant
Bit rate : 50.0 Mb/s
Width : 1 920 pixels
Clean aperture width : 1 888 pixels
Height : 1 080 pixels
Clean aperture height : 1 062 pixels
Display aspect ratio : 16:9
Clean aperture display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.965
Time code of first frame : 00:00:00:00
GOP, Open/Closed : Closed
Stream size : 20.6 GiB (90%)
Language : English
Encoded date : UTC 2014-02-15 03:30:44
Tagged date : UTC 2014-02-15 03:30:44
Source :

Audio #1
ID : 2
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Muxing mode : Wave
Codec ID : sowt / 1
Duration : 59 min 0 s
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 648 MiB (3%)
Language : English
Encoded date : UTC 2014-02-15 03:30:44
Tagged date : UTC 2014-02-15 03:30:44
Source :

Audio #2
ID : 3
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Muxing mode : Wave
Codec ID : sowt / 1
Duration : 59 min 0 s
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 648 MiB (3%)
Language : English
Encoded date : UTC 2014-02-15 03:30:44
Tagged date : UTC 2014-02-15 03:30:44
Source :

Audio #3
ID : 4
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Muxing mode : Wave
Codec ID : in24 / 1
Duration : 59 min 0 s
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 972 MiB (4%)
Language : English
Encoded date : UTC 2014-02-15 03:30:44
Tagged date : UTC 2014-02-15 03:30:44
Source :

Other
ID : 5
Type : Time code
Format : QuickTime TC
Duration : 59 min 0 s
Time code of first frame : 00:00:00:00
Time code, striped : Yes
Language : English
Encoded date : UTC 2014-02-15 03:30:44
Tagged date : UTC 2014-02-15 03:30:44

[poisondeathray]

I have been using LibavSMASHSource in VapourSynth 64 for a while, very successfully. I am now trying to use this on the below XDCAM HD 422 file, but I get an error, any suggestions please:


What error specifically ? Was there an message ?

I noticed the MOV container; XDCAM HD422 in MXF container works ok in 64bit vpy with lsmash - could it be container related issue ? Maybe try re-wrapping it

[StainlessS]

SpeedyRazor,
I have been using LibavSMASHSource
Would you like to clarify, LSMASHVideoSource or LWLibavVideoSource.

[poisondeathray]

SpeedyRazor,

Would you like to clarify, LSMASHVideoSource or LWLibavVideoSource.

vapoursynth version is slightly different than avisynth version

LibavSMASHSource, and LWLibavSource

[StainlessS]

A rose by any other name would smell as sweat.

Thanx PDR, was not expecting that. :)