L-SMASH Source

[LigH]

Interesting, indeed... how did you create the MKV containing MagicYUV video? Is it a "legacy MKV" containing a VfW compatible video stream identified by its FourCC (like VirtualDubMod used to create)? I believe mkvinfo will tell some details.

In this case, I wonder if one software tries to pass the content on to a VfW codec if it doesn't contain an own decoder, while the other doesn't? ... Hmm. Too late to think about it deeply.

[hello_hello]

Interesting, indeed... how did you create the MKV containing MagicYUV video? Is it a "legacy MKV" containing a VfW compatible video stream identified by its FourCC (like VirtualDubMod used to create)? I believe mkvinfo will tell some details.

It was originally a small AVI I re-encoded to a lossless AVI with VirtualDubMod, then remuxed with MKVMergeGUI.

|+ Segment tracks
| + A track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 13307746977031899292
| + Track type: video
| + Lacing flag: 0
| + Codec ID: V_MS/VFW/FOURCC
| + CodecPrivate, length 72 (FourCC: 0x4d414759 »MAGY«)
| + Default duration: 40.000ms (25.000 frames/fields per second for a video track)
| + Language: und
| + Video track
| + Pixel width: 704
| + Pixel height: 384
| + Display width: 704
| + Display height: 384


In this case, I wonder if one software tries to pass the content on to a VfW codec if it doesn't contain an own decoder, while the other doesn't? ... Hmm. Too late to think about it deeply.

Both ffms2 and L-Smash will open the video in the script creator preview, but for some reason with ffms2 it opens directly after indexing, while for L-Smash I need to re-open the video by loading the index file into the script creator as the source file. That's as far as it gets. Both produce a "can't find the video" error if the script is saved and loaded for encoding.

I discovered the same thing also happens if I try to open the MagicYUV AVI. It's no big deal because the script's not encode-able. I was just curious as whether there's a logical explanation.

General
Complete name : E:\test.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 598 MiB
Duration : 3mn 49s
Overall bit rate : 21.8 Mbps
Writing application : VirtualDubMod 1.5.10.2 (build 2540/release)
Writing library : VirtualDubMod build 2540/release

Video
ID : 0
Format : MAGY
Codec ID : MAGY
Duration : 3mn 49s
Bit rate : 21.7 Mbps
Width : 704 pixels
Height : 384 pixels
Display aspect ratio : 1.85:1
Frame rate : 25.000 fps
Bits/(Pixel*Frame) : 3.205
Stream size : 594 MiB (99%)

[kuchikirukia]

Is LSMASH supposed to be continually creating and destroying MSVCR threads?

I seem to be getting a weird grey color flash at the beginning of one of my encodes when using L-Smash and MVTools2. It doesn't seem to happen when using FFMS2.

I'm getting it (along with green) with QTGMC, and in the middle.
But FFMS2 is giving me gray all over the place just as a source filter.

http://www.fast-files.com/getfile.aspx?file=97185
LSMASH + QTGMC:
http://www.fast-files.com/getfile.aspx?file=97186

E1: Oh, it's not the combination with QTGMC. It does it without.
Trying the m2ts instead of the eac3to- and MakeMKV- made mkvs.
E2: Er, maybe not without. I just noticed the LWI for my remuxed mkv was 70MB (where I was seeing green with LSMASH alone) when it was 170MB before. I think I have my mkvmerge set up to strip the frame rate info from the video stream and so that may be my fault.
E3: Ok, as a source filter from the M2TS I'm not seeing any green. (and now it has a 380MB LWI file!)

[kuchikirukia]

Yup... oddest thing. If I start this encode at the beginning of the source, LSMASH starts to destroy and create threads. Even single-threaded it doesn't work right. I get 1.4FPS in AVSMeter, but 0.67FPS while encoding while well under 100% CPU util, and it's like Christmas in Process Explorer with MSVCR120 threads flashing red and green from 20 frames in.
I start at 1000 frames and it's going at 1.15 fps and rising. Worker 2 which I started at 200000 frames has been going solidly at 1.18FPS.
And it's not something that works itself out. I was 5600 frames in at 0.67fps before I decided to try to figure out why Worker 1 was half speed.

If someone will tell me how to cut a m2ts I'll give you a sample.

[LigH]

MPEG-2 video only (usually SD resolution): ProjectX. In general: Cypheros TS-Doctor.

[kuchikirukia]

Here it is cut with Avidemux.
http://www.fast-files.com/getfile.aspx?file=97207

Isn't it supposed to start on an I-frame?

TS-Doctor says raw packet copy exception error.

[Groucho2004]

Here it is cut with Avidemux.
http://www.fast-files.com/getfile.aspx?file=97207Worst file host ever. It would take hours to dl that file from there. They can't even spell Terabytes.

Use sendspace or dropbox.

Also, AVI is a very bad idea, Avidemux allows you to mux to TS and cut on I-frames.

[LigH]

If you want the result to start playing without garbage, you better have it start with an I-frame, indeed. Respect the GOPs.

A possible short-time host may also be "wikisend"; they usually expire after a week.

[kuchikirukia]

Here:
http://s000.tinyupload.com/?file_id=25858289883852891004

[Music Fan]

I believe tSMuxer is better to cut ts, m2ts, mp4, mov ... it cuts only on keyframe because there is no encoder. I guess it cuts on the closest keyframe of the specified timecode.
And it works well, I often use it.

[AMED]

I take it that my problem HERE (http://forum.doom9.org/showthread.php?p=1726225#post1726225) is a problem with the source file and not L-SMASH?

[foxyshadis]

I seem to be getting a weird grey color flash at the beginning of one of my encodes when using L-Smash and MVTools2. It doesn't seem to happen when using FFMS2.

# Set DAR in encoder to 16 : 9. The following line is for automatic signalling
global MeGUI_darx = 16
global MeGUI_dary = 9
LoadPlugin("D:\MEGUI\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("H:\Above The Law (1988) (1)-001.mkv")
#crop
super = MSuper(pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)

It only seems to occur when using MDegrain 2 or 3.

I've tested with Avisynth (2.6final), Avisynth+ (r1825), MVTool2 (v2.6.0.5) and L-Smash works (v785).

SAMPLE (http://www.mediafire.com/download/wsukekelrw1ag4r/Above_The_Law.zip)

AviDemux and L-Smash can't seek in the VC-1 stream correctly; if they try to skip frames it comes out grey or a full error. Didn't test ffms2, but I have a feeling it depends on whether libav or ffmpeg was used to build the filter. It looks like the ones that can't seek properly are built with ffmpeg. This is a pretty good test case.

Either that, or you just got lucky and ffms2 never used enough cache memory to cause a seek. If MDegrain2 is ALL you use, you should bump the memory up with SetMemoryMax(1024) or more.

Note SMDegrain is a great option instead of MDegrain2. Alternately, KNLMeans is much faster and won't cause grey frames if you have decent graphics.

[AMED]

Thanks for your assistance foxyshadis.

I'm currently using SMDegrain with prefilter 3 (Dfttest) which is a little bit faster than prefilter 4 (KNLMeans) on my system (ATI 6950).

[kuchikirukia]

Here we go again:
http://s27.postimg.org/y8iittekv/Untitled.jpg (http://postimg.org/image/y8iittekv/)

LSMASH and QTGMC don't seem to play well together.

[mini-moose]

I noticed megui now has r785(20150802) on updates.

I can't find any infos as to how it's different from the older 785. Anyone knows? Maybe my search skills are not great :)

[LigH]

Not sure; possibly just the same sources compiled with a different compiler or slightly different options (to make it more compatible or require less different runtime libraries).

[mini-moose]

Not sure; possibly just the same sources compiled with a different compiler or slightly different options (to make it more compatible or require less different runtime libraries).

ok, thanks. Maybe I'll inquire on megui thread too.

[fvisagie]

When decoding FFV1 generated by ffmpeg, LWLibavVideoSource() reports the correct number of frames, but the clip is shifted earlier by one frame. The first frame is lost and an additional frame is added towards the end. What is actually displayed towards the end depends on scrolling: sometimes a green frame is added at the end, sometimes the actual last frame appears twice in succession, sometimes the actual penultimate frame appears twice in succession. Scrolling backwards and forwards may cause any of the last three frames to display differently from before.

Other applications like MPC-HC and ffplay open the FFV1 clips correctly.

Results are the same for clips encoded with the latest ffmpeg version (with FFV1 version 3.4), and with an older 2013 version (with an FFV1 version reported by ffprobe as 0). L-SMASH-Works_r708-gc7cc104 is used.

Some examples below.

clip.avs:
fps = 25
length = 2*500
AudioDub(BlankClip(length=fps*length, width=1280, height=720, pixel_type="YV12", fps=25.0), Tone(length=length)).ShowFrameNumber()

ffmpeg:
>ffmpeg -y -i clip.avs -c:v ffv1 -c:a copy clip.avi
ffmpeg version N-75275-gd13a2df Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.3 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-l
ibilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --en
able-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --ena
ble-decklink --enable-zlib
libavutil 55. 2.100 / 55. 2.100
libavcodec 57. 1.100 / 57. 1.100
libavformat 57. 0.100 / 57. 0.100
libavdevice 57. 0.100 / 57. 0.100
libavfilter 6. 3.100 / 6. 3.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.100 / 2. 0.100
libpostproc 54. 0.100 / 54. 0.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'clip.avs':
Duration: 00:16:40.00, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1280x720, 25 fps, 25 tbr, 25 tbn, 25 tbc
Stream #0:1: Audio: pcm_f32le, 48000 Hz, 2 channels, flt, 3072 kb/s
Output #0, avi, to 'clip.avi':
Metadata:
ISFT : Lavf57.0.100
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv420p, 1280x720, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc57.1.100 ffv1
Stream #0:1: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 48000 Hz, stereo, 3072 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=25000 fps= 40 q=-0.0 Lsize= 1140802kB time=00:16:40.00 bitrate=9345.4kbits/s
video:764277kB audio:375000kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.133785%

LWLibavVideoSource() correctly reports a total of 25000 frames. The first frame displayed is frame 00001, and the last three frames display as described above.

clip.avs:
fps = 25
length = 2
AudioDub(BlankClip(length=fps*length, width=1280, height=720, pixel_type="YV12", fps=25.0), Tone(length=length)).ShowFrameNumber()

ffmpeg:
>ffmpeg -y -i clip.avs -c:v ffv1 -c:a copy clip.avi
ffmpeg version N-75275-gd13a2df Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.3 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-l
ibilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --en
able-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --ena
ble-decklink --enable-zlib
libavutil 55. 2.100 / 55. 2.100
libavcodec 57. 1.100 / 57. 1.100
libavformat 57. 0.100 / 57. 0.100
libavdevice 57. 0.100 / 57. 0.100
libavfilter 6. 3.100 / 6. 3.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.100 / 2. 0.100
libpostproc 54. 0.100 / 54. 0.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'clip.avs':
Duration: 00:00:02.00, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1280x720, 25 fps, 25 tbr, 25 tbn, 25 tbc
Stream #0:1: Audio: pcm_f32le, 48000 Hz, 2 channels, flt, 3072 kb/s
Output #0, avi, to 'clip.avi':
Metadata:
ISFT : Lavf57.0.100
Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv420p, 1280x720, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc57.1.100 ffv1
Stream #0:1: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 48000 Hz, stereo, 3072 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> ffv1 (native))
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 50 fps= 40 q=-0.0 Lsize= 2312kB time=00:00:02.00 bitrate=9469.0kbits/s
video:1550kB audio:750kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.526660%

LWLibavVideoSource() correctly reports a total of 50 frames. The first frame displayed is frame 00001, and the last three frames display as described above.

[poisondeathray]

@fvisagie - I can reproduce the issue with LWLibavVideoSource . Deleting the index and using threads=1 "fixes" it for a workaround

[Reel.Deel]

VFR-maniac hasn't been around since March so it's probably best to submit an issue on GitHub (https://github.com/VFR-maniac/L-SMASH-Works/issues).

[fvisagie]

Wow, that's just fantastic :). Thanks for the quick confirmation and work-around.

[fvisagie]

VFR-maniac hasn't been around since March so it's probably best to submit an issue on GitHub (https://github.com/VFR-maniac/L-SMASH-Works/issues).

Will do, thank you.

EDIT: Reported as FFV1 clips are shifted earlier by one frame (https://github.com/VFR-maniac/L-SMASH-Works/issues/39), thanks.

[MonoS]

since a couple of months i'm encountering a bug into lsmash using vapoursynth for m2ts and m2ts muxed in mkv, i tried a lot to reproduce this issues but is impossible, it's random AFAIK.

It happens using lsmash and mdegrain [tried with tr=2] together [only lsmash or using another source filter don't seems to cause the problem] and consist of wrong decoding sequences or duplicated frames [for example ABDCE... or ABBDE...].

I've tried setting threads to 1 thinking it was a race condition but without success.

As i stated, i cannot offer a raw sample because it's random and usually appear on the middle of the encode [even cutting the precise scene in which this happens i was unable to reproduce this].

This is the most i can give you http://www.mediafire.com/watch/2mg9wec9616kvjj/test_lsmash.mkv

[fvisagie]

EDIT: Reported as FFV1 clips are shifted earlier by one frame (https://github.com/VFR-maniac/L-SMASH-Works/issues/39), thanks.

From https://github.com/VFR-maniac/L-SMASH-Works/issues/39#issuecomment-143314643:
Should be fixed at aa12725 (https://github.com/VFR-maniac/L-SMASH-Works/commit/aa127250538b70eb70209f070ca680619eb8b6cd) .

Thanks, VFR-maniac.

[LigH]

Could someone dare you to make the indexer support 1 GB VOB segments continuously, provided they only contain one PGC and one angle, e.g. from a "shrinked" DVD?

[MysteryX]

I tried LWLibavVideoSource with stacked=true on 10-bit videos. It appears the upper and lower halves of the Stack16 video are reversed.

[Reel.Deel]

Try setting the format parameter, for example, if it's 10-bit YV12 then set it to "YUV420P10". If that doesn't work then upload a test sample that shows the problem.

[MysteryX]

That doesn't help. Here's the video frame before calling DitherPost. The video should be in the upper half.

http://s20.postimg.org/6896kgrmh/10bitsource.jpg (http://postimg.org/image/6896kgrmh/)

[the_weirdo]

Try setting the format parameter, for example, if it's 10-bit YV12 then set it to "YUV420P10". If that doesn't work then upload a test sample that shows the problem.

Actually, you should set format parameter to "YUV420P16" (assume that input is 10-bit YV12) if you want to use Stack16 format (accompanied with stacked=true, of course). "YUV420P10" is output format chosen automatically by LWLibavVideoSource for 10-bit YV12 source, which may be MysteryX's problem.

[Reel.Deel]

Actually, you should set format parameter to "YUV420P16" (assume that input is 10-bit YV12) if you want to use Stack16 format (accompanied with stacked=true, of course). "YUV420P10" is output format chosen automatically by LWLibavVideoSource for 10-bit YV12 source, which may be MysteryX's problem.

Indeed, I totally forgot about that.

[feisty2]

or "YUV420P10" + mt_lut ("x 64 *")

[AzraelNewtype]

or "YUV420P10" + mt_lut ("x 64 *")

If anyone's curious, you need to set u and v to 3 for this to work, as the results otherwise are... interesting. This does solve an automation issue I had though, even if it was mostly borne of the way I scripted the automation.

[MysteryX]

I just tried the latest version of LSMASH available here, which is a series of dynamically linked files
https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0

I use LWLibavVideoSource and tried to open a VP9 video and it failed. I tried the version in the "With-libav" folder and it worked but the playback was too slow.

The version of LSMASH I currently have is a single file of 12.5mb, it works to read that file and pretty much any formats, and it doesn't lag. I don't even know where to download that version anymore, nor what version it was.

It is unfortunate that the latest version doesn't have the same features. Having it as a single DLL also makes it more convenient to deploy.

[StainlessS]

MX, dont know where that version originates, but if you have MeGUI installed, then can get it from in there.
I have both Stable MeGUI and Development MeGUI installed, just tested before posting, and both have just recently been updated.
Stable has had LSmash update, Development, a little while ago.
NOTE, MeGUI packages disable themselves if not used for X number of days, so may need to be enabled in Update (right click).
MeGUI devs do an amount of testing before inclusion, and so is probably as good a source as any for the dll's. (single LSMash dll, but also
CPP runtimes dll if not already installed on system).

EDIT:
It is unfortunate that the latest version doesn't have the same features

No idea what those features might be, but perhaps thats why the dll's are 'in bits', you may need to wait until stable.

[Zathor]

MeGUI uses the DLLs from the same source. So do not expect any updates in MeGUI with a "single DLL". I am also curious why there are now these dynamically linked DLLs. This causes problems as MeGUI cannot load this plugin anymore without copying the other DLLs to the root directory of MeGUI. I have to check if maybe LoadDLL (not loadplugin) of the other DLLs can help.

[the_weirdo]

@MysteryX
Try the latest version. I messed up some build config for the 32-bit version.

The reason of those FFmpeg's DLLs in recent builds of L-SMASH Works AviSynth plugin is that I've recently switched to Visual Studio 2015 and the minGW-w64 libs currently are not compatible with it, thus it failed to link LSMASHSource against FFmpeg's static libs (which were built using minGW-w64 GCC). So I have to build them as DLLs and dynamically linked LSMASHSource against them. You just need to put them in the same directory as LSMASHSource.dll to make it work. It's a bit inconvenient than before, indeed. The upside of this is that now I can statically link LSMASHSource against MSVCRT (so you don't have to install VC 2015 redist to use it; dynamically linking against MSVCRT is the recommended way, though), and also can link it against FFmpeg libs with libmfx support.

[MysteryX]

As this is part of a setup package, I'm trying to minimize the size of files being redistributed. If I use this and the dynamically-linked FFMPEG version, can both share the same DLL?

[the_weirdo]

If I use this and the dynamically-linked FFMPEG version, can both share the same DLL?

As long as the DLLs are API compatible, I think LSMASHSource.dll should work with other FFmpeg shared builds (as I'm no programmer, I'm not really experienced in this area). I just tested with Zeranoe's builds and it seemed to work fine. However, note that L-SMASHSource requires libavresample which is not included in Zeranoe's builds. You can still use avresample-*.dll from my builds. I'm not sure if related functions (audio processing) would work properly, though.

[sneaker_ger]

I still get a "Module not found" error message, even with yesterday's binary. (Win 7 x64, AviSynth 2.6.0 32)

[LigH]

Did you install the MS VS 2015 runtime?

... I've recently switched to Visual Studio 2015 ...

[sneaker_ger]

I do, but:
The upside of this is that now I can statically link LSMASHSource against MSVCRT (so you don't have to install VC 2015 redist to use it

[MysteryX]

I won't share the DLL with FFMPEG for the simple reason that I use FFMPEG x64 and L-MASH x32. Plus your avcodec-57.dll takes 10MB while theirs takes 26MB.

I'll wait for a newer static DLL to come out.

[the_weirdo]

I do, but:

Hmm... I thought it would work without MSCRT being installed, but it seems I'm still missing something.

EDIT: After some reading, I have settled that I will dynamically link the plugin against CRT again. Statically linking the CRT into DLL may cause various problems and not worth the trouble anyway.

I won't share the DLL with FFMPEG for the simple reason that I use FFMPEG x64 and L-MASH x32. Plus your avcodec-57.dll takes 10MB while theirs takes 26MB.

I'll wait for a newer static DLL to come out.

I made a special build (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0) of the AviSynth plugin that is static. However, because FFmpeg libs were built using MSVC, their performances are often slower than GCC builds (you can read about the reason here (http://siliconandlithium.blogspot.com/2013/12/building-ffmpeg-on-windows-with-in-line.html)). Also it doesn't have some external libs (libdcadec, libspeex, libmfx) and may be missing some features from the GCC builds.

[jpsdr]

Until now, i compiled L-SMASH and L-SMASH work with VS2013 using the tutorial from here (https://github.com/BrunoReX/build-scripts/blob/master/L-SMASH/readme.md).

Now i have VS2015 Update 1, all the steps are still working, except the final, when i try to build the project with VS. Compile (not even link) fails, with several error messages like "unknow type", "impossible to convert from X to Y" and like.
Is there something more/else i have to do to make it work, or is it just impossible to build with VS2015 ?

[MysteryX]

LWLibavVideoSource is working for most video sources, but sometimes I get audio and video out of sync.

This video in WebM format, for example, doesn't synchronize.
https://www.youtube.com/watch?v=zIRRGKMLaJE

Anything can be done about it?

Edit: The previous version of the DLL synchronizes it just fine.

[sneaker_ger]

I don't see anything wrong with the youtube video using "LSMASHSource-AviSynth-plugin-r859-static-32bit".

Be more precise in the future. What lsmash version exactly, what is your script, where do you see the desync, is the desync constant or progressive, and upload a sample to a file host because youtube has many streams to offer (we don't want to guess).

[MysteryX]

I tried it again, this time making sure SVP is disabled. It was definitely out of sync. Here's the video
https://mega.nz/#!eMo13YTR!7qfuUSbg4pQFdmu63Wjy9z7OwQvKJvG5-d1MDfqzrCg

This is my script


P="Encoder\"
LoadPlugin(P+"TimeStretch.dll")
Import(P+"UUSize4.avsi")
SetMTMode(3,4)
LoadPlugin(P+"LSMASHSource.dll")
file="Input.mkv"
LWLibavVideoSource(file, cache=false, threads=2)
AudioDub(LWLibavAudioSource(file, cache=false))
SetMTMode(2)
UUSize4(mod=4)
ResampleAudio(48000)
TimeStretchPlugin(pitch = 100.0 * 0.98181819915771484)

[jpsdr]

When i try to build with VS2015...

Any idea :confused:


1>------ Début de la génération*: Projet*: LSMASHSource, Configuration*: Release Win32 ------
1> audio_output.c
1> qsv.c
1> audio_output.cpp
1> exlibs.cpp
1> libavsmash.c
1>..\common\libavsmash.c(191): error C3688: suffixe littéral non valide 'PRIu32'; opérateur littéral ou modèle d'opérateur littéral 'operator ""PRIu32' introuvable
1> libavsmash_audio.c
1> libavsmash_source.cpp
1> libavsmash_video.c
1>..\common\libavsmash_video.c(581): error C3688: suffixe littéral non valide 'PRIu32'; opérateur littéral ou modèle d'opérateur littéral 'operator ""PRIu32' introuvable
1>..\common\libavsmash_video.c(581): error C2664: 'void lw_log_show(lw_log_handler_t *,lw_log_level,const char *,...)'*: impossible de convertir l'argument 3 de 'uint32_t' en 'const char *'
1> ..\common\libavsmash_video.c(581): note: La conversion d'un type intégral en type pointeur nécessite reinterpret_cast, un cast de style C ou un cast de style fonction
1>..\common\libavsmash_video.c(618): warning C4244: '='*: conversion de 'double' en 'uint32_t', perte possible de données
1> lsmashsource.cpp
1> lwindex.c
1>..\common\lwindex.c(381): warning C4244: '+='*: conversion de 'int64_t' en 'int', perte possible de données
1>..\common\lwindex.c(394): warning C4244: '+='*: conversion de 'int64_t' en 'int', perte possible de données
1>..\common\lwindex.c(795): error C3680: impossible de concaténer des littéraux de chaîne définis par l'utilisateur avec des identificateurs de suffixe littéral incompatibles
1> ..\common\lwindex.c(795): note: Concaténation du suffixe 'PRId64' avec le suffixe 'PRIu32'
1>..\common\lwindex.c(795): error C3688: suffixe littéral non valide 'PRId64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""PRId64' introuvable
1>..\common\lwindex.c(796): error C2664: 'void lw_log_show(lw_log_handler_t *,lw_log_level,const char *,...)'*: impossible de convertir l'argument 3 de 'int64_t' en 'const char *'
1> ..\common\lwindex.c(796): note: La conversion d'un type intégral en type pointeur nécessite reinterpret_cast, un cast de style C ou un cast de style fonction
1>..\common\lwindex.c(847): error C3680: impossible de concaténer des littéraux de chaîne définis par l'utilisateur avec des identificateurs de suffixe littéral incompatibles
1> ..\common\lwindex.c(847): note: Concaténation du suffixe 'PRId64' avec le suffixe 'PRIu32'
1>..\common\lwindex.c(847): error C3688: suffixe littéral non valide 'PRId64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""PRId64' introuvable
1>..\common\lwindex.c(848): error C2664: 'void lw_log_show(lw_log_handler_t *,lw_log_level,const char *,...)'*: impossible de convertir l'argument 3 de 'int64_t' en 'const char *'
1> ..\common\lwindex.c(848): note: La conversion d'un type intégral en type pointeur nécessite reinterpret_cast, un cast de style C ou un cast de style fonction
1>..\common\lwindex.c(1694): error C3688: suffixe littéral non valide 'PRId64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""PRId64' introuvable
1>..\common\lwindex.c(1695): error C2664: 'void print_index(FILE *,const char *,...)'*: impossible de convertir l'argument 2 de 'int64_t' en 'const char *'
1> ..\common\lwindex.c(1695): note: La conversion d'un type intégral en type pointeur nécessite reinterpret_cast, un cast de style C ou un cast de style fonction
1>..\common\lwindex.c(1723): error C3688: suffixe littéral non valide 'PRIx64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""PRIx64' introuvable
1>..\common\lwindex.c(1726): error C2664: 'int fprintf(FILE *const ,const char *const ,...)'*: impossible de convertir l'argument 2 de 'int' en 'const char *const '
1> ..\common\lwindex.c(1726): note: La conversion d'un type intégral en type pointeur nécessite reinterpret_cast, un cast de style C ou un cast de style fonction
1>..\common\lwindex.c(2063): error C3688: suffixe littéral non valide 'PRId64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""PRId64' introuvable
1>..\common\lwindex.c(2070): error C2664: 'void print_index(FILE *,const char *,...)'*: impossible de convertir l'argument 2 de 'int' en 'const char *'
1> ..\common\lwindex.c(2070): note: La conversion d'un type intégral en type pointeur nécessite reinterpret_cast, un cast de style C ou un cast de style fonction
1>..\common\lwindex.c(2166): error C3680: impossible de concaténer des littéraux de chaîne définis par l'utilisateur avec des identificateurs de suffixe littéral incompatibles
1> ..\common\lwindex.c(2166): note: Concaténation du suffixe 'PRId64' avec le suffixe 'PRIx64'
1>..\common\lwindex.c(2166): error C3688: suffixe littéral non valide 'PRId64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""PRId64' introuvable
1>..\common\lwindex.c(2172): error C2664: 'void print_index(FILE *,const char *,...)'*: impossible de convertir l'argument 2 de 'int' en 'const char *'
1> ..\common\lwindex.c(2172): note: La conversion d'un type intégral en type pointeur nécessite reinterpret_cast, un cast de style C ou un cast de style fonction
1>..\common\lwindex.c(2229): error C3688: suffixe littéral non valide 'PRId64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""PRId64' introuvable
1>..\common\lwindex.c(2233): error C2664: 'void print_index(FILE *,const char *,...)'*: impossible de convertir l'argument 2 de 'unsigned int' en 'const char *'
1> ..\common\lwindex.c(2233): note: La conversion d'un type intégral en type pointeur nécessite reinterpret_cast, un cast de style C ou un cast de style fonction
1>..\common\lwindex.c(2277): error C3688: suffixe littéral non valide 'PRId64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""PRId64' introuvable
1>..\common\lwindex.c(2278): error C2664: 'void print_index(FILE *,const char *,...)'*: impossible de convertir l'argument 2 de 'unsigned int' en 'const char *'
1> ..\common\lwindex.c(2278): note: La conversion d'un type intégral en type pointeur nécessite reinterpret_cast, un cast de style C ou un cast de style fonction
1>..\common\lwindex.c(2560): error C3688: suffixe littéral non valide 'SCNd64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""SCNd64' introuvable
1>..\common\lwindex.c(2561): error C2664: 'int sscanf(const char *const ,const char *const ,...)'*: impossible de convertir l'argument 2 de 'int *' en 'const char *const '
1> ..\common\lwindex.c(2561): note: Les types pointés n'ont aucun rapport entre eux*; conversion nécessitant reinterpret_cast, cast de style C ou cast de style fonction
1>..\common\lwindex.c(2672): error C3688: suffixe littéral non valide 'SCNx64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""SCNx64' introuvable
1>..\common\lwindex.c(2673): error C2664: 'int sscanf(const char *const ,const char *const ,...)'*: impossible de convertir l'argument 2 de 'int *' en 'const char *const '
1> ..\common\lwindex.c(2673): note: Les types pointés n'ont aucun rapport entre eux*; conversion nécessitant reinterpret_cast, cast de style C ou cast de style fonction
1>..\common\lwindex.c(2751): error C3688: suffixe littéral non valide 'SCNd64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""SCNd64' introuvable
1>..\common\lwindex.c(2751): error C2664: 'int sscanf(const char *const ,const char *const ,...)'*: impossible de convertir l'argument 2 de 'int *' en 'const char *const '
1> ..\common\lwindex.c(2751): note: Les types pointés n'ont aucun rapport entre eux*; conversion nécessitant reinterpret_cast, cast de style C ou cast de style fonction
1>..\common\lwindex.c(2781): error C3688: suffixe littéral non valide 'SCNd64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""SCNd64' introuvable
1>..\common\lwindex.c(2782): error C2664: 'int sscanf(const char *const ,const char *const ,...)'*: impossible de convertir l'argument 2 de 'int64_t *' en 'const char *const '
1> ..\common\lwindex.c(2782): note: Les types pointés n'ont aucun rapport entre eux*; conversion nécessitant reinterpret_cast, cast de style C ou cast de style fonction
1>..\common\lwindex.c(2802): error C3688: suffixe littéral non valide 'SCNd64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""SCNd64' introuvable
1>..\common\lwindex.c(2803): error C2664: 'int sscanf(const char *const ,const char *const ,...)'*: impossible de convertir l'argument 2 de 'int64_t *' en 'const char *const '
1> ..\common\lwindex.c(2803): note: Les types pointés n'ont aucun rapport entre eux*; conversion nécessitant reinterpret_cast, cast de style C ou cast de style fonction
1>..\common\lwindex.c(2861): error C3688: suffixe littéral non valide 'SCNx64'; opérateur littéral ou modèle d'opérateur littéral 'operator ""SCNx64' introuvable
1>..\common\lwindex.c(2864): error C2664: 'int sscanf(const char *const ,const char *const ,...)'*: impossible de convertir l'argument 2 de 'int *' en 'const char *const '
1> ..\common\lwindex.c(2864): note: Les types pointés n'ont aucun rapport entre eux*; conversion nécessitant reinterpret_cast, cast de style C ou cast de style fonction
1> lwlibav_audio.c
1> lwlibav_dec.c
1> lwlibav_source.cpp
1> lwlibav_video.c
1> lwsimd.c
1> resample.c
1> utils.c
1> video_output.cpp
========== Génération*: 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

[an3k]

I'm trying to get L-SMASH Works working with VapourSynth on Linux and because there is no documentation I'm not aware if I need L-SMASH too or just L-SMASH Works. Thanks

EDIT: What are the correct steps to build it on Linux? Do I just need to ./configure, make, make install inside the VapourSynth directory or are there other steps to do additionally or instead of?

[Are_]

Yes, you first need https://github.com/l-smash/l-smash and then you can build https://github.com/VFR-maniac/L-SMASH-Works

Just ./configure && make && make install will suffice, I'm not sure what you mean by "make install inside the VapourSynth directory" but I think it's difficult to go wrong with this.