L-SMASH Source

[Selur]

Since LSMASHSource came up in the FFmpegSource thread I thought it might be a good idea to have a separate thread for it. :)


the_weirdo's Dropbox repository contains up-to-date downloads: http://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0
and here's the Wiki: http://avisynth.nl/index.php/LSMASHSource

From what I gathered LSMASHSource.dll offers:
LSMASHVideoSource(string source, int "track", int "threads", int "seek_mode", int "seek_threshold", bool "dr")
LSMASHAudioSource(string source, int "track", bool "skip_priming", string "layout")
LWLibavVideoSource(string source, int "stream_index", int "threads", bool "cache", int "seek_mode", int "seek_threshold", bool "dr")
LWLibavAudioSource(string source, int "stream_index", bool "cache", bool "av_sync", string "layout")

see: LSMASHSource.txt that comes with the download

Does anyone know what the difference is between LSMASH..Source and LWLibav..Source source is?
LWLibavVideoSource is basically a FFmpegSource alternative, which can be used without an index file. (index file will be created if cache is set to true)
LSMASHVideoSource is a mp4 source filter.

Cu Selur

[StainlessS]

Seems to belong to or part of L-SMASH-Works by "VFR Maniac", see his sig here:
http://forum.doom9.org/showthread.php?p=1567834#post1567834

[radigast]

Are there any advantages to using LWLibavVideoSource over FFVideoSource?

[Selur]

No, clue. :D
For me so far:
advantages

can be used the need to index the content,... (especially indexing HD content takes it's time)

downsides:

has no separate indexing application (which would allow me to index all my content over night, without having to use Avisynth)


-> test and post if you find more pro's and con's

[the_weirdo]

advantages

can be used the need to index the content,... (especially indexing HD content takes it's time)


You mean "can be used *without* the need..." right? Then actually it *does* need to index the source. It just stores the index in memory when set "cache=false", same as with FFMS2.

EDIT: It seems it take less time than FFMS2 to create the index.
EDIT (after some more testing):
Its index file is much larger than FFMS2's.
In case of MKV and MP4 container, it seems frame accurate as FFMS2.
Not sure about other containers 'cause I don't have a reference, but in some of my test, it decodes MPEG-TS different from FFMS2.

[Selur]

It just stores the index in memory when set "cache=false", same as with FFMS2.
argh, seems you are right. :( Opening a large HD file still takes a long time,..

[TheFluff]

Its index file is much larger than FFMS2's.

FFMS2 compresses its index files with zlib, so that's not so strange.

I think lsmashsource might actually do MPEG TS/PS right. For other stuff there shouldn't be much of a difference between lshashsource and FFMS2.

[VFR maniac]

Its index file is much larger than FFMS2's.

I dislike compressed/encoded format.
Since people can't select which stream by looking the index file.
So, I write the index file as human-readable.

[the_weirdo]

FFMS2 compresses its index files with zlib, so that's not so strange.

Ah, that explains a lot.
I dislike compressed/encoded format.
Since people can't select which stream by looking the index file.
So, I write the index file as human-readable.
That's the good thing, then. Actually, the index file doesn't take up much disk space, anyway.

I hope L-SMASHSource will become a good MPEG-TS/PS source filter, too.

[VFR maniac]

CODEC specific data (extradata) is written in the index file as well.
This makes more accurate seek possible.

For instance, H.264 allows IDR-picture without SPS/PPS.
For such IDR-pictures in TS, we can't treat as keyframe (random access point) but libavfomrat returns them as keyframe.
So, the result will be broken when the current SPS/PPS in extradata doesn't match (and libavcodec shall not update AVCodecContext.extradata).
This case is frequently present in BD m2ts.
LWLibavVideoSource can handle correctly this case.

About WMV3/VC-1 in ASF, libavformat may not return any PTS even if there is B-picture.
LWLibavVideoSource attempts to generate PTS from DTS and picture type by actual __decoding__, and realizes frame accurate seek.
So, creating the index file is to be slow.

About MPEG-1/2 Video, libavformat might return no PTS for some frames in certain contaniers such as MPEG-PS.
LWLibavVideoSource attempts to generate PTS from DTS and picture type, and realizes frame accurate seek.

LWLibavVideoSource can handle audio stream of DV-in-AVI Type-I without crash.
This format requires seek by special treatment in libavformat.

[noee]

I have a source that I ripped from one of my BDs that is interlaced/TFF VC1 (1080i60) and I get an error: "Detected PTS duplication..." and LWLibavVideoSource(source="...", seek_mode=0) won't open the file. Expected behavior? Bad rip?

[radigast]

Does LWLibavVideoSource accurately index interlaced sources? Depending on the source/solar winds/price of tea in China/etc..., FFVideoSource sometimes will index interlaced sources properly and sometimes won't.

[Selur]

regarding indexing:
looking at the aui_indexer from rigaya, it is mainly a frontend for the lsmashinput.aui (library), sadly it does not offer any way to choose where the index will be created nor does it offer any progress indication during the indexing.
-> so if someone is in contact with rigaya and/or lsmashinput.aui would be nice if adding progress indication and the possibility could be passed on to them as 'feature requests/wishes'.

[VFR maniac]

I have a source that I ripped from one of my BDs that is interlaced/TFF VC1 (1080i60) and I get an error: "Detected PTS duplication..." and LWLibavVideoSource(source="...", seek_mode=0) won't open the file. Expected behavior? Bad rip?

I threw all warning to env->ThrowError().
Now (@ rev499), I don't throw them but don't display any warning and non-fatal error.
At least that message means the file is broken or libavformat TS demuxer is broken for the file, and means the seek may behave inaccurately.
Well, I killed that message from LSMASHSource.dll so you can't see that message anymore :P unless I add the error threshold option.

[VFR maniac]

Does LWLibavVideoSource accurately index interlaced sources? Depending on the source/solar winds/price of tea in China/etc..., FFVideoSource sometimes will index interlaced sources properly and sometimes won't.

For frames structured by single picture, I think LWLibavVideoSource can seek correctly as long as there is no PTS/DTS duplication and no error of frame info returned by libavformat.

For frames structured by two separated pictures, LWLibavVideoSource will return correct frame and broken frame by turns.
In this case, you can delete broken frames by SelectEven() or SelectOdd().

For progressive frames with pulldown/RFF flag, LWLibavVideoSource can't handle these flags.
There is the patches for that, but impossible to apply to the latest repository.
https://skydrive.live.com/?cid=8658EC275D9699D5&id=8658EC275D9699D5!236
https://github.com/maki-rxrz/L-SMASH-Works/tree/experimental_repeat_control

About whether the index is written accurately or inaccurately, All I can say is that it depends on libavformat!! :D


regarding indexing:
looking at the aui_indexer from rigaya, it is mainly a frontend for the lsmashinput.aui (library), sadly it does not offer any way to choose where the index will be created nor does it offer any progress indication during the indexing.
-> so if someone is in contact with rigaya and/or lsmashinput.aui would be nice if adding progress indication and the possibility could be passed on to them as 'feature requests/wishes'.

aui_indexer only hits the open function common to all L-SMASH Works input plugin through AviUtl API without AviUtl.
Progress indication is displayed by another dialog.

It can't specify any destination for the index file and the way of displaying progress as long as hitting through AviUtl API.

[burfadel]

Testing on some old avi files that work fine with FFMpegsource, LwLibAvSource has the couple of flashes of green frames at the beginning, which then throws the video/audio sync out for the rest of the video.

Also, how do you use LsmashVideoSource? Does that only work on raw files or is it meant to open the video streams of Avi, MKV, VOV etc as well?

[Selur]

LsmashVideoSource works with mp4 and mov input. (not sure which video formats it supports)

[VFR maniac]

Testing on some old avi files that work fine with FFMpegsource, LwLibAvSource has the couple of flashes of green frames at the beginning, which then throws the video/audio sync out for the rest of the video.

I don't know your old AVI files.

[sl1pkn07]

vapoursynth plugin for l-smash not compatible with linux?

http://paste.opensuse.org/60828889

[VFR maniac]

vapoursynth plugin for l-smash not compatible with linux?

http://paste.opensuse.org/75818329

I don't test the compilation on any linux environment.
I build on MinGW32 only.
Patches welcome if the compilation fails.

BTW as far as I look at your log, it seems your ffmpeg or libav is old.
I don't consider about backward compatibility for L-SMASH Works.

[sl1pkn07]

the version of ffmpeg is 1.1.3

[VFR maniac]

I think the current any ffmpeg Major Release doesn't help you.
The latest L-SMASH Works requires The Evil Plan.

[sl1pkn07]

the evil plan? xd

[VFR maniac]

The reference counter which is the new feature of ffmpeg/libav API is called The Evil Plan.

[sl1pkn07]

oh, ok, I thinking The Evil Plan is a internet meme XDD

[burfadel]

I don't know your old AVI files.

The new rev 501 doesn't exhibit this behaviour.

Out of curiosity, what number threads are used by default when none are specified, is it equal to the number of cores, a fixed value (such as 2 or 4), or is it just 1 by default?

[VFR maniac]

The number of cores + 1.
This is the default value libavcodec does.

The maximum value is 16.
According to libavcodec/pthread.c,
/* H264 slice threading seems to be buggy with more than 16 threads,
* limit the number of threads to 16 for automatic detection */

[qyot27]

What steps should be taken to get the AviSynth plugin built? Because my test builds only worked if I set it on Debug, not Release, and it was only the LWLibav..Source functions that output anything. LSMASH..Source caused Access Violations (which may be because I had the dependencies wrong, or something got screwed up in the .sln/.vcproj conversion*).

*I used VS2010, not VS2008. Unless it's actually caused more by the use of Express than which incremental version of Visual Studio it was.

[VFR maniac]

Oh... I didn't notice that.
On Release build, I also get a crash for audio source filter on AviUtl loading AVS.
I still don't get what causes that.

I'm using TDM GCC 4.7.1-dw2 (tdm-1) + MSVC9 Express Edition.

[qyot27]

Ah, perhaps it was in the GCC build then, as I was using Komisar's (among other things, it uses sjlj, not dw2).

[VFR maniac]

The crash goes away when I disable /GL on MSVC9.
I don't get still why. :(

[qyot27]

Ok, I did manage to get Release to generate a build that can use both LWLibav..Source and LSMASH..Source, but it may have been at the cost of making it much closer to a Debug build (and the file size reflects it: the normal 'Release' build was ~6 MB, and the normal 'Debug' build was ~9 MB...the adjusted Release build that works is 9.07MB). I'll have to do some more trial-and-error and see exactly which option(s) fixed it.

[qyot27]

Following up again, it seems that the offending option was /OPT:REF. Setting /OPT:NOREF makes Release builds work for me, even with /GL and /LTCG enabled. My guess is that /OPT:REF was pruning stuff out of the .dll that it shouldn't have (as that's what the documentation (http://msdn.microsoft.com/en-us/library/bxwfs976.aspx) makes it sound like it does), and therefore causing the crashes and Access Violations. The resultant build size is a more modest 7MB or so. Probably could be reduced further, since the FFmpeg build used wasn't the type of minimal compile I use for FFMS2 (I'd also neglected to enable avresample since I actually built it to verify whether it still wanted to crash with the new AviSynth demuxer when built with MSVC...thankfully, it works fine).

LSMASHSource r507 (http://www.mediafire.com/?8ebzb9yet3h8d4q)

It's been optimized for SSE. Built with VS2010.




Further notes on building:

MinGW-w64's supplied version of libmingwex.a has incompatibilities with MSVC
Use the non-w64 version of the tdm toolchain to build L-SMASH

Build FFmpeg with MSVC as roughly outlined here: http://ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b
One thing to note is that the c99-to-c89 wrapper should be version 1.0, not version 1.0.1 (unless you want to compile 1.0.1 yourself with Clang, I guess) - the distributed binaries of 1.0.1 have their permissions screwed up somehow and error out with 'Bad file number'. The 1.0 binaries are fine.

Both Debug and Release:
Remove libmingwex.lib from Source Files (select 'Remove' from LSMASHSource project)

Configuration Properties -> VC++ Directories
Add the GCC lib/includes, MinGW lib/includes, and in my case, locally-installed FFmpeg & L-SMASH lib/includes
Append the following directories to the end of their respective lists:
C:\MinGW\tdm-mingw\lib\gcc\mingw32\4.7.1\include
C:\MinGW\tdm-mingw\include
C:\MinGW\home\username\win32_build\include

C:\MinGW\tdm-mingw\lib\gcc\mingw32\4.7.1
C:\MinGW\tdm-mingw\lib
C:\MinGW\home\username\win32_build\lib

Configuration Properties -> Linker -> Input
Append the following .a files to the end of the list.
Additional Dependences: libmsvcr100.a;libmingwex.a;libmingw32.a;libws2_32.a;libwsock32.a

Ignore Specific Default Libraries: libcmt.lib


'Release' build specific:
Configuration Properties -> Linker -> Debugging
Generate Debug Info: No
(There's no point to the 'Release' build generating Debug info, IMO)

Configuration Properties -> Linker -> Optimization
References: No

[qyot27]

Partial support for building the VapourSynth plugin for Linux (maybe OSX, but that's completely untested here):
Fix permissions on configure (https://gist.github.com/qyot27/5229879)
Linux compilation support (https://gist.github.com/qyot27/5229885)

It just took some adjusting of configure and GNUmakefile; the shared object settings were derived from what the FFMS2 C-plugin does when compiling. 'Partial' because the install rules are still missing, but it does generate a valid .so that Linux-native VapourSynth can use. Windows use needs to be tested to make sure nothing broke, even though compilation still succeeds.


...and I just now realized I hadn't shifted the LDFLAGS section's if block from 'MINGW' to 'WIN32'.

[sl1pkn07]

thanks qyot27!

what version of ffmpeg/libav you use?

[qyot27]

I was using ffmpeg-git.

[Selur]

btw. does anyone know if 10 bit precision input support is planned, atm. (r561) High10 content throws
Avisynth open failure:
LWLibavVideoSource: yuv420p10le is not supported

[VFR maniac]

Partial support for building the VapourSynth plugin for Linux (maybe OSX, but that's completely untested here):
Linux compilation support (https://gist.github.com/qyot27/5229885)


Did anyone test this patch on OSX?


btw. does anyone know if 10 bit precision input support is planned, atm. (r561) High10 content throws

Avisynth open failure:
LWLibavVideoSource: yuv420p10le is not supported

I don't have any experience about high bit depth on AviSynth.
Patches welcome: Issue 15 (https://github.com/VFR-maniac/L-SMASH-Works/issues/15).
Use vslsmashsource.dll instead, for a while.

[qyot27]

Did anyone test this patch on OSX?
I just did, because I finally got around to getting VapourSynth set up on the OSX machine I have access to. It does build, and both LWLibavSource and LibavSMASHSource work as expected. However, due to the way that the output of git rev-list and wc is on OSX, the REV info needed to be fixed up a little by inserting sed into the command.

Revised patch here:
https://gist.github.com/qyot27/5439568

[VFR maniac]

OK. Applied.

Thanks for your contribution.

[sl1pkn07]

one little question (and maybe stupid) about vapoursynth plugin (in linux)

the library vslsmashsource.so call boxdumper/muxer/remuxer/timelineeditor for indexing/open videos? or can self handle without these executables

i want build this plugin with lsmash and ffmpeg form git into library (static linked)

[VFR maniac]

one little question (and maybe stupid) about vapoursynth plugin (in linux)

the library vslsmashsource.so call boxdumper/muxer/remuxer/timelineeditor for indexing/open videos? or can self handle without these executables

i want build this plugin with lsmash and ffmpeg form git into library (static linked)

boxdumper, muxer, remuxer and timelineeditor are L-SMASH App.
They have nothing to do with L-SMASH Works.
L-SMASH Works depends on liblsmash, libavutil, libavcodec, libavformat, libswscale and libavresample.

[sl1pkn07]

I thought the vapourshynt pluging (and l-smash lib) working like:

vapoursynth call vslsmashsource -> vslsmashsource call liblsmash -> liblsmash call l-smash aplications to handle videos -> liblsmash collect the info and send to vapoursynth through vslsmashsource

oks, tanks fot the aclaration. :)

[VFR maniac]

btw. does anyone know if 10 bit precision input support is planned, atm. (r561) High10 content throws

Avisynth open failure:
LWLibavVideoSource: yuv420p10le is not supported

I added supporting of a hack of high bit-depth input between rev594 and rev603.
For interleaved format (at default), only little endianness output is supported currently i.e. LSB comes at the first byte and MSB comes at the second.
Stacked format is also available but direct rendering is always not available if used.


By the way, does anyone have a PAFF H.264 sample?
I added supporting of H.264 field coded picture handling for LW-Libav part but I haven't tested on any sample containing both frame coded and field coded yet.
I only tested on samples containing field coded only.

[Selur]

using: L-SMASH-Works_r608 (extracted the LSMASHSource.dll and the msvcr100.dll into my test folder)
I called:
LoadPlugin("G:\Test\LSMASHSource.dll")
LSMASHVideoSource("F:\Testfiles\test2.mkv"))
when trying to open the script with Virtual Dub I get:
Avisynth open failure:
LSMASHVideoSource: failed to lsmash_open_movie.
(F:\Testfiles\test2.avs, line 2)
am I missing something? (uploaded the test2.mkv to http://www.embedupload.com/?d=1JUTIYWYCU)

Cu Selur

[VFR maniac]

using: L-SMASH-Works_r608 (extracted the LSMASHSource.dll and the msvcr100.dll into my test folder)
I called:
LoadPlugin("G:\Test\LSMASHSource.dll")
LSMASHVideoSource("F:\Testfiles\test2.mkv"))
when trying to open the script with Virtual Dub I get:

Avisynth open failure:
LSMASHVideoSource: failed to lsmash_open_movie.
(F:\Testfiles\test2.avs, line 2)

am I missing something? (uploaded the test2.mkv to http://www.embedupload.com/?d=1JUTIYWYCU)

Cu Selur

Why do you use LSMASHVideoSource() for mkv?
LSMASH*Source() is for MOV, ISO Base Media and its derived file formats.
LSMASH*Source() uses libavformat only for the first decoder initialization, and demuxes streams by using L-SMASH demuxer API.
Use LWLibavVideoSource() instead.

[Selur]

DOH, just realized it myself and wanted to report my mistake. :)

[Selur]

Are there any plans to include .mpls (Blu-ray playlist) support as input in LWLibavVideoSource? (would be a 'nice to have' feature)

[LigH]

LSS has an impressive speed advantage in relation to FFMS2 (almost *150% in a quick test (http://forum.gleitz.info/showthread.php?46419&p=437633#post437633) decoding AVC 1080p CRF6); it appears to use one more thread than FFMS2, but this won't be the only reason?

[Groucho2004]

it appears to use one more thread than FFMS2, but this won't be the only reason?
That additional thread could simply be an OS module that is being used by the decoder. Process Explorer would show details about the threads.

Edit:
Just checked - LSS invokes 5 decoding threads on my (quad) i5 2500K without specifying "threads=x". It's marginally faster than specifying 4 threads.

[qyot27]

A few patches that might be useful:

AvxSynth support
https://gist.github.com/qyot27/5794294
(this one is currently broken because it's not creating the function exports correctly under g++ or AvxSynth, or both; it compiles, but that's about it)

Installation rules for the VapourSynth plugin
https://gist.github.com/qyot27/5794299


The third patch is for the case where L-SMASH itself has been patched to install its headers in $(includedir)/lsmash rather than just $(includedir)
https://gist.github.com/qyot27/5794312

Adjusted header search paths
https://gist.github.com/qyot27/5794300
(it does assume that the AvxSynth patch has been applied already)

[qyot27]

I've updated the AvxSynth and VapourSynth install patches slightly (AvxSynth plugin is still broken); the URLs are still the same.

[Selur]

'small' feature request: would be nice if could call LWLibavVideoSource with a list of sources and not just with a single source, since one it a bit of a pain when trying to open a blu-ray that uses a mpls file which links to multiple m2ts files.
LoadPlugin("G:\Hybrid\avisynthPlugins\LSMASHSource.dll")
LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00004.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00109.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00111.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00113.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00115.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00117.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00119.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00121.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00123.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00125.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00127.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00129.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00131.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00133.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00137.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00139.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00141.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00143.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00145.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00147.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00149.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00151.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00153.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00155.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00157.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00159.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00161.m2ts",repeat=true)
return last (using cache=false on this one will crash Avisynth since more than 3.5GB RAM get consumed)

[Music Fan]

I have a strange problem with LWLibavVideoSource (L-SMASH-Works_r629) : when I open a ts file including interlaced h264 (recorded on tv) in 1920.1080 25i, the fields are blended (until there that's normal because I didn't de-interlace video) and the resulting frames are doubled, so the video is seen as 50 fps instead of 25 in Virtual Dub and there is movement only all 2 images.:confused:
The video is considered as interlaced TFF by MediaInfo.
There is only one line in my script ;
LWLibavVideoSource("F:\myvideo.ts")
Sorry if it has been explained earlier, I didn't read all pages.

[Reel.Deel]

@Music Fan

For an explanation read VFR maniac's post in this thread (http://forum.doom9.org/showthread.php?p=1633952#post1633952).

For a solution try remuxing to MKV and set repeat=true.
Like so:
LWLibavVideoSource("Video.mkv", repeat=true)

[Music Fan]

Thanks a lot, repeat=true works with my ts :)
But I'm astonished to note that my ts files are in bff and not tff (I see it clearly by adding separatefields in my script), while I believed tv streams were always in tff.
Is it possible that LWLibavVideoSource does a field inversion ?
Or could it be a difficulty to handle TS container ?
I still had to put these files in MKV container to see if the result is the same.

[LigH]

The field dominance is an attribute of the video stream, not of the container.

If AssumeBFF().Bob() doubtlessly returns smooth motion, whereas AssumeTFF().Bob() returns a forth-and-back jitter, then it is correct, and the material was recorded using a camera with a dominant bottom field.

[VFR maniac]

'small' feature request: would be nice if could call LWLibavVideoSource with a list of sources and not just with a single source, since one it a bit of a pain when trying to open a blu-ray that uses a mpls file which links to multiple m2ts files.
LoadPlugin("G:\Hybrid\avisynthPlugins\LSMASHSource.dll")
LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00004.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00109.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00111.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00113.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00115.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00117.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00119.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00121.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00123.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00125.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00127.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00129.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00131.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00133.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00137.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00139.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00141.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00143.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00145.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00147.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00149.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00151.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00153.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00155.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00157.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00159.m2ts",repeat=true)\
+LWLibavVideoSource("H:\TestClips&Co\BluRay\BDMV\STREAM\00161.m2ts",repeat=true)
return last (using cache=false on this one will crash Avisynth since more than 3.5GB RAM get consumed)

I don't have enough time.
I say again and again "patches welcome".

Thanks a lot, repeat=true works with my ts :)
But I'm astonished to note that my ts files are in bff and not tff (I see it clearly by adding separatefields in my script), while I believed tv streams were always in tff.
Is it possible that LWLibavVideoSource does a field inversion ?
Or could it be a difficulty to handle TS container ?
I still had to put these files in MKV container to see if the result is the same.

Inversion can be done by 'dominance'.

+ dominance : (default : 0)
Which field, top or bottom, is displayed first.
- 0 : Obey source flags
- 1 : TFF i.e. Top -> Bottom
- 2 : BFF i.e. Bottom -> Top
This option is enabled only if 'repeat' is set to true.

Even if a source file is TFF, If the first frame consists of two PAFF field coded pictures and the first field is missing, it should be treated as BFF.
Libavcodec returns frames by pair of two field coded picture.
You can see the source is TFF but the recorded and decoded stream is BFF.

source: ... T0 B1 T2 B3 T4 B5 T6 B7 T8 B9 ...
recorded: B1 T2 B3 T4 B5 T6 B7 T8 B9 ... (the first field dropped)
decoded: [B1 T2] [B3 T4] [B5 T6] [B7 T8] [B9 X] ...

For PAFF field coded pictures, there is no concept of field order or field dominance.
They only play role being coded as top field or bottom field.

[LigH]

I say again and again "patches welcome".

Believe it or not ... there are people in this world who are not C++ programmers. :o

[VFR maniac]

Believe it or not ... there are people in this world who are not C++ programmers. :o

I'm not a C++ programmer.
Though LSMASHSource is written in C++, most features of C++ is not used :P
And the part of shared codes between AviSynth, VapurSynth and AviUtl is compilable with both C99 and C++.
So, basically it requires knowledge about only C.

[Music Fan]

Inversion can be done by 'dominance'.



Even if a source file is TFF, If the first frame consists of two PAFF field coded pictures and the first field is missing, it should be treated as BFF.
Libavcodec returns frames by pair of two field coded picture.
You can see the source is TFF but the recorded and decoded stream is BFF.

source: ... T0 B1 T2 B3 T4 B5 T6 B7 T8 B9 ...
recorded: B1 T2 B3 T4 B5 T6 B7 T8 B9 ... (the first field dropped)
decoded: [B1 T2] [B3 T4] [B5 T6] [B7 T8] [B9 X] ...

For PAFF field coded pictures, there is no concept of field order or field dominance.
They only play role being coded as top field or bottom field.
Thanks, interesting.
Do you believe that TV channels encode in PAFF ?
I believed it was rare.

[Music Fan]

The field dominance is an attribute of the video stream, not of the container.

If AssumeBFF().Bob() doubtlessly returns smooth motion, whereas AssumeTFF().Bob() returns a forth-and-back jitter, then it is correct, and the material was recorded using a camera with a dominant bottom field.
Not necessarily, tv channels often do field inversion to mix tff and bff sources (as we can do with video editing softwares).
When I used to record in analog, video was always in tff, for years, and on all channels.
I guess they also chose tff in digital.

[LigH]

Do you believe that TV channels encode in PAFF ?
I believed it was rare.

PAFF is probably more suitable for hardware real-time encoders (per-frame "decision" – possibly always "yes, this frame is interlaced" – is faster than per-macroblock decision). Many AVCHD cameras record PAFF.

If there is enough time to encode the material "offline", broadcasters may use more elaborate encoders; results created by x264 have been spotted in TV broadcasts already.
__

Field inversions ... do you mean wrong flagging (motion analysis reveals TFF order but bitstream flags report BFF), or do you mean a correct TFF/BFF conversion by omitting one field?

[Music Fan]

do you mean wrong flagging (motion analysis reveals TFF order but bitstream flags report BFF), or do you mean a correct TFF/BFF conversion by omitting one field?
I mean a correct conversion.
So I meant that TV often do that kind of conversion and we can't know if it was filmed in tff or bff.
And as my analog recordings were in tff and as MediaInfo also detects tff for my digital recordings, I was astonished to note that these digital recordings were in bff for Libavcodec.
But VFR maniac has given a good explanation about this phenomenon.

PAFF is probably more suitable for hardware real-time encoders (per-frame "decision" – possibly always "yes, this frame is interlaced" – is faster than per-macroblock decision). Many AVCHD cameras record PAFF.
Ok, good to know.

results created by x264 have been spotted in TV broadcasts already
Do you mean some typical x264 defects seen on TV, which means they also use x264 (which is free) ?

[LigH]

I mean that there have been broadcasts where the video stream contained metadata revealing x264 as encoder.

Nothing to worry about, x264 has commercial licensing too.

[Music Fan]

Update ;
http://k4095-takuan.blogspot.de/p/blog-page_17.html

[LigH]

There is a report (http://forum.gleitz.info/showthread.php?46487&p=438362#post438362) that Apple ProRes (http://www.clipcanvas.com/a/video-clip-downloads/) videos (e.g. clipcanvas_14348_PRORES_HQ.mov) are incorrectly decoded and deskewed by LWLibavVideoSource (LSMASHSource r632), in contrast to FFVideoSource (FFMS2 v2.18 RC1).

[VFR maniac]

Apple ProRes?
Haha, I guess the strange output from LWLibavVideoSource is high bit-depth interleaved format.
You may feel FFMS2 outputs correctly but, the fact, the output loses accuracy around 2-bit for each Y'CbCr component.
Try format="YUV422P8" or stacked=true.

Edit and Note: currently libavcodec ProRes decoder supports only Y'CbCr 4:2:2 10-bit and 4:4:4 10-bit format with or without alpha channel.
Therefore, LWLibavVideoSource(source="ProRes") always output in interleaved format unless user specifies output format.
And even if ProRes4444 (12-bit) is input, the default output format will be Y'CbCr 4:4:4 10-bit with alpha.

[Selur]

btw. is there some way to roughly predict the size of the LWLibavVideoSource index.
Since I can't specify where the index should be created, I normally use to let LWLibavVideoSource create the index inside the RAM, problem is on large files the index gets to large for Avisynth to handle, so I would like to predict the size before indexing a file so I can decide whether to use LWLibavVideoSource or not. :)

[VFR maniac]

There is no way to predict the size of the index file.

The index file consists of properties per packet returned by libavformat in the overall stream.
(+plus CODEC specific decoder configurations and libavformat own index entries)
The size doesn't depend on the source file size.

[VFR maniac]

lsmas: exceeded the number of frames.



This message means the subsequent filter requests frame number exceeding the number of output frames from vslsmashsource.
For instance, the number of output frames from vslsmashsource is 239, and the filter requests 240-th frame, then vslsmashsource will return this error message.

I guess mvtools or VapourSynth's AviSynth compatible module causes the problem.

[Myrsloik]

This message means the subsequent filter requests frame number exceeding the number of output frames from vslsmashsource.
For instance, the number of output frames from vslsmashsource is 239, and the filter requests 240-th frame, then vslsmashsource will return this error message.

I guess mvtools or VapourSynth's AviSynth compatible module causes the problem.

Just return the last frame when that happens. Vs allows frames beyond the end to be requested.

[Music Fan]

Hi,
how to configure LWLibavVideoSource to open VFR h264 ?

[VFR maniac]

@ Myrsloik
Should return with error or warning message?

@ Music Fan
I can't get what you mean.

[Music Fan]

@ Music Fan
I can't get what you mean.
I want to open a vfr video with LWLibavVideoSource, is there anything to add at the end of the 1st line of the script ?
For comparison, when it's done with DirectShowSource, one has to add convertfps=true.
Is there anything like this for LWLibavVideoSource ?

[Myrsloik]

@ Myrsloik
Should return with error or warning message?


As I said, filters are allowed to request frames beyond the end. No errors or warnings.

[LigH]

Current versions of L-SMASH Works (http://k4095-takuan.blogspot.de/p/blog-page_17.html) appears to be r662 (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing).

Changelog is probably best read in the Github (https://github.com/VFR-maniac/L-SMASH-Works/commits/master).
__

A user in the german doom9/Gleitz forum is reporting intermittent issues with batch-converted DVB-S2 720p50 movies being encoded twice as long, sometimes repeated, sometimes with green blanks. But before your alarm goes off, we are trying to discover the reason (RAM, resident AV, timing issue of indexing different files with always the same temporary name...). Usually a second run returns a correct conversion.

[wOxxOm]

I added supporting of a hack of high bit-depth input between rev594 and rev603.
For interleaved format (at default), only little endianness output is supported currently i.e. LSB comes at the first byte and MSB comes at the second.
Stacked format is also available but direct rendering is always not available if used.

In order to use LW in avisynth to process 10-bit video files with high-bitdepth plugins (like modded dfttest and mdegrain from the Dither (http://forum.doom9.org/showpost.php?p=1386559&postcount=3) package) the output needs to be converted.

Stacked=true: 950 fps (LWLibavVideoSource only) -> 400 fps drop.
msb = crop(0,0,0,height/2)
lsb = crop(0,height/2,0,0)
stackvertical(mt_lutxy(msb,lsb,"x 8 << y + 2 >>",u=3,v=3),
\ mt_lutxy(msb,lsb,"x 8 << y + 3 &u 6 <<",u=3,v=3))

On default settings it's even slower because of bad avisynth's turn implementation: 110 fps (or 300 fps with FTurn SSE2 (http://forum.doom9.org/showpost.php?p=1638416&postcount=1))
assumebff.turnleft.separatefields.turnright.assumeframebased
stackvertical( mt_lutxy(selectodd, selecteven, "x 8 << y + 2 >>", u=3,v=3),
\ mt_lutxy(selectodd, selecteven, "x 8 << y + 3 &u 6 <<", u=3,v=3))

BTW, the output of FFVideoSource with 10-bit-to-stacked hack can be used directly by the aforementioned plugins...
It'd be nice if the LW output for 10-bit files in avisynth would match that, since it's not as useful otherwise.

[VFR maniac]

I want to open a vfr video with LWLibavVideoSource, is there anything to add at the end of the 1st line of the script ?
For comparison, when it's done with DirectShowSource, one has to add convertfps=true.
Is there anything like this for LWLibavVideoSource ?

LWLibavVideoSource doesn't support VFR->CFR conversion i.e. doesn't pad frames for VFR source.
It just returns frame by frame.
VFR->CFR conversion is "patches welcome".

In order to use LW in avisynth to process 10-bit video files with high-bitdepth plugins (like modded dfttest and mdegrain from the Dither (http://forum.doom9.org/showpost.php?p=1386559&postcount=3) package) the output needs to be converted.

Stacked=true: 950 fps (LWLibavVideoSource only) -> 400 fps drop.
msb = crop(0,0,0,height/2)
lsb = crop(0,height/2,0,0)
stackvertical(mt_lutxy(msb,lsb,"x 8 << y + 2 >>",u=3,v=3),
\ mt_lutxy(msb,lsb,"x 8 << y + 3 &u 6 <<",u=3,v=3))

On default settings it's even slower because of bad avisynth's turn implementation: 110 fps (or 300 fps with FTurn SSE2 (http://forum.doom9.org/showpost.php?p=1638416&postcount=1))
assumebff.turnleft.separatefields.turnright.assumeframebased
stackvertical( mt_lutxy(selectodd, selecteven, "x 8 << y + 2 >>", u=3,v=3),
\ mt_lutxy(selectodd, selecteven, "x 8 << y + 3 &u 6 <<", u=3,v=3))

BTW, the output of FFVideoSource with 10-bit-to-stacked hack can be used directly by the aforementioned plugins...
It'd be nice if the LW output for 10-bit files in avisynth would match that, since it's not as useful otherwise.

Did you try format="YUV4**P16"?
'format' and 'stacked' are not exclusive option each other.
I have not tested speed comparison though.

[wOxxOm]

Did you try format="YUV4**P16"?
'format' and 'stacked' are not exclusive option each other.
I have not tested speed comparison though.
Thank you for the hint, I've totally missed the flexibility of 'format', here's a 1080p-10bit quick test results (the video is different, so fps shouldn't be compared to that in my previous post):
YUV420P10 265 - default mode
YUV420P10stacked 248
YUV420P16 270
YUV420P16stacked 190 - same fps as the old ffms2-mod

Edit: 18 Aug build
YUV420P10 285 - 7% faster
YUV420P10stacked 285 - 15% faster
YUV420P16 285 - 5% faster
YUV420P16stacked 223 - 17% faster than the previous build

[Reel.Deel]

@VFR maniac

I think I might of found a bug in VS LSmashSource r662.

I don't know how I managed to create it, but I cut a small MPEG2 sample and last frames seem to be corrupted.
When I try opening it in VapourSynth using either VirtualDub or AvsPMod it silently crashes when it gets to frame 499 or beyond. Muxing it into MKV also did not fix the problem.
The very same file does not crash in AviSynth.

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path=r'C:\VapourSynth\LSmashSource\vslsmashsource.dll')

# Source
src = core.lsmas.LWLibavSource(source=r'C:\VapourSynth\LSmashSource\Test_Corrupt.m2v')

# Output
src.set_output()

Here's the corrupted (https://www.dropbox.com/s/2o3lmi9io0xu8gx/Test_Corrupt.m2v) sample used to cause the crash.
Don't know if is any help but here's the very same sample uncorrupted (https://www.dropbox.com/s/aeq5piha6rrqzhd/Test_Correct.m2v).

[VFR maniac]

@VFR maniac

I think I might of found a bug in VS LSmashSource r662.

I don't know how I managed to create it, but I cut a small MPEG2 sample and last frames seem to be corrupted.
When I try opening it in VapourSynth using either VirtualDub or AvsPMod it silently crashes when it gets to frame 499 or beyond. Muxing it into MKV also did not fix the problem.
The very same file does not crash in AviSynth.

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path=r'C:\VapourSynth\LSmashSource\vslsmashsource.dll')

# Source
src = core.lsmas.LWLibavSource(source=r'C:\VapourSynth\LSmashSource\Test_Corrupt.m2v')

# Output
src.set_output()

Here's the corrupted (https://www.dropbox.com/s/2o3lmi9io0xu8gx/Test_Corrupt.m2v) sample used to cause the crash.
Don't know if is any help but here's the very same sample uncorrupted (https://www.dropbox.com/s/aeq5piha6rrqzhd/Test_Correct.m2v).

I can't reproduce the crash in r682 though I haven't tested in r662.

[zettai]

I'm trying to build the vapoursynth libs on OSX but I'm not really sure what I'm doing.

I've cloned the git repo but I don't know what options to put into configure. Has anyone done this who could give me some pointers?

edit: nevermind. I hadn't built l-smash first. It's fine now :)

[Reel.Deel]

I can't reproduce the crash in r682 though I haven't tested in r662.

Hmm, just tried with r688 and I still have the same problem.
I have double checked to make sure I'm not doing anything wrong.
Maybe this can be something specific to my system? I'm using 32-bit Windows XP SP3 with a Q6600 (http://ark.intel.com/products/29765).

[qupfer]

Hi,

I'm sorry if my question sounds stupid but I have some trouble to understand the "repeat-mode". It could be related to my unawareness(? its a google translation) about the dependigs of fields and frames ;)

Can I say summarized:
If my source is interlaced-flaged (like 1080i HDTV recordings) I set repeat=true and if the source in progressiv (non-interlaced DVD,BD) then repeat=false?
And what happend, if I set repeate=true for a progressiv source?

And why is repeat=true what it is? I mean, i would suppose what with set to true, I will have some/all frames twice and not with the false-option.

Can somebody give me a easy-to-understand explanation? :thanks:

[sneaker_ger]

There is a report (http://forum.gleitz.info/showthread.php?46487&p=438362#post438362) that Apple ProRes (http://www.clipcanvas.com/a/video-clip-downloads/) videos (e.g. clipcanvas_14348_PRORES_HQ.mov) are incorrectly decoded and deskewed by LWLibavVideoSource (LSMASHSource r632), in contrast to FFVideoSource (FFMS2 v2.18 RC1).

Apple ProRes?
Haha, I guess the strange output from LWLibavVideoSource is high bit-depth interleaved format.
You may feel FFMS2 outputs correctly but, the fact, the output loses accuracy around 2-bit for each Y'CbCr component.
Try format="YUV422P8" or stacked=true.

Edit and Note: currently libavcodec ProRes decoder supports only Y'CbCr 4:2:2 10-bit and 4:4:4 10-bit format with or without alpha channel.
Therefore, LWLibavVideoSource(source="ProRes") always output in interleaved format unless user specifies output format.
And even if ProRes4444 (12-bit) is input, the default output format will be Y'CbCr 4:4:4 10-bit with alpha.

Did you take a look at the samples? For me it does indeed seem broken instead of a user error. Output is greenish, even if I assume interleaved format. When using the stacked=true parameter the upper half is greenish as well.

LSMASHVideoSource("clipcanvas_14348_ProResHQ_720p50.mov", stacked=true)
#DitherPost()
http://abload.de/img/lsmashvideosource_proisqg8.jpg

[VFR maniac]

Did you take a look at the samples? For me it does indeed seem broken instead of a user error. Output is greenish, even if I assume interleaved format. When using the stacked=true parameter the upper half is greenish as well.

LSMASHVideoSource("clipcanvas_14348_ProResHQ_720p50.mov", stacked=true)
#DitherPost()
http://abload.de/img/lsmashvideosource_proisqg8.jpg

It's not broken because significant bits of the MSB are lower 2 bits only i.e. the values of each Y'CbCr component are almost near by zero.
10 bits = MSB 2 bits + LSB 8 bits
Upper 6 bits of the MSB make no sense.
Therefore, the greenish is normal with 10bit Y'CbCr samples.

[sneaker_ger]

Any reason for choosing this format? Dither/f3kdb/x264 seem to do it the other way, so one would would need to skew those bits over into the MSB to make it compatible with those? Or am I missing something again?

[VFR maniac]

Libavcodec decoders output by such format; [LSB 8 | zero 6 | MSB 2] for 10-bit Y'CbCr.
As the default, the postprocessor after decoding works as just copying data delivered from decoder into the AviSynth video buffer.
Basically I believe that data shall not be modified unless user, decoder or demuxer specifies.
10->16 change may add something of dither instead of simple bit-shifting.

Use format="YUV4**P16" if you need the format [LSB 8 | MSB 8].

[sneaker_ger]

10->16 change may add something of dither instead of simple bit-shifting.

"May"?

[zero9999]

does LWLibavVideoSource export useful global variables like FFMS2 (SAR, matrix, tv/pc range, cfr & vfr time) ?

[Selur]

trying to access http://k4095-takuan.blogspot.de/p/blog-page_17.html I now get "This blog is open to invited readers only" :(

[Reel.Deel]

"This blog is open to invited readers only"

Must of recently happened, I was just there last night. Anyways, here's r688 (https://www.dropbox.com/s/pok2p8kygc06t5d/L-SMASH-Works_r688v2.7z) for anyone looking for it.

[Selur]

thanks

[Selur]

is it just me, or isn't LWLibavVideoSource any more reuse the .lwi index file? (iirc it did before)

[l33tmeatwad]

trying to access http://k4095-takuan.blogspot.de/p/blog-page_17.html I now get "This blog is open to invited readers only" :(Must of recently happened, I was just there last night. Anyways, here's r688 (https://www.dropbox.com/s/pok2p8kygc06t5d/L-SMASH-Works_r688v2.7z) for anyone looking for it.That is odd...well at least the google drive folder (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing) where you can download it is still shared.

is it just me, or isn't LWLibavVideoSource any more reuse the .lwi index file? (iirc it did before)I haven't noticed it not reusing the index files, have you tried the newest version (r688v2)?

[RTW47]

from my experience latest LWLibavVideoSource do not re-write index file, if it was already created.
and it doesn't seem to (re-index) overwrite index file created by aui_indexer either.

[LigH]

Not even if the timestamp of the source file is newer than the timestamp of the index file (so the source has probably changed since indexing it)?

[the_weirdo]

Not even if the timestamp of the source file is newer than the timestamp of the index file (so the source has probably changed since indexing it)?

In my tests, even when you've replaced the source file with a different file, it still re-use the index file.

[VFR maniac]

trying to access http://k4095-takuan.blogspot.de/p/blog-page_17.html I now get "This blog is open to invited readers only" :(

He moved his blog.
It was announced at the top page of the old one.

http://otsukemono.blogspot.jp/

[Selur]

thanks, added the info to the first post.

[Brazil2]

thanks, added the info to the first post.
Maybe you should add the URL tags to your URLs to make them clickable ;)

But I thought L-Smash muxer.exe was now able to mux HEVC into MP4 but I can't make it working with rev786 while it works with the same source and MP4box rev4868. Am I missing anything ?
Example of source file: https://x265.cc/builds/Samples/bigbuckbunny.hevc

[VFR maniac]

But I thought L-Smash muxer.exe was now able to mux HEVC into MP4 but I can't make it working with rev786 while it works with the same source and MP4box rev4868. Am I missing anything ?
Example of source file: https://x265.cc/builds/Samples/bigbuckbunny.hevc

http://repo.or.cz/w/L-SMASH.git/commitdiff/153572b12eed094fbf68c6770c753810d49e5a3a

HEVC muxing is testing and experimental purposes only at present since the specification is not finalized and published yet.

I don't want you to mux HEVC for archival and distribution purposes since there is no guarantee that the file is demuxed and decoded correctly in the future.
At least, L-SMASH will reject files based on the draft versions.
Be patient, please.

If compiled with the latest ffmpeg (which can output POCs of HEVC), L-SMASH Works can seek raw Annex B HEVC stream.
So, you can play avs importing the raw stream and audio stream as if AVI.

[Brazil2]

HEVC muxing is testing and experimental purposes only at present since the specification is not finalized and published yet.

I don't want you to mux HEVC for archival and distribution purposes since there is no guarantee that the file is demuxed and decoded correctly in the future.
At least, L-SMASH will reject files based on the draft versions.
OK, thanks for clarification :)

Be patient, please.
No! :D :p ;)

[LigH]

In my tests, even when you've replaced the source file with a different file, it still re-use the index file.

Confirming. L-SMASH Source (which I'm using as AviSynth plugin) needs a sanity check of the index file to rebuild it when outdated.

(Confirmed with r688-2; not yet tested with most recent r693)

[Music Fan]

LWLibavVideoSource seems to have a problem with big ts files (I tested 2 files ; 4,70 GB and 6,02 GB) in interlaced h264 : the framerate is doubled, even when repeat=true is added. It happens on rev 693, 688 and 662.
With a short extract of one of these files (5 minutes, 230 MB cut with TSMuxer), there is no problem, even when repeat=true is not added (with rev693).
I don't know which is the size limit to allow a good working, I guess 4 GB.

[StainlessS]

Try cutting out 2 clips, one about 1.75GB and other about 3.75GB.

[Lenmaer]

It's not bound to file size.
I've noticed this error since the beginning with LWLibavVideoSource.
I noticed also that it affects MBAFF m2ts files, whatever their length or size.
And FFMS2 has that bug too.

[Music Fan]

Try cutting out 2 clips, one about 1.75GB and other about 3.75GB.
Ok, but that won't help me for big files. Or I should cut them in several parts, then re-encode and merge them.

[Music Fan]

It's not bound to file size.
I've noticed this error since the beginning with LWLibavVideoSource.
I noticed also that it affects MBAFF m2ts files, whatever their length or size.
And FFMS2 has that bug too.
In this case, why does it work with an extract of the big file ?

[StainlessS]

Ok, but that won't help me for big files. Or I should cut them in several parts, then re-encode and merge them.

Was intended to ascertain whether problem over 2GB (signed int)
or 4GB (unsigned int), but as Lenmaer says unrelated to size, then of no use.

In this case, why does it work with an extract of the big file ?

perhaps because of remux, try remux whole thing.

[Lenmaer]

In this case, why does it work with an extract of the big file ?

That I can't say, perhaps TS muxer does something that corrects it?

[LigH]

Especially transport streams from DVB [-S2] may always contain transmission errors. They should never be used without cleaning.

And even if direct handling of TS sources is more or less supported by FFMS2 (with the required Haali splitter) or L-SMASH Source, handling a source remultiplexed to MKV is certainly more reliable.

[Music Fan]

Especially transport streams from DVB [-S2] may always contain transmission errors. They should never be used without cleaning.
I did it with TSDoctor.

And even if direct handling of TS sources is more or less supported by FFMS2 (with the required Haali splitter) or L-SMASH Source, handling a source remultiplexed to MKV is certainly more reliable.
Ok, I will try it.

[Music Fan]

Tried in MKV, does not work either with 4,70 GB file ; still have to try 2,5 and 3,5 GB sized files.

[Music Fan]

Tried a 2,5 GB ts : strange behavior (with rev693) : Virtual Dub detects now 25 fps -whatever I specify repeat=true or not-, but in both cases all frames are doubled anyway and the file length too, and it is played at half speed.:scared:

edit : same problem with a 1,64 GB TS cut with TSMuxer.

edit : different problem when the 2,5 and 1,64 GB files are put in MKV : file length is good but all frames are also doubled -whatever I specify repeat=true or not- and Virtual Dub detects 50 fps (I demuxed streams with TSMuxer, opened them in MKVMerge and specified 50i as framerate).

Even below 2 GB, there are problems.

[LigH]

If it also fails for a cut of a few seconds, then please provide a sample...

[Music Fan]

As I said 2 days ago, it works with a 5 minutes extract (230 MB), otherwise I wouldn't have made all these tests.

[Music Fan]

r702 is online ;
https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing

[Music Fan]

I can't make it work, I get this error message : "unable to load dll, error=0x7e". :scared:

[Music Fan]

Thanks, works with dll in system32 folder ;)

But I still have the problem described above with big interlaced h264 files.:(

[real.finder]

about interlaced h264 and double FPS, you can use Select Even or Select Odd, try to see which one is best suited to your video

and about MS C++, can you back it to old one? I think that the 2012 update 4 is suitable in order to unite with avs+

[the_weirdo]

You can just install VC++ 2013 Redist. It doesn't harm anything.

[turbojet]

I'm getting crc32 errors when using this with 2 pass decimate.

1st pass
LWLibavvideosource("source",cache=false,dr=true)
TFM(clip2=nnedi3(),mode=3).sorathread().TDecimate(mode=4,output="metrics.txt",rate=25)

2nd pass
LWLibavvideosource("source",cache=false,dr=true)
TFM(clip2=nnedi3(),mode=3).sorathread().TDecimate(mode=2,input="metrics.txt",rate=25)

When it starts the second pass it throws:
TDecimate: crc32 in input file does not match that of the current clip (0x95a26115 vs 0xc40c874d)!

When I use DSS/DSS2 for both passes it works fine. I haven't tested other source filters yet but any idea what could be going on?
Changing lw back to defaults had no effect.

When dr=true there's corrupt lines on the bottom, it really sticks out with this clip http://www.sendspace.com/file/qiqta1. It's unfortunate because it's a nice speed increase.

[turbojet]

That sample was for the corrupt bottom lines but I figured out it only effects 1080 sources. It's expanding to 1088 to make it a multiple of 16. Wouldn't it make sense to either automatically crop the added lines that were added when dr=true?

It was a different source (4GB) that was throwing the tdecimate error. I tried cutting it but couldn't reproduce the issue that way. Just finished redoing first pass and about half the time the second pass loads okay, other times it throws an ntdll error. Haven't seen a tdecimate error this time. DSS2 second pass always loads. I can upload the whole source if you want otherwise maybe the index file can help find a problematic part to cut. http://www.sendspace.com/file/1gpmpv

[Lenchik]

sample 10 bit RGB DPX file (https://archive.org/details/Sample10BitRgbDpxFile)
ImageMagick identify verbose output attached
After ImageMagick manipulation convert Sample10BitRgbDpxFile_00255.dpx ( -clone 0 -evaluate and 65280 ) ^ ( -clone 0 -evaluate and 255 -evaluate leftshift 8 ) -delete 0 -append Sample10BitRgbDpxFile_00255.bmp
I get stack16 bmp (https://docs.google.com/file/d/0Bzb8ahHlm9BBS1lDOWdiWFVFQWM).

While
img = img_fldr + "Sample10BitRgbDpxFile_00255.dpx"
LWLibavVideoSource(img, cache=false, stacked = true)
gives me "gbrp10le is not supported".

LWLibavVideoSource(img, cache=false, format="YUV444P16", stacked = true)
gives me some stack16 output which is not identical to ImageMagick's. Too many differences. YUV444P16 output is much brighter (brighter than pc-tv difference) and bottom part of image is completely different in colors of "garbage" (not like 601-709 difference).

How can i get out of LWLibavVideoSource (+ maybe some additional manipulations) the same as from ImageMagick's to-stack16-bmp-conversion?
Or this is some bug in L-Smash Source?
Maybe i am doing something wrong with ImageMagick?

p. s. Avisynth 2.6 latest MT build by Set

[wOxxOm]

Lenchik, XnView and Photoshop don't agree with you and show the picture almost the same as LWLibavVideoSource, so the bmp produced by imagemagick is too dark. However, the white balance of LWLibavVideoSource output differs from both Photoshop and XnView, it's a little too warm.

[Lenchik]

Lenchik, XnView and Photoshop don't agree with you and show the picture almost the same as LWLibavVideoSource, so the bmp produced by imagemagick is too dark.
Maybe this has something to do with log colorspace (that is reported by imagemagick's identify) and some conversions applied (or not applied)? I didn't understand fully info at pages that i have found recently: http://galannicolas.com/mediawiki-1.13.3/index.php?title=Color_Space_101
http://www.qvolabs.com/Digital_Images_ColorSpace_Log_vs_Linear.html

[Dogway]

Maybe this has something to do with log colorspace (that is reported by imagemagick's identify) and some conversions applied (or not applied)? I didn't understand fully info at pages that i have found recently: http://galannicolas.com/mediawiki-1.13.3/index.php?title=Color_Space_101
http://www.qvolabs.com/Digital_Images_ColorSpace_Log_vs_Linear.html

Log files look always that pale, without any type of proofing or real time LUT viewer.
cretindesalpes created (http://forum.doom9.org/showthread.php?p=1532300#post1532300)a function for that.
It will convert log space to gamma encoded space such as ITU601.

[MeteorRain]

I experienced memory overflow on indexing bluray remux'd mkv file using core.lsmas.LWLibavSource().

The file is about 11GB big, 1 hour in length.

The memory usage continuously increases from 100MB to ～2GB and then python (or whatever other process) crashes, leaving the lwi file at ～80% progress or so.

Did anyone experience the same problem before?

I'm on the latest version (r708), Windows Server 2012.

[LigH]

Current binary (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing) = r708: git-c7cc104 [2013-12-08]

[Music Fan]

Thanks, I copy here a part of the changelog for those who wonder what changed.

r708: git-c7cc104 [2013-12-08] lwlibav_video: Retry seek when corrected frame_number greater than rap_number.
r707: git-32c1ff2 [2013-12-08] lwlibav_audio: Fix possible infinite loop.
r706: git-0b66edf [2013-12-07] common/audio: Remove unused variable audio_frame_count.
r705: git-dc8bd80 [2013-12-07] libavsmash: Fix free() -> lsmash_free() to prevent crash on different C runtime.
r704: git-8eb5a8f [2013-12-01] lwindex: Generate or interpolate DTS if any invalid DTS for WMV/VC-1.
r703: git-ed370d7 [2013-11-30] Use av_frame_alloc() instead of deprecated avcodec_alloc_frame().
r702: git-f9b2b46 [2013-11-29] lsmashsource: Add x64 configuration to VC10/11/12 solution.
r701: git-a3d6d20 [2013-11-29] lsmashsource: Fix compilation on x64.
r700: git-acc739a [2013-11-23] lwinput: Remove redundant cleanup operations at closing file.
r699: git-2ea3cae [2013-11-10] lwmuxer: Fix the dialog box title.
r698: git-409bb24 [2013-11-10] lwdumper: Fix the dialog box title.
r697: git-b0fea24 [2013-11-10] AviUtl/progress_dlg: Cosmetics.
r696: git-a198bea [2013-11-10] lwinput: Fix the dialog box title.
r695: git-1e84230 [2013-11-03] lsmashsource: Add VC12 support.
r694: git-0eb40a4 [2013-11-02] lwindex: The maximum max_num_reorder_pics is equal to 15 for HEVC ver.1.
r693: git-2c9602f [2013-11-01] libavsmash: Try to get codec_id from summaries when getting track if unknown.
r692: git-a193e98 [2013-11-01] lwindex: Generate PTSs from POCs for HEVC stream if incomplete.
r691: git-0c7b2f4 [2013-11-01] libavsmash: Support High Efficiency Video Coding.
r690: git-490544b [2013-10-31] lwindex: Construct frame from pair of field coded picture automatically if any.
r689: git-26686fe [2013-10-31] Update VapourSynth.h to synchronize with R21.

[LigH]

Available on Google Drive. Changelog:

r713: git-dd17b77 [2014-02-14] video: Fix 10L introduced in 2aa7ba260d .
r712: git-1612126 [2014-02-14] video: Improve average framerate calculation more.
r711: git-4f027a7 [2014-02-14] Use av_frame_free() instead of deprecated avcodec_free_frame().
r710: git-7ed15b3 [2014-02-14] Remove avcodec_get_frame_defaults().
r709: git-2aa7ba2 [2014-02-14] video: Improve average framerate calculation.

[turbojet]

This was working well for months but now all of a sudden I'm getting error=0x7e. Any ideas on how to fix?

Edit: nevermind, moving msvcr120 worked like it did for Music Fan. Wonder why this all of a sudden started happening.

[LigH]

In general, you should prefer installing MSVC 2013 runtimes over copying a DLL into the possibly wrong directory (because there are 32-bit and 64-bit variants of it, and intermixing causes crashes).

[LigH]

In contrast to FFMS2, L-SMASH Source for AviSynth does not decode Apple ProRes correctly ... or at least, "usably":

Coastguard_ProRes.mov (http://hwcdn.net/j9t9v3v5/cds/Coastguard_ProRes.mov) (750 MB, Elemental Technologies 4K test sequences (http://www.elementaltechnologies.com/resources/4k-test-sequences)) — MediaInfo full report (http://paste.frubar.net/15937)

It returns a YV16 video with twice the width (7680x2160 px), which is displayed with vertical color stripes, probably due to an enhanced color depth. I have to use the following addition to have L-SMASH source convert it to YV12:

LSMASHVideoSource("Coastguard_ProRes.mov", format="YUV420P8")

[sneaker_ger]

http://forum.doom9.org/showthread.php?p=1636993#post1636993

[LigH]

Verdamp lang her :D

OK, checking with "stacked=true" ... no; mainly green above, "fantastic colors" below (but at least a hint that it may be high bitdepth). Mapping to 8 bit per component (format="YUV...P8") is required.

[sneaker_ger]

Choose a P16 format if you need high bit depth 8 bits msb + 2 bits lsb + 6 bits zero, the decoder uses 6 bits zero + 2 bits msb + 8 bits lsb by default for P10.

[Music Fan]

Good news, LWLibavVideoSource seems to handle correctly now the framerate of big interlaced h264 TS files (with rev 713), even without adding repeat=true.:)
I recall that until rev693 (and maybe more recent versions, I didn't test those between 693 and 713), the framerate was doubled with some files, even when repeat=true was added.
http://forum.doom9.org/showthread.php?p=1652889#post1652889

But for some reasons, when I open my avs script in Virtual Dub, nothing happens when I click on next frame, I have to move Virtual Dub's GUI with the mouse to see the refresh and thus the next frame.
I don't know if this is linked to LWLibavVideoSource, Virtual Dub or my pc.:confused:
Something else : when I open this script, the picture is green in the left window (input video pane), not in the right window (output video pane), while ffdshow is not used. I also have to move Virtual Dub's GUI to see the real picture instead the green one.
I don't have this problem when I open an avi in Virtual Dub (without avisynth). :confused:

[cretindesalpes]

Hi,

I have reading problems with LWLibavVideoSource, 10-bit input and stack mode.
L-Smash r714
Avisynth 2.6 alpha 5 and Avisynth+ MT r1689
CPU: i7 Haswell

http://s30.postimg.org/dzicgspy5/bad_stack16_lwlibavvideosource.jpg (http://postimg.org/image/dzicgspy5/)

Video sample (12 MB) (http://www.mediafire.com/download/r4hfullc4tsy6da/bad-stack16.mkv)LWLibavVideoSource ("bad-stack16.mkv", format="YUV420P16", stacked=true)
Note: it works correctly with the default parameters (interleaved bytes)

[wOxxOm]

cretindesalpes, apparently I can't reproduce with just the code above here on avs+ r1576 x86, avs2.6a5 x86, avs+ MT r1689 x86: pic (http://i.imgur.com/CiD9SQg.png)

Edit: oic, my ivy bridge i7 has AVX, not AVX2.

[VFR maniac]

Hi,

I have reading problems with LWLibavVideoSource, 10-bit input and stack mode.
L-Smash r714
Avisynth 2.6 alpha 5 and Avisynth+ MT r1689
CPU: i7 Haswell

http://s30.postimg.org/dzicgspy5/bad_stack16_lwlibavvideosource.jpg (http://postimg.org/image/dzicgspy5/)

Video sample (12 MB) (http://www.mediafire.com/download/r4hfullc4tsy6da/bad-stack16.mkv)LWLibavVideoSource ("bad-stack16.mkv", format="YUV420P16", stacked=true)
Note: it works correctly with the default parameters (interleaved bytes)

Maybe the bug was fixed at rev715.
https://github.com/VFR-maniac/L-SMASH-Works/commit/4ada105018cb848b475d1ff8092ee4455e40c1cf

[burfadel]

Hmmm, couldn't download r715 via the icon:
https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU

I had to manually get it.

[Music Fan]

Hmmm, couldn't download r715 via the icon:
https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU

I had to manually get it.
How did you do ? I can't get it.

[burfadel]

How did you do ? I can't get it.

This is where the icon is meant to take you:
https://docs.google.com/file/d/0BwV03nn6LPd9Y21BSHJUblVQRHc/edit?usp\u003ddrive_web

[Music Fan]

Thanks !

[wOxxOm]

VFR maniac, r715 produces blocks and ugly artifacts on i7 ivy bridge in p16 stacked mode, r714 is ok.

[VFR maniac]

What!?
The fix should not affect Ivy Bridge since it has no AVX2 support.
I'm using i5 3570 Ivy Bridge but can't replicate the issue.

[wOxxOm]

What!?
Exactly my words after seeing this (http://screenshotcomparison.com/comparison/69311) using whatever format/stacked combination, some of them are more broken though.

Maybe the code (https://github.com/VFR-maniac/L-SMASH-Works/blob/4ada105018cb848b475d1ff8092ee4455e40c1cf/AviSynth/video_output.cpp#L206) should have an explicit if (avx2_available) branch?

Edit: the updated r715 works. Thanks.

[VFR maniac]

The for-loop does nothing if no AVX2 support since width32 is set to 0 i.e. _width32 is set to 0.
And, if the address of the source buffer is non-mod32, _width32 is also set to 0 and the loop also does nothing in this case.

Edit: the issue has nothing to do with rev715.
I also replicate the issue by using his build.
Probably it is a bug of linked ffmpeg.

Edit2: He rebuild and reupload. Try again.

[Zathor]

Thanks for your work!

There seems to be a memory problem with all builds which I have tried (702 to 715). I am using it from within AviSynth+ (r1576) - but have tried also other AviSynth versions. The script will be called from within MeGUI several times (auto crop, deinterlace detection, encoding, ...) and after a while a script cannot be opened anymore with the error "[Fatal]: Failed to avformat_open_input." It can then be noticed that the memory consumption of the MeGUI process is high (up to 2GB) and it will not be freed when the script is closed. I have to close MeGUI and then the last operation can be continued. Also other users have the same problem: http://forum.doom9.org/showthread.php?p=1676500#post1676500

I have to try it with other programs as well (e.g. VirtualDub), but with other source filters I do not have the problem (ffms, dgindex, dgindexnv, ...) - only exception is the c-plugin of ffms which also seems to have a memory leak.
EDIT: Just tried it with VirtualDub. I opened and closed a simple script
LWLibavVideoSource("C:\test.mkv.lwi")
pointing to test.mkv - lwi size is ~50 MB. During every open/close cycle the memory increase and will not be freed completly.
I made those tests with r715 v2.

[Music Fan]

Edit: the updated r715 works. Thanks.
Is it still this link (given above) or another ;
https://docs.google.com/file/d/0BwV03nn6LPd9Y21BSHJUblVQRHc/edit?usp\u003ddrive_web&pli=1

[wOxxOm]

Is it still this link (given above) or anotherNo, the new one has _v2 in its name, just use the folder link and you'll see the updated file there, click it, then download.

[Music Fan]

Thanks, it's there but I can't download it, nothing happens when I click on the link :confused: ;
https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing#list
same problem when displayed like this (logical) ;
https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing

[Reel.Deel]

This link should work - https://docs.google.com/file/d/0BwV03nn6LPd9M1YycUVka29xVEU/edit

[filler56789]

Thanks, it's there but I can't download it, nothing happens when I click on the link :confused:

It seems that, since "some time ago", you must be logged in to your GMail or Google account, in order to to be allowed to download the files :mad: :(

[Music Fan]

This link should work - https://docs.google.com/file/d/0BwV03nn6LPd9M1YycUVka29xVEU/edit
Thanks, it does.
How do you find this link ?

[Music Fan]

It seems that, since "some time ago", you must be logged in to your GMail or Google account, in order to to be allowed to download the files :mad: :(
Mmmh, I have neither the one nor the other.:o

[yipeskop]

I think I have a bug to report. Upon trying to inverse telecine some ads, I realized I was getting weird artifacting. Upon inspection with a script of just LWLibavVideoSource("video").SeparateFields(), I found that the field order became completely messed up part way through the video. It was fine in the first half or so, but then started messing up some point after. Trying the script with both AssumeTFF() and AssumeBFF() didn't work, and trying LWLibavVideoSource with a dominance of both 1 and 2 didn't work. I've tried it on some other telecined material and it has the same issue. I'm using r715, by the way. I've also had this issue confirmed by a friend of mine who was using r714.

Here is one of the files in question (https://dl.dropboxusercontent.com/u/42171557/00011.m2ts) that it was having trouble displaying correctly. This video is a mix of progressive and telecined material. It starts having the field ordering issues once it reaches the Arata Kangatari ad around 1:20. Although do note that this issue also happened with a video that was a mix of pure interlace and telecine and also a video that was just purely telecine. The one purely interlaced video I tried it with worked perfectly fine (aside from the script causing mpc to crash near the end, but the video encoded fine with x264 at least)

edit: a correction about the sample video I gave in this post. it's a mix of pure interlaced and telecined. Not sure why I said it was progressive.

[wOxxOm]

you must be logged in to your GMail or Google account, in order to to be allowed to download the filesIt's fixed now, you can download anonymously from Drive.

the field order became completely messed up part way through the videoWell, there are *many* different videos actually, so different field order is completely expected.

[yipeskop]

Well, there are *many* different videos actually, so different field order is completely expected.

No, the whole file is TFF, as a simple avisynth script of FFVideoSource().AssumeTFF().SeparateFields() will show. Both FFVideoSource and DirectShowSource handle the videos I mentioned just fine. Only LWLibavVideoSource is giving wrong output, which is why I said it's probably a bug.

And in any case, I also said it was having issues with a purely telecined source anyway. So "*many* different videos" has nothing to do with it. I'll put the 750MB purely telecined ad in this comment as soon as it's done uploading if you or anyone wants to check it.

edit: And here's the telecine sample video (https://dl.dropboxusercontent.com/u/42171557/00010.m2ts)

[wOxxOm]

yipeskop, I think LWLibavVideoSource gets it wrong from the very beginning by dropping one field. Here's what appears to be a fix: LWLibavVideoSource("00011.m2ts").SeparateFields().DuplicateFrame(0).Weave()And the same goes for 0010.m2ts
So yeah there's a bug obviously.

[VFR maniac]

I think I have a bug to report. Upon trying to inverse telecine some ads, I realized I was getting weird artifacting. Upon inspection with a script of just LWLibavVideoSource("video").SeparateFields(), I found that the field order became completely messed up part way through the video. It was fine in the first half or so, but then started messing up some point after. Trying the script with both AssumeTFF() and AssumeBFF() didn't work, and trying LWLibavVideoSource with a dominance of both 1 and 2 didn't work. I've tried it on some other telecined material and it has the same issue. I'm using r715, by the way. I've also had this issue confirmed by a friend of mine who was using r714.

Here is one of the files in question (https://dl.dropboxusercontent.com/u/42171557/00011.m2ts) that it was having trouble displaying correctly. This video is a mix of progressive and telecined material. It starts having the field ordering issues once it reaches the Arata Kangatari ad around 1:20. Although do note that this issue also happened with a video that was a mix of pure interlace and telecine and also a video that was just purely telecine. The one purely interlaced video I tried it with worked perfectly fine (aside from the script causing mpc to crash near the end, but the video encoded fine with x264 at least)

edit: a correction about the sample video I gave in this post. it's a mix of pure interlaced and telecined. Not sure why I said it was progressive.

The file changes its field order in material level on the way of the stream but indicates TFF on the whole of the stream.
The stream is encoded simply as TFF MBAFF 60i.
So, the proper behaviour of the decoder is just returning a frame by frame.
I think L-SMASH Works is working properly.

No, the whole file is TFF, as a simple avisynth script of FFVideoSource().AssumeTFF().SeparateFields() will show. Both FFVideoSource and DirectShowSource handle the videos I mentioned just fine. Only LWLibavVideoSource is giving wrong output, which is why I said it's probably a bug.


I can't get why FFVideoSource and DirectShowSource handle it correctly(?).

Edit: note that L-SMASH Works doesn't seek by PTS but frame or picture number unlike FFVideoSource and DirectShowSource.

[VFR maniac]

I think I have a bug to report. Upon trying to inverse telecine some ads, I realized I was getting weird artifacting. Upon inspection with a script of just LWLibavVideoSource("video").SeparateFields(), I found that the field order became completely messed up part way through the video. It was fine in the first half or so, but then started messing up some point after. Trying the script with both AssumeTFF() and AssumeBFF() didn't work, and trying LWLibavVideoSource with a dominance of both 1 and 2 didn't work. I've tried it on some other telecined material and it has the same issue. I'm using r715, by the way. I've also had this issue confirmed by a friend of mine who was using r714.

Here is one of the files in question (https://dl.dropboxusercontent.com/u/42171557/00011.m2ts) that it was having trouble displaying correctly. This video is a mix of progressive and telecined material. It starts having the field ordering issues once it reaches the Arata Kangatari ad around 1:20. Although do note that this issue also happened with a video that was a mix of pure interlace and telecine and also a video that was just purely telecine. The one purely interlaced video I tried it with worked perfectly fine (aside from the script causing mpc to crash near the end, but the video encoded fine with x264 at least)

edit: a correction about the sample video I gave in this post. it's a mix of pure interlaced and telecined. Not sure why I said it was progressive.

Sorry, this is a bug of workaround for auto construction of a frame from a pair of field coded picture.
The cause comes from that the first some pictures have repeat=0 i.e. are signaled as field coded since the stream starts at non-IDR picture and libavcodec parser misdetects picture parameters.

Edit: Fixed at rev717: https://github.com/VFR-maniac/L-SMASH-Works/commit/0c4d9dfec0363096fc4ca5db09a9c62f9ad55499

[yipeskop]

The repository in the OP that hosts the binary builds of lsmash-works hasn't seemed to have updated since r715, and I was rather looking forward to trying out the newest version to see if it actually fixed the bug I was experiencing.

Could someone upload a build of the latest version please? I'd compile it myself, but I don't really know what I'm doing.

[the_weirdo]

Could someone upload a build of the latest version please?

You can try this build (https://dl.dropboxusercontent.com/u/18695757/L-SMASH-Works-r717-32bit.7z). 32-bit only and you need to install MSVC++ 2013 Redist (x86) (http://go.microsoft.com/?linkid=9832156) if you don't have it installed already.

[yipeskop]

Hey thanks, both of you!

The bug seems to have been mostly fixed. All the test files that were giving me trouble before are now working just fine.

There's just one small issue left. Using LWLibavVideoSource on these files without specifying the field dominance results in the field dominance becoming incorrectly reversed part way through the video. You can see this at 1:22 in the first example video I posted earlier and at 1:14 in the second example video I posted earlier. For reference, this issue does not happen with FFVideoSource.

The script I used to verify this issue was again just simply
LWLibavVideoSource("video").SeparateFields()

This is very easily worked around, though, by simply using AssumeTFF() or AssumeBFF() as needed, forcing the whole input to be read as TFF or BFF. Changing the values for the dominance argument for LWLibavVideoSource didn't seem to effect those two videos one way or another, however.

Again, thank you though. With LWLibavVideoSource, I now actually have something that can handle m2ts files without any annoying issues, like FFVideoSource has.

[burfadel]

You can try this build (https://dl.dropboxusercontent.com/u/18695757/L-SMASH-Works-r717-32bit.7z). 32-bit only and you need to install MSVC++ 2013 Redist (x86) (http://go.microsoft.com/?linkid=9832156) if you don't have it installed already.

Did you build that yourself?

Maybe a run through on how to compile it would help some people out :).

Even better would be someone new to upload optimised compiles to somewhere. That r717 build seems a little quicker than those that were on the google repository.

[the_weirdo]

Did you build that yourself?

Maybe a run through on how to compile it would help some people out :).

Even better would be someone new to upload optimised compiles to somewhere. That r717 build seems a little quicker than those that were on the google repository.

Yes, I built that myself. However, I didn't use any special config for that build. Don't know why there's difference in performance (cann't reproduce on my computer, though), as I believe his builds and mine might be using the (almost) same build environment.

[burfadel]

Ah ok, that's interesting then!

I would build it myself and make some optimised builds and upload it somewhere (and keep them updated), but I tried doing that a couple of months ago and couldn't get it to work. Can you explain how you compiled it so I can work out where I am going wrong?

Thanks!

[Reel.Deel]

Downloads from https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing seem to be gone. :(

-----

@the_weirdo

Thanks for r717.

[Taurus]

Downloads from https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing seem to be gone. :(


It is working here...
Maybe a server hickup? :p

[filler56789]

A couple of hours ago, there was no L-Smash Works 717 archive in that folder :confused:
Anyway, Google keeps sucking too much at file sharing :mad: :p

[LigH]

So far I never had problems with MediaFire yet...

[CarlPig]

r720 is available on Google Drive, check link from post #177

[burfadel]

r720 is available on Google Drive, check link from post #177

It is now. It wasn't updated for a little while, and R717 was missed, and there were no downloads there for a few days.

It's good that it's up though! Ready to use, properly done binaries are important for projects such as this, as not everyone wants to build. They would more likely go to an alternative, even if it isn't as good if they had to.

[siella]

LWLibavAudioSource
This function uses libavcodec as audio decoder and libavformat as demuxer

LSMASHAudioSource
This function uses libavcodec as video decoder and L-SMASH as demuxer

is the main difference only demuxer way?

[LigH]

As far as I know, yes; L-SMASH demuxer is specifically for the MP4 container. In general, the libavformat demultiplexer supports MP4 too, L-SMASH is probably only required for very special issues.

P.S.: Both use audio decoders.

[LigH]

But the disadvantage that it supports only MP4 containers, correct?

[AMED]

Thanks for your work!

There seems to be a memory problem with all builds which I have tried (702 to 715). I am using it from within AviSynth+ (r1576) - but have tried also other AviSynth versions. The script will be called from within MeGUI several times (auto crop, deinterlace detection, encoding, ...) and after a while a script cannot be opened anymore with the error "[Fatal]: Failed to avformat_open_input." It can then be noticed that the memory consumption of the MeGUI process is high (up to 2GB) and it will not be freed when the script is closed. I have to close MeGUI and then the last operation can be continued. Also other users have the same problem: http://forum.doom9.org/showthread.php?p=1676500#post1676500

I have to try it with other programs as well (e.g. VirtualDub), but with other source filters I do not have the problem (ffms, dgindex, dgindexnv, ...) - only exception is the c-plugin of ffms which also seems to have a memory leak.
EDIT: Just tried it with VirtualDub. I opened and closed a simple script
LWLibavVideoSource("C:\test.mkv.lwi")
pointing to test.mkv - lwi size is ~50 MB. During every open/close cycle the memory increase and will not be freed completly.
I made those tests with r715 v2.
Has there been any luck with this problem reported by Zathor?

I have tested R720 and can see that it's still not releasing memory.

[Reel.Deel]

Has there been any luck with this problem reported by Zathor?

I have tested R720 and can see that it's still not releasing memory.

Not yet, the issue is is open. (https://github.com/VFR-maniac/L-SMASH-Works/issues/28)

[Groucho2004]

I have tested R720 and can see that it's still not releasing memory.
I have tried to reproduce this issue but no matter how many times I re-load in VDub or Avsp, it releases the memory as it should.

AVS+ r1576 (32 Bit)
LSMASH r720v2
WinXP 32

[Zathor]

I use the Process Explorer to check the memory usage. And with every closing/opening cycle I see a steady increase in the memory usage (e.g. the peak values). Currently I am testing with a 1080p movie and with every cycle I get ~5MB more.

VirtualDub 1.9.11
LSMASH r720v2 (32bit)
AVS+ r1576 (32bit) and AVS 2.5.8 (plain, 32bit)
XP (32bit)

[Groucho2004]

I use the Process Explorer to check the memory usage. And with every closing/opening cycle I see a steady increase in the memory usage (e.g. the peak values). Currently I am testing with a 1080p movie and with every cycle I get ~5MB more.

VirtualDub 1.9.11
LSMASH r720v2 (32bit)
AVS+ r1576 (32bit) and AVS 2.5.8 (plain, 32bit)
XP (32bit)
Tried exactly that, still releases the memory properly. Maybe it's the splitter you're using. Try loading the raw stream into LWLibavVideoSource.

[Zathor]

Correct. With a raw avc stream there is no leak, but when muxed into MKV there is one.

[Zathor]

After a few limited tests it seems that r725 fixes the memory leak when using a container. I have to do more tests yet, but looks promising.

[AMED]

I'm still seeing the memory leak with r725 when using MKV. It is much better than previous versions though. I'm seeing about a 50MB increase with every bluray movie job when using One Click Mode in MeGUI build 2500.

[VFR maniac]

I fixed a memory leak of files with audio stream @ rev724 (https://github.com/VFR-maniac/L-SMASH-Works/commit/7c1dddbe3e3114e4b2582a303aa8c3fc13457930).
I cannot replicate any memory leak now, and it is difficult to debug unless any sample is supplied.

[AMED]

Here is a sample (https://www.mediafire.com/?dgaa17v2cztlzek).

[VFR maniac]

Here is a sample (https://www.mediafire.com/?dgaa17v2cztlzek).

I can't replicate the issue.
I think your memory leak is not derived from L-SMASH Works.

[AMED]

Thanks for taking a look. I shall look elsewhere for the cause of this problem.

[fvisagie]

Hi All,

When I open many files as in

...
AudioDub(LWLibavVideoSource("20140510154111.mts"), LWLibavAudioSource("20140510154111.mts")) ++ \
AudioDub(LWLibavVideoSource("20140510154135.mts"), LWLibavAudioSource("20140510154135.mts")) ++ \
...

either of LWLibavVideo/AudioSource() would at some point fail as follows

LWLibavAudioSource: failed to get the audio track.
(C:\Users\fvisagie\Videos\Home Videos\20140510 Collene & Kallie Pre-shoot\1. Footage.avs, line 38)


I'm using Avisynth 2.6.0 Alpha 4 with L-SMASH WORKS r725 on Windows 7 Pro SP1 32-bit. The machine has 4GB RAM and a quad-core i5-2540M.

Setting higher-than-default values with SetMemoryMax() makes no difference I could notice.

The failure happens anywhere from the 38th to the 41st input, but it always occurs when the Avisynth parent process gets to about 1666MB RAM usage as files are opened. At that point, total physical memory utilisation across all processes is only ~75%, meaning that not even physical memory has been exhausted, let alone virtual memory.

Another interesting observation: when I reduce the number of plugin threads, more files can be opened. The lower the number of threads, the less the amount of memory used per file and the more files that can be opened.

In that vein, keeping threads at e.g. 3 and adding more and more files to increase memory usage, once 1666MB is reached Avisynth still fails. In this case no LWLibavVideo/AudioSource() message is generated, but instead the host application would fail with some strange error. For example, Windows Media Player complains about the video card and AvsPmod lists a string of Python errors in its Error Window.

The bottom line is that whichever of threads or files I increase, once the usage of ~1666MB has been reached Avisynth fails.

Because not even physical memory has been exhausted by that point, Avisynth and/or the plugin hasn't run into a platform resource limitation; the problem must be something else.

Where does this problem lie, and what are the prospects for fixing it?

Many thanks,
Francois

[Groucho2004]

What do you use to open the script?

Also, the max. user process memory on a 32 Bit OS is 2Gb. Your 1666 MB are pretty close to that limit, no surprise there.

Reducing the number of threads to 1 for each call should enable you to open more files.

[fvisagie]

What do you use to open the script?

AvsPmod for editing, and Windows Media Player, VirtualDub, MPC-HC etc. for comparison.

Also, the max. user process memory on a 32 Bit OS is 2Gb. Your 1666 MB are pretty close to that limit, no surprise there.

Reducing the number of threads to 1 for each call should enable you to open more files.

I've tried that, thanks, but then it's ssslllooowww!!!!!


PS. Would moving to 64-bit Windows help (my machine has a 64-bit CPU), or would 32-bit AVS still be a limiting factor?

[Groucho2004]

I've tried that, thanks, but then it's ssslllooowww!!!!!Could you load more clips?

BTW, if you have access to a 64 Bit OS you could try Avisynth+ 64 Bit. It *might*(not sure) allow you to load more clips. But then you would need to use VirtualDub 64 Bit to open the script.

[SamKook]

Last time I reached 75% RAM utilisation in windows, it started to try and use the pagefile(which I had disabled since 75% = 12GB for me) and everything started to get unstable and crashing. Not sure why exactly it doesn't want to use the rest of the RAM whitout acting weird though.

If the software you use to load the avisynth script is large adress aware, you can get to close to 4GB before it will crash on a 64 bit OS instead of 2GB on a 32bit OS. If the software isn't(like virtualdub), there are application to switch the flag in the exe.

[qyot27]

/LARGEADDRESSAWARE might mitigate the issue a little on 32-bit, but good luck trying to get a hold of large address aware builds of everything in the toolchain.

Also, the /3GB flag would need to be set on the 32-bit OS to let it know it can go higher.

[LigH]

It is probably more useful to concatenate the MTS segments somehow before processing them (e.g. convert to a contiguous MKV); furthermore, L-SMASH Source supporting playlists may be useful, especially for Blu-ray sources.

But I am not certain if that would work reliably in your case, the segment filenames seem to be based on DVB recordings, not Blu-ray disks. If they contain different programmes (e.g. a different set of audio streams), concatenating may fail.

[fvisagie]

Thanks for the suggestions.

It is probably more useful to concatenate the MTS segments somehow before processing them

Barring one drawback, this works well for me, concatenating multiple (AVCHD) M2TS to M2TS with ffmpeg. The drawback is that while the camera records one scene per file for convenient editing, those scene transitions are lost in concatenation. Do you know of a way to record scene transitions when concatenating with ffmpeg, perhaps with the aid of shell scripting? I've tried all sorts of things but nothing so far looks even remotely promising.

[fvisagie]

does LWLibavVideoSource export useful global variables like FFMS2 (SAR, matrix, tv/pc range, cfr & vfr time) ?

I strongly support the addition of global variables. In my case specifically, a variable to identify the current source file at runtime. It would enable logging scene changes when concatenating source files (http://forum.doom9.org/showthread.php?p=1681933#post1681933), needed to work around memory usage issues (http://forum.doom9.org/showthread.php?p=1681983#post1681983) when using L-SMASH Source.

Thanks,
Francois

[Music Fan]

r726 ;
https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing

Extract of changelog ;
r726: git-7a8d8a7 [2014-05-22] lwmuxer: Stop using deprecated movie parameters.
r725: git-92d69d8 [2014-05-14] Bump copyright years to 2014.
r724: git-7c1dddb [2014-05-13] lwlibav_audio: Fix memory leak of audio frame list.
r723: git-e4ca061 [2014-05-12] lwindex: Fix handling of file path.
r722: git-5d5add8 [2014-05-12] libavsmash: Fix compilation error on debug build.
r721: git-c9c67e6 [2014-05-08] lwindex: Override stream with AV_DISPOSITION_ATTACHED_PIC
r720: git-3548f58 [2014-05-03] lwmuxer: Use new I/O APIs.
r719: git-8e176da [2014-05-03] lwdumper: Use new I/O APIs.
r718: git-d0e0961 [2014-05-02] libavsmash: Use new I/O APIs.
r717: git-0c4d9df [2014-04-11] lwindex: Don't treat as field coded picture if picture seems corrupted.
r716: git-2242b10 [2014-04-08] libavsmash: More QuickTime Audio support.
r715: git-4ada105 [2014-04-05] lsmashsource: Fix stack mode when AVX2 instructions are available.
r714: git-f8890ff [2014-02-17] utils: Limit framerate numerator strictly up to INT32_MAX.
r713: git-dd17b77 [2014-02-14] video: Fix 10L introduced in 2aa7ba260d .
r712: git-1612126 [2014-02-14] video: Improve average framerate calculation more.

[Reel.Deel]

I recently added LSMASHSource to the wiki (http://avisynth.nl/index.php/LSMASHSource) (with VFR maniac's consent) and I would like to add additional information since the included readme seems a little vague (at least to me).
I searched this thread for useful information and so far I have this:


L-SMASH Works depends on liblsmash, libavutil, libavcodec, libavformat, libswscale and libavresample.

I added supporting of a hack of high bit-depth input between rev594 and rev603.
For interleaved format (at default), only little endianness output is supported currently i.e. LSB comes at the first byte and MSB comes at the second.
Stacked format is also available but direct rendering is always not available if used.


LSMASH*Source() is for MOV, ISO Base Media and its derived file formats.
LSMASH*Source() uses libavformat only for the first decoder initialization, and demuxes streams by using L-SMASH demuxer API.

Apple ProRes?
Haha, I guess the strange output from LWLibavVideoSource is high bit-depth interleaved format.
You may feel FFMS2 outputs correctly but, the fact, the output loses accuracy around 2-bit for each Y'CbCr component.
Try format="YUV422P8" or stacked=true.

Edit and Note: currently libavcodec ProRes decoder supports only Y'CbCr 4:2:2 10-bit and 4:4:4 10-bit format with or without alpha channel.
Therefore, LWLibavVideoSource(source="ProRes") always output in interleaved format unless user specifies output format.
And even if ProRes4444 (12-bit) is input, the default output format will be Y'CbCr 4:4:4 10-bit with alpha.

Libavcodec decoders output by such format; [LSB 8 | zero 6 | MSB 2] for 10-bit Y'CbCr.
As the default, the postprocessor after decoding works as just copying data delivered from decoder into the AviSynth video buffer.
Basically I believe that data shall not be modified unless user, decoder or demuxer specifies.
10->16 change may add something of dither instead of simple bit-shifting.

Use format="YUV4**P16" if you need the format [LSB 8 | MSB 8].

Besides, LSMASH*Source has the advantage over LWLibav*Source that it doesn't need to create index file for supported formats.

Anyone know of any other advantages/disadvantages and or any other limitations of LSMASHSource?

----

One more thing, the readme list all supported video formats but for 12 and 14-bit formats it says 'ffmpeg only', what does that really mean?

Example:
"YUV422P10"
"YUV444P10"
"YUV420P12" (ffmpeg only)
"YUV422P12" (ffmpeg only)
"YUV420P14" (ffmpeg only)
"YUV422P14" (ffmpeg only)
"YUV420P16"
"YUV422P16"

Any insight will be appreciated.

[VFR maniac]

One more thing, the readme list all supported video formats but for 12 and 14-bit formats it says 'ffmpeg only', what does that really mean?


Libav's libavutil and libswscale have no support of 12 and 14-bit formats.
These formats may or may not be supported by libav in the future.

[qyot27]

Edit: already answered.


One more thing, the readme list all supported video formats but for 12 and 14-bit formats it says 'ffmpeg only', what does that really mean?

Example:
"YUV422P10"
"YUV444P10"
"YUV420P12" (ffmpeg only)
"YUV422P12" (ffmpeg only)
"YUV420P14" (ffmpeg only)
"YUV422P14" (ffmpeg only)
"YUV420P16"
"YUV422P16"
Any insight will be appreciated.
It means that if you want support for 12-bit and 14-bit pixel formats, you need to build against FFmpeg.

http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/pixfmt.h

http://git.libav.org/?p=libav.git;a=blob;f=libavutil/pixfmt.h

Compare: only FFmpeg contains those pixel format markers. Libav doesn't.

[Reel.Deel]

Thanks for the quick response VFR maniac and qyot27. :)

So if you load any 12/14-bit source will it be truncated to 10-bits?

@VFR maniac

One more thing:

10->16 change may add something of dither instead of simple bit-shifting.

Does that mean if you have a 10-bit source and force it to stack16 (stacked=true, format="YUVXXXP16") it will be dithered to 16-bits rather than just shifting the bits? You said may add dither so I'm not sure.

[VFR maniac]

I don't know so deep about the internal behaviour of libswscale, but at least ffmpeg's libswscale has options about dither and set to auto by default.
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libswscale/options.c

Libav's libswscale has no options about dither.
https://git.libav.org/?p=libav.git;a=blob;f=libswscale/options.c

[Reel.Deel]

ok, thanks for the answer VFR maniac.

If anyone knows a bit more on this matter please share.

[fvisagie]

Thanks for this initiative, Reel.Deel :thanks:

[Daemon404]

So if you load any 12/14-bit source will it be truncated to 10-bits?

Only if built with FFmpeg.

Does that mean if you have a 10-bit source and force it to stack16 (stacked=true, format="YUVXXXP16") it will be dithered to 16-bits rather than just shifting the bits? You said may add dither so I'm not sure.

It will be bitshifted, unless there is no direct path between formats, then all bets are off. yuvXXXp10 -> yuvXXXp16 should just be a bitshift in swscale.

[Reel.Deel]

@Daemon404

Thanks for the info.

---------

@everyone

r728 is available (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing) - Support for RGB32 and Y8 in Avisynth.

[qupfer]

@everyone

r728 is available (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing) - Support for RGB32 and Y8 in Avisynth.

Thanks,

but google says, I need permission, so I cliked on Request access (two times :o). Will this be enough or I have to do additional things?

[Music Fan]

@everyone

r728 is available (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing) - Support for RGB32 and Y8 in Avisynth.
This link don't work anymore, is there another server for r728 ?

[filler56789]

Geez, this is the error message G00gle Drive gave me:

You need permission

Want in? Ask the owner for access, or switch to an account with permission. Learn more (https://support.google.com/drive/answer/53355?hl=en)

You are signed in as ***.***@gmail.com.

Seriously, I think open-source doesn't go well with unreasonable access restrictions.

[filler56789]

For the time being, r728 is available at:

http://www.mediafire.com/download/m8fa458q8zzjuae/L-SMASH-Works_r728-g34b1526.7z

[Reel.Deel]

Here's a direct download for r728: [Dropbox (https://dl.dropbox.com/s/u7qdfhukuq24fdo/L-SMASH-Works_r728-g34b1526.7z)]

FWIW here's the build script for L-SMASH Works (https://github.com/nak5124/build_env/blob/master/buildscripts/lsw.sh).

[Music Fan]

Thanks.

[qupfer]

Hi Guys,

I have a MeGui-Generated avs-File for the audio-stream of a tv-recording.
LWLibavAudioSource("Path\to\Movie.ts", stream_index=1)

With with tool(s) can I play/decode it? (except MeGui)
ffmpeg doesn't do it. (and its compiled with --enable-avisynth)

[Groucho2004]

Hi Guys,

I have a MeGui-Generated avs-File for the audio-stream of a tv-recording.
LWLibavAudioSource("Path\to\Movie.ts", stream_index=1)

With with tool(s) can I play/decode it? (except MeGui)
ffmpeg doesn't do it. (and its compiled with --enable-avisynth)
Post the complete script. You should be able to open/run the script in MPC or VirtualDub.

ffmpeg doesn't do it.
Somehow I doubt that this is the error message you get from ffmpeg. :rolleyes:

[qupfer]

Thanks,
okay the complete script


LoadPlugin("D:\Users\Henning\Dropbox\MeGUI\tools\lsmash\LSMASHSource.dll")
LWLibavAudioSource("E:\convert\temp\test.ts", stream_index=1)
# detected channels: 2 channels
# detected channel positions: 2/0/0



ffplay output:


ffplay version N-64495-g154954c Copyright (c) 2003-2014 the FFmpeg developers
built on Jul 8 2014 00:30:36 with gcc 4.8.2 (GCC)
configuration: --arch=x86_64 --target-os=mingw32 --cross-prefix=/home/username/sandbox/mingw-w64-x86_64/bin/x86_64-w64-mingw32- --pkg-config=pkg-config --enable-gpl --enable-libx264 --enable-avisynth [...]
libavutil 52. 91.100 / 52. 91.100
libavcodec 55. 68.101 / 55. 68.101
libavformat 55. 45.100 / 55. 45.100
libavdevice 55. 13.101 / 55. 13.101
libavfilter 4. 10.100 / 4. 10.100
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100
nan : 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
E:\convert\temp\test.avs: Unknown error occurred

[Groucho2004]

LoadPlugin("D:\Users\Henning\Dropbox\MeGUI\tools\lsmash\LSMASHSource.dll")
LWLibavAudioSource("E:\convert\temp\test.ts", stream_index=1)
# detected channels: 2 channels
# detected channel positions: 2/0/0

Open the script in VirtualDub and post the error message (if any).

[qupfer]

Open the script in VirtualDub and post the error message (if any).


Vdub says: Video has no video stream :rolleyes: but I found the problem (and solution).

I mixed up with the architectures. Avisynth 32bit, ffmpeg 64bit. If I use a 32bit ffmpeg, all fine. :thanks:

[LigH]

The output won't have a video stream, only tools which can handle audio-only AviSynth output as their input (e.g. avs2wav / wavi / avs2pipemod, and MeGUI's audio conversion part) may accept it.

And yes, keeping the same architecture is a prerequisite.

[foxyshadis]

If that's all you need, Avisynth(+) and L-SMASH are both available in 64-bit. Transitioning to 64-bit with its speed increases is quite possible.

[burfadel]

Any newer builds?

[Brazil2]

Any newer builds?
And GCC binaries of L-Smash (muxer, remuser, etc) which will run on XP as well, since they seem not to be available from http://otsukemono.blogspot.jp anymore and the Google drive he used is down :(

I wonder why it's so hard to find binaries of this project.

[bennynihon]

When I try using LSMASHVideoSource I get "System Exception - Access Violation". This is the case for both x86 and x64 builds. LWLibavVideoSource, which uses the lilbavformat as the demuxer, works fine. This is using the r278 build from the links above. Any ideas why this is? Does this have anything to do with the msvcr120.dll included in the package? Am I supposed to place that in the System32 directory? Looks as though I already have msvcr120.dll in both System32 and SysWOW64

[LigH]

LSMASHVideoSource is only suitable for MP4 and similar ISO-MOV based container sources. Do not use it with any other container format.

Do not rely on any included MSVCR*.DLL; instead, rather install the Microsoft Visual C++ Runtime for 32 bit (and possibly also for 64 bit if you have a 64 bit Windows 7+), this will ensure that the appropriate version of several DLLs will be installed to the matching version of the system32 directory (depending on 32 or 64 bit runtime, and 32 or 64 bit OS; furthermore, MSVCR###.DLL is not the only required DLL).

[bennynihon]

thanks. yeah, I am using the msvcr*.dll files from the VC++ redistributables.

[Reel.Deel]

LSMASHVideoSource is only suitable for MP4 container sources. Do not use it with any other container format.
VFR maniac says differently :)
LSMASH*Source() is for MOV, ISO Base Media and its derived file formats (http://en.wikipedia.org/wiki/ISO_base_media_file_format).

I've successfully opened .mov from my DSLRs, .mp4/mov from multiple camera phones, .m4v and .mov from iTunes, and .3gp from my ancient phone. Additionally, Apple has sample files for download (http://support.apple.com/kb/ht1425) and LSMASHVideoSource works for all of them except for sample_mpeg2.m2v and sample_sorenson.mov.

[foxyshadis]

Those are all essentially the same format. MP4 is mostly a subset of MOV, and 3GP/3G2 are subsets of MP4. You could say that L-SMASH is only for MP4-like containers.

[Reel.Deel]

Yeah you're right, I just wanted to clarify (for future readers). Saying 'LSMASHVideoSource is only suitable for MP4 container...' is kinda misleading.

[LigH]

Well, yes, sorry, I always forget that "MP4" is a too strict restriction. But I take MOV not much more serious than AVI for personal reasons, would always recommend the "intentionally best matching container for the content"... ;)

[Brazil2]

Erm, cough, does anyone know where to find up to date binaries of L-Smash (not Works but muxer, remuxer, etc) which will run on XP ? Preferably GCC compiled.

[burfadel]

Unfortunately without up to date and properly compiled binaries (ones that aren't slow), L-SMASH Works could end up 'dying' like so many other great projects. Why you may ask? Well, quite simply if people can't download it they can't use it! Also, many are turned away if there is a significant time between builds. Realistically it needs a 'daily' build, like MPC-HC gets. Sure, there may be a week or two between commits, but that doesn't matter, the nightly build only needs updating when new commits are made. The same probably can be said for FFMpegSource, since they, in many ways, compliment each other.

[Kurtnoise]

Erm, cough, does anyone know where to find up to date binaries of L-Smash (not Works but muxer, remuxer, etc) which will run on XP ? Preferably GCC compiled.

- l-smash x86 (http://www.mediafire.com/download/jt6ffwhccrrn1yr/l-smash_x86_20140801.7z)
- l-smash x64 (http://www.mediafire.com/download/9kb218lm1om6iih/l-smash_x64_20140801.7z)

[Brazil2]

- l-smash x86 (http://www.mediafire.com/download/jt6ffwhccrrn1yr/l-smash_x86_20140801.7z)
- l-smash x64 (http://www.mediafire.com/download/9kb218lm1om6iih/l-smash_x64_20140801.7z)
Thanks a lot! :)

[burfadel]

- l-smash x86 (http://www.mediafire.com/download/jt6ffwhccrrn1yr/l-smash_x86_20140801.7z)
- l-smash x64 (http://www.mediafire.com/download/9kb218lm1om6iih/l-smash_x64_20140801.7z)

Any possibilities of being the new L-SMASH Works build guy? lol, thanks :).

[Kurtnoise]

I can provide l-smash builds as requested from time to time but not l-smash-work because it's a pain to compile (at least for me)...

[burfadel]

Ah ok :). I would compile it myself but have had issues compiling in the past as well. Thought it was just me :D.

[masterkivat]

The usual guy from where I was downloading "l-smash works" (yet other binaries like custom x264 builds) stopped (http://otsukemono.blogspot.jp/), it's a shame.
Hope that more people get interest in sharing their own compiled versions, which is something that I don't master :D

[burfadel]

The usual guy from where I was downloading "l-smash works" (yet other binaries like custom x264 builds) stopped (http://otsukemono.blogspot.jp/), it's a shame.
Hope that more people get interest in sharing their own compiled versions, which is something that I don't master :D

Yeah, quickest way for a project to die is the unavailability of binaries. If people can't get binaries they can't use it!

[the_weirdo]

You can get my L-SMASH-Works builds here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0). Require Visual C++ Redist 2013 (32-bit (http://go.microsoft.com/?linkid=9832156), 64-bit (http://go.microsoft.com/?linkid=9832146)) and Windows Vista or later.

Also my L-SMASH builds can be found here (https://www.dropbox.com/sh/7jjrz5i4wcxhf49/AADZlN98OhKAvLHVwfaXYK4da?dl=0).

[LigH]

:thanks: for maintaining their availability.

[masterkivat]

:thanks:, "weirdo"-san. :D

[bennynihon]

Is there a way to mux in a subtitle track using the L-Smash muxer? What about setting one of two audio tracks as the default track? Thanks

[burfadel]

Here are my builds:
L-SMASH Works r729 32-bit (https://dl.dropboxusercontent.com/u/18695757/L-SMASH-Works-r729-32bit.7z)
L-SMASH Works r729 64-bit (https://dl.dropboxusercontent.com/u/18695757/L-SMASH-Works-r729-64bit.7z)
Require Visual C++ Redist 2013 (32-bit (http://go.microsoft.com/?linkid=9832156), 64-bit (http://go.microsoft.com/?linkid=9832146))

Thanks, very much appreciated!

[gnol009]

Any chance for FFinfo() in FFMS2.avsi can work with LWLibavVideoSource()?

[LigH]

Probably only if L-SMASH Works would expose similar internal variables as FFMS2. The support has to start in the plugin DLL.

[Reel.Deel]

@Selur

Can you please update the links in the first post with the link here (http://forum.doom9.org/showpost.php?p=1689573&postcount=250). And also make it clickable :)

[foxyshadis]

Looks like WebM/VP9 decoding is completely broken in the latest builds. Oh well, I have a copy from 2013 that seems to work right, I can use that just for webm.

[Are_]

Not a single problem here at my linux box with my own compiles. Linked against ffmpeg and using vapoursynth filter.

[Reel.Deel]

Looks like WebM/VP9 decoding is completely broken in the latest builds. Oh well, I have a copy from 2013 that seems to work right, I can use that just for webm.

Do you know which version from 2013?

[VFR maniac]

Looks like WebM/VP9 decoding is completely broken in the latest builds. Oh well, I have a copy from 2013 that seems to work right, I can use that just for webm.

I had already gotten a report and a sample of VP9-in-WebM from someone through ask.fm and 2ch.
And he says that binaries linked with ffmpeg have the problem but with libav have no.
I'll look into this later.

[fvisagie]

You can get my L-SMASH-Works builds here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0). Require Visual C++ Redist 2013 (32-bit (http://go.microsoft.com/?linkid=9832156), 64-bit (http://go.microsoft.com/?linkid=9832146))

Also my L-SMASH builds can be found here (https://www.dropbox.com/sh/7jjrz5i4wcxhf49/AADZlN98OhKAvLHVwfaXYK4da?dl=0).

Many thanks for helping keep this alive :).

What is the difference between the builds in the top-level folder linked (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0) and those in the with-Libav (https://www.dropbox.com/sh/3i81ttxf028m1eh/AABKDekYfeh-6Lv6Pkz_eLcEa/with-Libav?dl=0) subfolder? They both seem to support the LWLibav...Source() functions, so I'm a little confused by the distinction between these different builds.

[the_weirdo]

What is the difference between the builds in the top-level folder linked (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0) and those in the with-Libav (https://www.dropbox.com/sh/3i81ttxf028m1eh/AABKDekYfeh-6Lv6Pkz_eLcEa/with-Libav?dl=0) subfolder? They both seem to support the LWLibav...Source() functions, so I'm a little confused by the distinction between these different builds.

Those builds in top folder are linked with FFmpeg libraries, while those builds in "with-Libav" are linked with... Libav libraries. You can read the differences between FFmpeg and Libav here (https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav). However, in general, they should work the same. Some cases, FFmpeg builds may be better than Libav builds, or vice versa.

[fvisagie]

Thanks, that explains a lot.

I'd like to stick with what worked for me from the now-dead download link (https://drive.google.com/folderview?id=0BwV03nn6LPd9OXJUWVVMMXZmNUU&usp=sharing) before. Comparing the LSMASHSource.dll size of L-SMASH-Works_r725-g92d69d8.7z I got from there and also looking at the build_info.txt shipped with that version
L-SMASH-Works r725 ( lwinput.aui, lwmuxer.auf, lwdumper.auf, lwcolor.auc, LSMASHSource.dll, vslsmashsource.dll )

Source:
L-SMASH-Works: git-92d69d8 ( https://github.com/VFR-maniac/L-SMASH-Works )
L-SMASH: git-4433160 ( https://github.com/l-smash/l-smash )
FFmpeg: git-87f2d80 ( http://git.videolan.org/?p=ffmpeg.git )

seem to suggest it was built with FFmpeg, correct?

[foxyshadis]

Do you know which version from 2013?

r688v2 from this thread (https://www.dropbox.com/s/pok2p8kygc06t5d/L-SMASH-Works_r688v2.7z). It's dated August 30, 2013, but it was just the first that came up when I searched for old versions.

[the_weirdo]

seem to suggest it was built with FFmpeg, correct?

AFAIK, yes.

[fvisagie]

AFAIK, yes.

Thank you.

[fvisagie]

How much might a media file filter (and Avisynth) benefit from hardware accelerated decoding? On the face of it, more CPU power should become available for actual script processing?

It seems FFmpeg has been supporting hardware acceleration since around March 2014, although the documentation (http://ffmpeg.org/ffmpeg-all.html#Advanced-Video-options) is very modest about performance. Would it be feasible supporting that in L-SMASH Source, and would it be worthwhile?

[LigH]

There is already e.g. DGDecNV using Nvidia PureVideo decoder chips V2+, but it has already been reported that V2 and V3 chips are so slow, they just even decode in realtime. Pure software decoding, multithreaded on a multi-core CPU, can be several times faster. So if there is only little filtering, AviSynth has to wait a lot until the decoder chip sends the video data, and if there is a lot of elaborate filtering, the decoding time is marginal in relation to the filtering. With the current fast CPUs and the good multithreaded decoding routines, hardware decoding with these decoder chips is not really worth being called acceleration; but it can be a quite robust and feature-complete alternative decoder (e.g. the libav decoder lacked support for interlaced VC-1 for a long time).

Decoding by PureVideo V5 chips is quite a bit faster, and with QuickSync (DGDecIM) probably even more. They could well be good hardware to assign decoding to. Yet they may not be noticably faster, because there is also some overhead of moving data between system RAM and video RAM. And the more elaborate the filtering, the less impact the decoding will have on the whole filtering time.

[Music Fan]

Another solution to use hardware decoder with avisynth is LAV filter when set on DXVA2 Copy-Back (which doesn't work with XP, you need Vista, Win 7 or more).
Use directshowsource() in avisynth. I read that DSS2() could also work with Haali Splitter.
You may need Win7DSFilterTweaker to choose LAV's directshowsource filter instead of Windows.

One can see if the script is faster with AVSMeter.

[[ReX]]

I originally intended to write a compilation guide for L-SMASH and L-SMASH Works, but it got too long for a forum post.
After lots of pain and agony (:p), I managed to compile everything using GCC and VS2013, you can read the guide here (https://github.com/BrunoReX/build-scripts/blob/master/L-SMASH/readme.md).

[LigH]

Thank you for your efforts. A pity it seems to require Visual Studio, so it won't be possible to integrate it into the media-autobuild_suite easily (which relies on GCC only). Or is that relevant for the *Synth DLLs only?

[[ReX]]

Thank you for your efforts. A pity it seems to require Visual Studio, so it won't be possible to integrate it into the media-autobuild_suite easily (which relies on GCC only). Or is that relevant for the *Synth DLLs only?

Yes, only the AviSynth plugin requires Visual Studio.

[fvisagie]

I'm having trouble getting the plugin to load on 64-bit Windows 8.1.

On a 32-bit Windows 7 Pro SP 1 system it loads fine. On the Windows 8.1 system LoadPlugin() fails with "...error=0xc1".

It makes no difference having the supplied msvcr120.dll in the plugins subfolder or in System32. The supplied DLL has exactly the same File and Product version as the existing one in System32 as well as the same datestamp, but the timestamps differs by 2h40m and the file sizes by 8KB.

EDIT: I should perhaps mention that I tried both the 32-bit as well as the 64-bit DLLs, being uncertain whether the 64-bit version is indicated for 64-bit Avisynth (the version installed is 32-bit), or for 64-bit Windows. The results above pertain to the 64-bit DLL. With the 32-bit DLL the error code is 0x7e, also regardless of whether the supplied 32-bit msvcr120.dll is put in the plugins subfolder or in System32.

What is the cause of this problem and how do I fix it?

Thanks!

[LigH]

Again, and again, and again ...

Applications should never provide a copy of msvc*.dll files, because a) just putting them somewhere may not be enough, and b) they belong to different places, depending on having either a 32-bit or a 64-bit Windows:

Windows 7/8 32-bit: 32-bit DLLs belong to \Windows\System32
Windows 7/8 64-bit: 32-bit DLLs belong to \Windows\SysWOW64 (by overwriting the existing file in \Windows\System32 on a 64-bit Windows, you exchanged the 64-bit DLL with a 32-bit DLL, so 64-bit MSVC 2013 applications will now probably crash from now on)
To avoid any trouble here: Always download the 32-bit Microsoft Visual C++ 2013 Runtime (Redistributable) and run the installer to support 32-bit applications and DLLs built with MSVC 2013 on both 32-bit and 64-bit versions of Windows reliably; it will put at least MSVCR120.DLL and MSVCP120.DLL into the correct directory, depending on your Windows version. For a 64-bit Windows, there are both 32-bit and 64-bit MSVC Runtime installers, with their own set of DLLs.

[foxyshadis]

There are also multiple versions of some msvc* files, since each service pack can get its own despite the identical file name. If the manifests don't match, it won't load. Installing the correct redist will get you everything.

This is supposed to change with MSVC 14 (2015), all future versions will be compatible with any msvcr140 (etc) dlls unless there's a breaking change.

[StainlessS]

With Toolkit 2003 and VS dot net 2003, MS suggest/advise applications each having their own copy of redistributables in their own
directories and not putting them in system32 due to version differences, you can usually find quite a few versions of redistributables
with similar names spread throughout your "Program Files" directory.
You sometimes come across a program or eg Avisynth filter that fails because of missing runtimes, I usually (against MS advise) copy
a collection of these files

mfc70.dll 1,024,000 bytes
mfc71.dll 1,060,864 bytes
msvcp70.dll 487,424 bytes
msvcp71.dll 499,712 bytes
msvcr70.dll 344,064 bytes
msvcr71.dll 348,160 bytes

EDIT: Added files sizes. The 70 variations are from VS dot net 2002.

into system32, I'm not aware of ever having any problems because of this, but I always use the same files (from an old version of nero, I think about v5.0).
EDIT: Think I probably chose the most recent versions that I had available.

[Groucho2004]

With Toolkit 2003 and VS dot net 2003, MS suggest/advise applications each having their own copy of redistributables in their own
directories and not putting them in system32 due to version differences
Do you have a link to that MS statement?

The whole point of using dynamic linking is to have one runtime used by all programs. Well, one runtime for each compiler version.

Instead of putting the runtimes in the program directory one should simply statically link with the appropriate libraries.

[StainlessS]

I dont know where I read that but that is the reason that many copies will be found in Program Files.
According to the first google link I looked at:
There never was a Microsoft Visual C++ 2003 redistributable package released. However, because of the DST changes the US
government made in 2007, Microsoft released a hotfix which includes the 2003 C/C++ runtime in March 2007.
You can download the runtime from the link provided in this thread.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/f6220619-3999-4489-ba5f-09d38dfaefcf/visual-c-2003-71-redistributable-package-x86
EDIT: Link fixed, original posted link would not properley connect for some reason. The download mentioned in above quote is no longer available.

so it looks like they never were considered redistibutable. (at least not in a standard one size fits all)


Just found, this looks similar to what I was talking about but is I think not the original link that I referred to (twas a long time ago).
http://support2.microsoft.com/kb/326922

From above link,
Summary:

When you build an application in Microsoft Visual Studio, and the application uses the C run-time libraries (CRT),
distribute the appropriate CRT DLL from the following list with your application:

Msvcr90.dll for Microsoft Visual C++ 2008
Msvcr80.dll for Microsoft Visual C++ 2005
Msvcr71.dll for Microsoft Visual C++ .NET 2003 with the Microsoft .NET Framework 1.1
Msvcr70.dll for Microsoft Visual C++ .NET 2002 with the Microsoft .NET Framework 1.0

For Msvcr70.dll or for Msvcr71.dll, you should install the CRT DLL into your application program files directory.
You should not install these files into the Windows system directories. For Msvcr80.dll and for Msvcr90.dll, you
should install the CRT as Windows side-by-side assemblies.


More Information:

The shared CRT DLL has been distributed by Microsoft in the past as a shared system component. This may cause
problems when you run applications that are linked to a different version of the CRT on computers that do not
have the correct versions of the CRT DLL installed. This is commonly referred to as the "DLL Conflict" problem.

To address this issue, the CRT DLL is no longer considered a system file, therefore, distribute the CRT DLL with
any application that relies on it. Because it is no longer a system component, install it in your applications
Program Files directory with other application-specific code. This prevents your application from using other
versions of the CRT library that may be installed on the system paths.

Visual C++ .NET 2003 or Visual C++ .NET 2002 installs the CRT DLL in the System32 directory on a development system.
This is installed as a convenience for the developer. Otherwise, all projects that are built with Visual C++ that
link with the shared CRT require a copy of the DLL in the build directory for debugging and execution. Visual C++ 2005
and Visual C++ 2008 install the CRT DLL as a Windows side-by-side assembly on Windows XP and later operating systems.
Windows 2000 does not support side-by-side assemblies. On Windows 2000, the CRT DLL is installed in the System32 directory.

When you distribute applications that require the Shared CRT library in the CRT DLL, we recommend that you use the CRT.msm
merge module that is included with Visual C++ instead of directly distributing the DLL file.


EDIT:
The whole point of using dynamic linking is
Yep, I know. Looks to me like MS made a hash of it and the above advise was their way of fixing the cock-up.

EDIT: As far as the MS 71 (2003) dll's in my system32 are concerned, they are the same as given sizes (in prev post), so looks like
I copied VS ToolKit 2003 dll's to my repository at some point (I usually do the copy to system32 on new system install along with
other standard configurations that I make [I used to also copy gdiplus.dll to system32 but do not remember why].
The copied dll's would not be used by programs that installed their own copies in Program Files application directory, only
by those that were supplied without the dll's, as noted by MS above).

[fvisagie]

Again, and again, and again ...

Thanks, this helped explain and fix the problem.

(by overwriting the existing file in \Windows\System32 on a 64-bit Windows, you exchanged the 64-bit DLL with a 32-bit DLL, so 64-bit MSVC 2013 applications will now probably crash from now on)

Fortunately I was sensible enough to save and restore original files as I went along :).

[StainlessS]

I've only just started playing with L-SMASH source filter and downloaded a couple of test clips to try out.
The first clip in the list here:- http://samples.mplayerhq.hu/asf-wmv/
ie "Alice Deejay - Back In My Life.asf" 13MB
EDIT: Above sample list posted by D9 moderator, so I assume its kosha (not a rule breaker, EDIT: Actual post was parent ie http://samples.mplayerhq.hu/).

MediaInfo:

General
Complete name : D:\CROPTEST\AliceDeejay-BackInMyLife.asf
Format : Windows Media
File size : 13.0 MiB
Duration : 3mn 28s
Overall bit rate : 523 Kbps
Maximum Overall bit rate : 524 Kbps
Movie name : Alice Deejay - Back In My Life
Performer : Presented by http://come.to/mp3mtvhits
Encoded date : UTC 2000-01-05 15:00:32.820

Video
ID : 2
Format : MPEG-4 Visual
Codec ID : MP43
Codec ID/Info : Microsoft MPEG-4 v3 (pre-standard)
Codec ID/Hint : Microsoft
Description of the codec : Microsoft MPEG-4 Video Codec V3
Duration : 3mn 28s
Bit rate : 430 Kbps
Width : 320 pixels
Height : 240 pixels
Display aspect ratio : 4:3
Frame rate : 25.000 fps
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.224
Stream size : 10.7 MiB (82%)

Audio
ID : 1
Format : WMA
Format version : Version 2
Codec ID : 161
Codec ID/Info : Windows Media Audio
Description of the codec : Windows Media Audio V2 - 64 kbps, 44 kHz, stereo
Duration : 3mn 28s
Bit rate : 64.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Stream size : 1.59 MiB (12%)


Opens OK via
FN="AliceDeejay-BackInMyLife.asf"
V=LWLibavVideoSource(FN)
A=LWLibavAudioSource(FN)
AudioDubEx(V,A)


But the audio is cut off after about 4.2 seconds. FFMpegSource plays OK.

[GMJCZP]

I'm starting to use L-Smash and I'm noticing, as with FFMpegSource, the frames of the original video does not match exported, for example, an original video MP4 on your frame 404 coincided with the frame 408 of L-Smash (for Incidentally, as with FFMpegSource), a difference of 4 frames(!). Never have that problem with AviSource, the frames match perfectly.

Why is this so and how can it be remedied?

Edit: with VirtualDub MP4 opening directly apparently decoded correctly. It seems absurd to convert the video to a file Avi lossless and then use AviSource. That's why I'm here.

[LigH]

There are different "splitters" in different source filters: AviSource uses the VfW system of Windows; FFMS2 and L-SMASH Works both use different versions of splitters from libav libraries (ffmpeg or libav variants). As already reported several times, FFMS2 only supports the MKV container reliably (but has some issues with different other containers, even when the Haali Media Splitter is installed, which is used as helper). L-SMASH Works even has two different splitters available: Either LAV Filters for LwLibavVideoSource(), or the L-SMASH splitter for LSMASHVideoSource() — the latter only for ISO Media containers like MP4 or MOV.

Different splitters may treat containers more or less correctly, and some may have issues with specific structures in containers, so they may possibly ignore a few frames in the beginning. But as long as they do that reliably, and ignore always the same frames in both first and second pass of a 2-pass encode, it should at least allow a reliable conversion. With some DirectShow filters, different frames may have skipped between first and second pass, therefore DirectShowSource() may be a risk for 2-pass encoding even.

[GMJCZP]

There are different "splitters" in different source filters: AviSource uses the VfW system of Windows; FFMS2 and L-SMASH Works both use different versions of splitters from libav libraries (ffmpeg or libav variants). As already reported several times, FFMS2 only supports the MKV container reliably (but has some issues with different other containers, even when the Haali Media Splitter is installed, which is used as helper). L-SMASH Works even has two different splitters available: Either LAV Filters for LwLibavVideoSource(), or the L-SMASH splitter for LSMASHVideoSource() — the latter only for ISO Media containers like MP4 or MOV.

Different splitters may treat containers more or less correctly, and some may have issues with specific structures in containers, so they may possibly ignore a few frames in the beginning. But as long as they do that reliably, and ignore always the same frames in both first and second pass of a 2-pass encode, it should at least allow a reliable conversion. With some DirectShow filters, different frames may have skipped between first and second pass, therefore DirectShowSource() may be a risk for 2-pass encoding even.

I noticed this problem a while and now when I'm trying to take action on the matter.

So far the historical sequence in my learning curve with MP4 videos goes like this:
DirectShowSource - FFSource - L-Smash Source.

I tried both flavors of L-Smash source and the result is the same.

[LigH]

Are you able to upload a short sample which provokes this difference, which we can use to compare? It may be necessary to report the exact version numbers of the plugins you are using.

[GMJCZP]

Are you able to upload a short sample which provokes this difference, which we can use to compare? It may be necessary to report the exact version numbers of the plugins you are using.

I use the r729 version. Certainly cost me a lot to get it, did not know there was a wiki page.

For now it's hard to upload a sample, sorry.

[LigH]

Accidently asked elsewhere already ... LAV Filters support VFR when an AVI contains drop frames; for LwLibavVideoSource instead, it would be more useful to repeat the last decoded frame with a constant frame rate, because AviSynth supports only CFR as well.

In the german doom9/Gleitz forum, a user complained that L-SMASH Works instead returns an average frame rate, not repeating the previous of a drop frame, thus creating sync issues. I don't have such samples, but I believe some webcams will use this technique, so I would like someone here to test it or provide a sample for testing. And I hope VFR maniac or anyone with some source code insight can check how the current behaviour is, especially regarding the indexer module for AVIs.

[Lenmaer]

Hi, can someone explain me what's the difference between L-SMASH-Works-r729-20141025 and L-SMASH-Works-r729-20141025-Libav from the_weirdo's dropbox link?

[LigH]

Explained one page ago (http://forum.doom9.org/showthread.php?p=1693941#post1693941).

[Lenmaer]

Oh, thanks a lot.
I missed that.

[GMJCZP]

Correct me if I'm wrong, but with L-Smash I can not adjust the input fps, but I can FFMS, actually once had to resort to the latter for the reason cited.

[Music Fan]

You can just add assumefps(x), the result should be the same.

[the_weirdo]

Correct me if I'm wrong, but with L-Smash I can not adjust the input fps, but I can FFMS, actually once had to resort to the latter for the reason cited.

Currently, L-SMASH Works filters don't support VFR to CFR convertion if that's what you mean.

[LigH]

But does it support drop frames as implemented in AVI (expand the display duration of the previous frame by not changing the output for another frame duration)? Or does it ignore drop frames and treat all remaining non-drop frames (no matter how many drop-frames separated each of them) with equal average duration?

[Lenmaer]

It also doesn't support 3:2 pulldown. One of the nourin BDMVs had one m2ts like that.

[LigH]

Well, IVTC (if it was hard telecine encoded) can be applied later, after decoding, bacause it is (hopefully) a regular field/frame pattern in a CFR video.

But respecting AVI drop frames would have to be supported during the indexing, because it will probably be irregular, and no filter after the decoder will know about the positions of drop frames in the AVI container.

[Lenmaer]

I was able to fix it by changing the framerate of that m2ts to 23.976 with tsmuxer, otherwise it was off.

[GMJCZP]

And what is DSS2?

Here. (https://code.google.com/p/xvid4psp/downloads/detail?name=DSS2%20mod%20%2B%20LAVFilters.7z&can=2&q=) Another link? I got it! Here. (http://forum.doom9.org/showthread.php?p=1699301#post1699301)

To LigH: here (http://forum.gleitz.info/archive/index.php/t-38053.html)

And here (http://docs.aegisub.org/manual/Video) additional information.

In the last link says: "Do note that DSS2 converts variable framerate files to constant"
What do you think? This is what I want but...

[LigH]

DSS2 is a part of the Haali Media Splitter. DSS2Mod added support for LAV Filters as alternative decoders.

"Do note that DSS2 converts variable framerate files to constant" ... But how does it do that? By assuming an equal distance between frames which should have a varying distance instead? Then you will get sync errors.

The usual DirectShowSource(convertfps=true) does this by "resampling" the video, so you may get doubled or missing frames. But at least it will be in sync.

[TheFluff]

DSS2 does the same thing as DSS with convertfps=true. The other alternative would pretty useless.

[GMJCZP]

Here is a testimonial about DSS2:

Here (http://forum.doom9.org/showthread.php?p=1699121#post1699121)

I think the more options about source filters the better.

[cagali]

Hi, I am new to Lsmash.
Just 1 quick question.
Is these 2 avs going to output the same thing for x264-10bit to encode?

I tried and what I get are 2 files with <1% difference in peak bitrate.
I am using megui. The source clip is a YV12/yuv420p8 short segment from a BD m2ts.
Thank you.

avs file 1:
LoadPlugin("LSMASHSource.dll")
LWLibavVideoSource("clip.mkv")

avs file2:
LoadPlugin("ffms2.dll")
FFVideoSource("clip.mkv", threads=1)

And the versions are:
L-SMASH-Works-r729-20141025-32bit
ffms2-2.20-msvc

[LigH]

The source clip is a YV12/yuv420p8 short segment from a BD m2ts.

Uhm, no. There is no raw YV12 on a BD. There may be e.g. MPEG-2, AVC or VC-1 video streams contained in the M2TS. MediaInfo should be able to report important details.

Still, regarding your question: There may be slight differences between decoders in ffmpeg or libav libraries used by either source plugin. Therefore, there may not be a guarantee for bit-identical decoding results; but the differences should be marginal.

[cagali]

Uhm, no. There is no raw YV12 on a BD. There may be e.g. MPEG-2, AVC or VC-1 video streams contained in the M2TS. MediaInfo should be able to report important details.

Still, regarding your question: There may be slight differences between decoders in ffmpeg or libav libraries used by either source plugin. Therefore, there may not be a guarantee for bit-identical decoding results; but the differences should be marginal.

Right. The clip is a AVC clip with colorspace with this info:
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits

[foxyshadis]

Hm, if it was MPEG-2 it would be perfectly understandable, but as it's AVC it should be bit-identical or it's out of spec. I wonder which one is the buggy one? Of course, peak bitrate doesn't tell us anything, actually comparing the two against each other (with mt_makediff) is the only way to tell for sure.

It could also be that x264 didn't encode them identically; while x264 is supposed to be deterministic, in rare cases of lots of threads it can change slightly.

[LigH]

@ the_weirdo:


L-SMASH-Works-r733-20141121-32bit.7z
with-Libav\L-SMASH-Works-r729-20141117-32bit-Libav.7z

Is the revision gap correct?

And do you know if either one has issues with Dolby TrueHD+Atmos audio tracks? I don't have such material, but a user in the german forum may have...

[the_weirdo]

@LigH
Because the VP9 decoding issue when linked with FFmpeg libs has been fixed, I just feel that there's no good reason to use Libav builds over FFmpeg builds anymore, so I don't update them. Only FFmpeg has supported TrueHD streams with Atmos substream, however, I'm not sure if L-SMASH Works builds linked with FFmpeg libs can decode TrueHD+Atmos or not.

EDIT: I can confirm that builds linked with FFmpeg libs have issues with media files that contain TrueHD+Atmos tracks.
EDIT2: Please disregard previous statement. I was wrong about that. It's because my builds being broken. Builds linked with FFmpeg libs can work with those files just fine.

[LigH]

I remember that there was recently an update to at least ignore Atmos extensions gracefully ... but which software was it?

Ah: LAV Filters 0.63.0 can ignore it now (http://forum.doom9.org/showthread.php?p=1695625#post1695625); eac3to may still need an update.

So if LAV Filters can, I wondered if LwLibav could as well. But that might require to port the patch? In the meantime, DDS2Mod might work for AviSynth users.

[the_weirdo]

I've uploaded new builds that linked with Libav libs. Those builds seem to work with files that contain TrueHD+Atmos tracks (though they can't decode those TrueHD+Atmos tracks at all).

EDIT: My bad. Those new builds are broken so I have to pull them down and do more testings before uploading new builds.
EDIT2: As it turned out there's no problem with FFmpeg builds (compare to Libav builds), I won't update Libav builds anymore.

There are some misunderstandings caused by my poor English and bad testing method. So to make thing clearer, builds linked with FFmpeg should be able to decode TrueHD from TrueHD+Atmos tracks (they work with some samples I have) while builds linked with Libav can't decode TrueHD+Atmos tracks at all. As Libav builds now don't offer any advantage over FFmpeg builds, I won't update them anymore.

[LigH]

:thanks:

Ignoring Atmos extensions is fine. As far as I read, their "rendering" is speaker setup dependent... They just should not make demuxing and decoding TrueHD audio tracks fail.

[LigH]

OK, the ffmpeg based L-SMASH Source build r733 was able to load the sample I received; now I hope the other user can handle the whole audio.

[forclip]

LSMASHSource (tested with L-SMASH-Works-r775-20150108-32bit from here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0)) have a memory leak: when indexing unsupported video files, it doesn't freed the memory of the process, and it seems like the whole file is readed into it.
For example

ffmpeg -i "input_file.avs" -vcodec rawvideo -pix_fmt bgra64le -an "output_file.avi"
where "input_file" is a simple AviSynth script:

ColorBars()
Trim(0, 1000)
then load resulting AVI file (2+Gb) into AviSynth (http://forum.doom9.org/showthread.php?t=148782)

LWLibavVideoSource("D:\Temp\output_file.avi")
While indexing, the memory consumption of the process (AvsP, MPC-HC,..) has increased to the same 2+Gb, and after that

LWLibavVideoSource: failed to get the video track.

Unloading the script doesn't freed the memory.

[stax76]

@VFR maniac

I have a small request:

if this is possible from a avs filter, please write indexing progress to stdout.

[LigH]

May be complicated when it is not connected to any console. But possibly via a debug message API?

[stax76]

In StaxRip I run DGIndex exactly like I run almost all command line apps and it receives progress from DGIndex so it must be in the source code and neuron2 must know it.

[qyot27]

But you're still using a separate CLI program that outputs its progress to stdout to do the indexing; DGDecode.dll isn't what powers the indexing in DGIndex. You'd need to look at FFMS2 and how it interacts with ffmsindex to see how to implement this for LSMASHSource.dll, provided there's a similar reporting structure in place in the code. Or just take the suggestion from the corresponding Github issue (https://github.com/VFR-maniac/L-SMASH-Works/issues/17) and use aui_indexer to generate the indices for LSMASHSource's filters rather than the .dll itself. I don't know if aui_indexer prints its progress or not (and if you want to support XP and pre-SSE2 users, you'll need to recompile it from the provided source).

[Selur]

don't know if aui_indexer prints its progress or not
it doesn't, posted about this at the beginning of this thread (https://www.doom9.org/showthread.php?p=1620445#post1620445) which is when I created the issue :)

[VFR maniac]

Write like the plugin for AviUtl.
I rarely care about the plugin for AviSynth.
I'm busy and lazy.

Hints:
https://github.com/VFR-maniac/L-SMASH-Works/blob/master/AviUtl/progress_dlg.c
https://github.com/VFR-maniac/L-SMASH-Works/blob/master/AviUtl/lwlibav_input.c#L104
https://github.com/VFR-maniac/L-SMASH-Works/blob/master/AviSynth/lwlibav_source.h#L24
https://github.com/VFR-maniac/L-SMASH-Works/blob/master/AviSynth/lwlibav_source.cpp#L74

[speedyrazor]

Hi, I am opening very large HD Quicktime Prores files, about 120GB, with LSMASHVideoSource, as I don't want to wait 20 mins for an index.
I am finding using the below avisynth script that it is still taking about 1-2 mins to open my file.
My source quicktime contains 8 channels of audio, which I need to use.
My question is... Is there anything I can do to speed up the opening of my files?

v = LSMASHVideoSource(source="E:\Source22.mov", format="YUY2")
a1 = LSMASHAudioSource(source="E:\Source22.mov", track=2)
a2 = LSMASHAudioSource(source="E:\Source22.mov", track=3)
a3 = LSMASHAudioSource(source="E:\Source22.mov", track=4)
a4 = LSMASHAudioSource(source="E:\Source22.mov", track=5)
a5 = LSMASHAudioSource(source="E:\Source22.mov", track=6)
a6 = LSMASHAudioSource(source="E:\Source22.mov", track=7)
a7 = LSMASHAudioSource(source="E:\Source22.mov", track=8)
a = MergeChannels(a1,a2,a3,a4,a5,a6,a7)
AudioDub(a,v)
ColorMatrix(mode="Rec.709->Rec.601", clamp=0)
Spline64Resize(720, 576)
AssumeFPS(25, 1)

Kind regards.

[speedyrazor]

Hi, When using LSMASHAudioSource with 24 bit audio all I am getting is white noise. Is LSMASHAudioSource compatible with 24 bit audio?

Kind regards.

[Selur]

Not atm. (LWLibavAudioSource is, but that requires an index)

[VFR maniac]

Hi, When using LSMASHAudioSource with 24 bit audio all I am getting is white noise. Is LSMASHAudioSource compatible with 24 bit audio?

Kind regards.

Yes, if the CODEC and its configuration are correctly detected.
If not, send such sample please.

[VFR maniac]

Hi, I am opening very large HD Quicktime Prores files, about 120GB, with LSMASHVideoSource, as I don't want to wait 20 mins for an index.
I am finding using the below avisynth script that it is still taking about 1-2 mins to open my file.
My source quicktime contains 8 channels of audio, which I need to use.
My question is... Is there anything I can do to speed up the opening of my files?



Kind regards.

Because the internal indexing occurs per each clip (video and individual audio channels), I guess.
To solve this, we need an implementation like the following method.

clip = LSMASHSource(source="source.mov")
v = LSMASHGetTrack(clip, track=1)
a1 = LSMASHGetTrack(clip, track=2)
a2 = LSMASHGetTrack(clip, track=3)
a3 = LSMASHGetTrack(clip, track=4)
a4 = LSMASHGetTrack(clip, track=5)
a5 = LSMASHGetTrack(clip, track=6)
a6 = LSMASHGetTrack(clip, track=7)
a7 = LSMASHGetTrack(clip, track=8)
a = MergeChannels(a1,a2,a3,a4,a5,a6,a7)
AudioDub(a,v)


I don't know if it can be achieved within AviSynth API restrictions.

[Selur]

Is there anything I can do to speed up the opening of my files?
you could create the index before opening the file,...
Just out of curiosity how large is the index file?

[speedyrazor]

Yes, if the CODEC and its configuration are correctly detected.
If not, send such sample please.

Hi, thanks for you response. I have sent you a PM with a link to a small test file.
I have tried using various source videos, all prores, all with 24 bit audio, I have also tried various settings, but all come out with white noise (same files with 16 bit audio work fine).
The sample I sent you is a typical prores file with multichannel 24 bit audio.
Thanks for your help.

Kind regards.

[speedyrazor]

you could create the index before opening the file,...
Just out of curiosity how large is the index file?

OK, so using only LWLibavVideoSource for a 90 min HD Prores at 113 GB, it took 12 mins to index and produced a 457 MB file.
This was using a 10 GB network with media which was on a network share.
Here is the AVS script I used.

LWLibavVideoSource(source="J:\Folder\test.mov", format="YUY2")

Kind regards.

[VFR maniac]

Hi, thanks for you response. I have sent you a PM with a link to a small test file.
I have tried using various source videos, all prores, all with 24 bit audio, I have also tried various settings, but all come out with white noise (same files with 16 bit audio work fine).
The sample I sent you is a typical prores file with multichannel 24 bit audio.
Thanks for your help.

Kind regards.

Should be fixed @ L-SMASH rev1339 + L-SMASH Works rev782
Thank you for sending a sample.

[speedyrazor]

Hi VFR maniac, you are a star!!!! Many thanks for sorting this out so quickly.
Sorry to appear stupid, but where can I download the LSMASHSource.dll from?

Kind regards.

[LigH]

Let's hope the_weirdo will publish builds (http://forum.doom9.org/showthread.php?p=1689573#post1689573) soon.

[speedyrazor]

And here it is.....
Many thanks to VFR maniac and the_weirdo.

https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0

And I can report that all is now working as it should with 24 bit audio.
Thanks againVFR maniac.

[speedyrazor]

Because the internal indexing occurs per each clip (video and individual audio channels), I guess.
To solve this, we need an implementation like the following method.

clip = LSMASHSource(source="source.mov")
v = LSMASHGetTrack(clip, track=1)
a1 = LSMASHGetTrack(clip, track=2)
a2 = LSMASHGetTrack(clip, track=3)
a3 = LSMASHGetTrack(clip, track=4)
a4 = LSMASHGetTrack(clip, track=5)
a5 = LSMASHGetTrack(clip, track=6)
a6 = LSMASHGetTrack(clip, track=7)
a7 = LSMASHGetTrack(clip, track=8)
a = MergeChannels(a1,a2,a3,a4,a5,a6,a7)
AudioDub(a,v)


I don't know if it can be achieved within AviSynth API restrictions.

Could something like cache bool = true be implemented, so it only looks at it once?

Kind regards.

[RTW47]

since there is no cache parameter for LSMASH*Source does this mean that index always is stored inside memory and discarded after the script is closed? (just like LWLibav*Source/FFMS2 with cache=false would?) because there is still some internal indexing involved, if i understood correctly. (more interested in vapoursynth version if there are any differences)

[speedyrazor]

Hi, I am trying to open a Quicktime Prores 444 file with LSMASHVideoSource but just get the below error:

[avisynth @ 029017e0] Avisynth: access violation at 0x0076F2E1 in C:\Program Files (x86)\AviSynth 2.5\plugins\LSMASHSource.dll, attempting to read from 0x00000000
(C:\Temp\SC_Test.avs, line 1)
C:\Temp\SC_Test.avs: Unknown error occurred

I am using this ASV script:

LSMASHVideoSource(source="Prores_444.mov", format="YUV444P10")

I have also tried various other 'format's.
Should LSMASHVideoSource be able to open Prores 444 files?

[VFR maniac]

444? not 4444?
LSMASHVideoSource should be able to open ProRes 422 and 4444 (XQ).

[speedyrazor]

444? not 4444?
LSMASHVideoSource should be able to open ProRes 422 and 4444 (XQ).

ffmpeg reports it to be this:

Stream #0:0(eng): Video: prores (ap4h / 0x68347061), yuv444p10le(bt709), 1920x1080, 22649 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 25 tbn, 25 tbc (default)

I have PM'd you a small sample.

Kind regards.

[VFR maniac]

The 4CC 'ap4h' represents Apple ProRes 4444.

I can't reproduce your bug. Here, it's processed normally.
I have a question to you. What ver. of AviSynth do you use?
AviSynth 2.5.8 can't handle some planar pixel formats.

If you don't use such old AviSynth, I guess you encountered miscompilation, but I'm not sure
Usually, MSVC+GCC is unstable, especially, when static linking is used.
Anyway, it is difficult to investigate without debug builds.

[speedyrazor]

The 4CC 'ap4h' represents Apple ProRes 4444.

I can't reproduce your bug. Here, it's processed normally.
I have a question to you. What ver. of AviSynth do you use?
AviSynth 2.5.8 can't handle some planar pixel formats.

If you don't use such old AviSynth, I guess you encountered miscompilation, but I'm not sure
Usually, MSVC+GCC is unstable, especially, when static linking is used.
Anyway, it is difficult to investigate without debug builds.

I am very sorry VFR maniac, I tried on a different system, and it worked fine. Sorry for wasting your time. I will do a re-install on the current system.

Kind regards.

[hello_hello]

I guess this is the place to report it......

The version of L-Smash currently on MeGUI's auto-update server (r783) doesn't seem to work at all on XP. Avisynth won't load it.
http://forum.doom9.org/showthread.php?p=1710813#post1710813

I've reverted back to r768 and that works fine, although I have a question regarding the recently added variable to constant frame rate conversion. I haven't tested it with lots of sources, but should it work regardless of file type? So far I've had it working for AVIs and MP4s but it seems to have no effect when the source is MKV. Should it?

Thanks.

[sneaker_ger]

Works fine here with mkv (the_weirdo's 783). Be more specific and supply a sample.

[hello_hello]

Originally I thought it was specific to MKV because the frame rate conversion seemed to have no effect for the couple I tried but it turns out that's not correct. However it is producing odd results with some files so I'll try to split off a few small samples shortly. I can't upload large files as my internet connection is way too slow so I'll need to split some files and try to create small samples.

[Groucho2004]

Works fine here with mkv (the_weirdo's 783).
It works fine because you're not using XP, right?
I already explained what the problem is in the Megui thread. r783 is not compatible with XP.

[sneaker_ger]

I was talking about VFR->CFR with mkv files, not the XP issue.

[hello_hello]

Okay.... here's a few little samples. Each file contains exactly the same video, remuxed into different containers. The duration is just over a minute. I don't know what the deal is with this particular video but if I had to pick who to believe in respect to frame count (for a constant frame rate) and duration, I'd always put my money on AviSource.

AVI
AviSource: 1593 frames, duration 00:01:06:441, 23.976fps.
FFMS2: Same as AviSource with and without frame rate conversion.
LWLibavVideoSource: Same frame count but only 0.3fps and a duration of 01:28:35:637. Adding "fpsnum=24000, fpsden=1001" frame rate conversion increases the total frame count to over 100,000.

TS
DirectShowSource: Same result as for AviSource above (minus one frame when convertfps=true is added).
FFMS2: Shows a little FFMS2 oddness in that the frame count changes by 3 when "fpsnum=24000, fpsden=1001" is used, but it is ffms2 and a TS file.
LWLibavVideoSource: Same result as for AviSource above when "fpsnum=24000, fpsden=1001" is added to the script. Without it the duration decreases by about 11ms.

MKV
DirectShowSource: Seems to behave pretty well for DirectShowSource aside from not liking the last 3 frames.
FFMS2: Behaves fairly well although when "fpsnum=24000, fpsden=1001" is added the frame count drops by three. It appears to be ignoring the first couple of frames.
LWLibavVideoSource: Agrees with AviSource above as to the total number of frames, but not the duration. Output is 24.471fps. There's no convincing it to change the frame rate. You can add "fpsnum=96000, fpsden=1001" to a script if you like, but the output will still be 24.471fps.

Make of that what you will. ;)
I'm testing with L-Smash r768.

35MB zip file containing the video in three different containers. http://ge.tt/1PYYr0B2/v/0

As a side note, I've seen ffms do odd things with AVIs when frame rate conversion is added to the script, even when the specified frame rate is the original fame rate. That problem (http://forum.doom9.org/showthread.php?p=1709589#post1709589) has been discussed a few times. The video from which I split the samples off for this post is the only one where I've seen ffms2 do the same thing for a different file type (ie MKV) but I'm having trouble splitting off a small sample without the problem going away.

Anyway..... could someone please tell me why ffms2 and L-Smash treat AVIs with null frames as variable frame rate? Given they're plugins for AviSynth I'd think it far more logical not to. That's a big part of the motivation for using fpsnum and fpsden when opening AVI's, to make sure the output is the correct constant frame rate, just like AviSource would do it.....

[Groucho2004]

There's nothing wrong with the video.

First I demuxed the h.264 stream to determine the properties. Frame rate is 23.976, 1594 frames.

Muxed to mkv, no problem with LWLibavVideoSource reading that mkv, frame rate and number of frames are fine.

FFMS2 however needs a "assumefps(24000, 1001)" in order to behave.

[sneaker_ger]

The mkv has a video delay so demuxing will change the results. I don't have time to look into this further at the moment.

[hello_hello]

You're probably right about the total frame count being 1594. MeGUI's preview displays 1593 bit I keep forgetting about the first frame being frame zero.

You might be able to demux and remux the video to get it to behave, but what about the MKV I uploaded? Can you use fpsnum and fpsden to change the frame rate? And what about the AVI, does LWLibavVideoSource lose the plot completely as it does for me?

Anyway, I think I've had enough for today. I've been messing around with this way too long. I'll probably check back tomorrow.

[hello_hello]

The mkv has a video delay so demuxing will change the results. I don't have time to look into this further at the moment.

Ahh..... that might explain why sometimes the frame count changes by three or four, depending on the container and who's decoding, but I have no idea why there should be a delay. I remuxed the original MKV without any audio, then split it into sections until I found one that misbehaved, and it wasn't at the beginning.

See you tomorrow (tomorrow for me, at least).

[Groucho2004]

You might be able to demux and remux the video to get it to behave, but what about the MKV I uploaded? Can you use fpsnum and fpsden to change the frame rate? And what about the AVI, does LWLibavVideoSource lose the plot completely as it does for me?
The mkv and avi you uploaded are obviously bolloxed.
The elementary stream is fine and when I mux it into a mkv, everything is OK. The question is - what went wrong when you created the mkv?

Lastly, muxing avc into an avi should be avoided anyway.

[hello_hello]

The mkv and avi you uploaded are obviously bolloxed.
The elementary stream is fine and when I mux it into a mkv, everything is OK. The question is - what went wrong when you created the mkv?

Lastly, muxing avc into an avi should be avoided anyway.

The AVI is only bolloxed when using LWLibavVideoSource. I normally wouldn't put AVC in an AVI without a specific reason but I thought I'd test it.

If something went wrong with the MKV when it was created it's persisted through several remuxes and splitting and seems to only effect LWLibavVideoSource. How "something going wrong" could stop L-Smash from doing frame rate conversion is still a mystery.

If you're motivated, try remuxing the extracted stream with ffmpeg. I can't get it to play nice. It keeps dropping the first 50 seconds and I'm left with a 16 second MP4/MKV. It's odd.

I've really got to do some work. See you later......

[kolak]

Have a small issue with new ffmpeg supported format, which is GrassValey HQX codec.
Height is returned in vs as 1088 (instead of 1080), so I assume it misses some automatic cropping (looks like LWLibavSource forces mod16 mode).
I can provide sample file if needed.

[hello_hello]

Is L-Smash deliberately snubbing XP these days? The latest version (r784) won't run on XP. Neither would r783.

[Reel.Deel]

Is L-Smash deliberately snubbing XP these days? The latest version (r784) won't run on XP. Neither would r783.

have you tried L-SMASH-Works-r783-20150223-32bit-XP.7z (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0)?

[hello_hello]

have you tried L-SMASH-Works-r783-20150223-32bit-XP.7z (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0)?

No, but I will.
Thanks.

[the_weirdo]

Is L-Smash deliberately snubbing XP these days? The latest version (r784) won't run on XP. Neither would r783.

I was busy last time so I didn't answer this. L-SMASH Works itself isn't "deliberately snubbing" XP, as it doesn't require features which are exclusive on later Windows versions. It's just me who don't support XP in my builds anymore (since the begining of 2015). As I'm only sharing _my_ builds to anyone who needs them, I'm not responsible for providing builds that are as compatible as possible.

L-SMASH Works and its dependencies are open-source, the toolchain is also free, anyone can grab the source and build it themselve. Someone may provide a XP-compatible version. But it's not me. Sorry about that.

[StainlessS]

It's just me who don't support XP in my builds anymore

Well at least please let people know of the limitations everywhere that you post your links.
Thank you.

[TheFluff]

I have a modest proposal: how about you upgrade to an OS from the last decade

[burfadel]

Yes, I shouldn't need to post this in another thread, and yet I am :).

Windows XP.

Compiling for Windows XP and making it universal is detrimental to users of Windows 8.1 etc.

[StainlessS]

I have a modest proposal: how about you upgrade to an OS from the last decade

No !

I dont expect that Zathor was aware that he was breaking MeGUI for XP when downloading The_Weirdo's offering. I'm perfectly OK with The_Weirdo not supporting XP, what I do have a problem with is breaking stuff due to not stating requirement.

EDIT:
Yes, I shouldn't need to post this in another thread, and yet I am :).
And I should not have to post this.

[burfadel]

And I should not have to post this.

It's 2015, not 2007. In 2007, there was a reason to stick to XP - Windows Vista. There is really no valid reason to to stick with XP any more. System can't run Windows 7/8.1/10? Well, it probably shouldn't be used for encoding either. Stressing old components and all.

Not to mention Windows XP is no longer supposed security patch wise, unless on that paid plan or whatever (which would be stupid to be part of), which they're ending shortly anyway. It's hardly a point worth saying. It's old, defunct, full of security holes, and regardless of any complaints I might get because of this statement, they shouldn't be encouraged to continue using it. If they're too stubborn to change from XP why on earth are they wanting to latest encoding tools?

[Wilbert]

@burfadel, stop trolling. It's not up to you to say which os people should use.

[burfadel]

It wasn't my intention to troll. Actually Microsoft have summed up what I said (and keeping in mind this page isn't new):
http://windows.microsoft.com/en-AU/windows/end-support-help

With that in mind, and people still using XP for banking and other financial transfers, I just fully believe it's continued use shouldn't be encouraged.

[hello_hello]

It's 2015, not 2007. In 2007, there was a reason to stick to XP - Windows Vista. There is really no valid reason to to stick with XP any more.

Granted, software/driver support for XP isn't universal any more, but even in 2015 the best Windows upgrade scenario I can expect still seems to be the software I use will continue to work as it always has.

If they're too stubborn to change from XP why on earth are they wanting to latest encoding tools?

It's a tangible benefit thing and a not an upgrading just for the sake of it thing.
The next PC I build (which is well overdue) won't run XP, but this one does (and very possibly will until it dies) so it'd be nice to know when updated software no longer supports XP. If that's okay with you?

[jones1913]

@xp users try this: https://www.mediafire.com/folder/17q7t31dib18t/LSMASH-Works

Some time ago I build the dll for personal use, but then I stopped when the_weirdo offers his builds. It was easy to reactivate my build environment now...
Build with VS2010, tell me if it works and how speed compares. :)

I mostly agree that it is a bad idea to use xp on production/online systems these days, but it is not up to us to force anybody to upgrade.
Everybody must self decide and weight up the risks.

I personally use a NT 5.2 x64 virtual machine on my Linux PC for Windows specific tasks, because a Win7 VM would need 3 times the disk space.
And this system got all updates via offline method and never saw an online connection.

[hello_hello]

@xp users try this: https://www.mediafire.com/folder/17q7t31dib18t/LSMASH-Works

Some time ago I build the dll for personal use, but then I stopped when the_weirdo offers his builds. It was easy to reactivate my build environment now...
Build with VS2010, tell me if it works and how speed compares. :)

I haven't checked for any speed difference yet but it definitely works on XP. Thank you!

I mostly agree that it is a bad idea to use xp on production/online systems these days, but it is not up to us to force anybody to upgrade.
Everybody must self decide and weight up the risks.

I honestly don't know how people get infected. It must take a bit of effort, even when running XP. It's not like we're all still using IE6 and in danger of an ActiveX drive-by infection wherever we go.
No antivirus program here. No anti-malware program. No software firewall. Just me, XP and Firefox (behind a router). I haven't even run Windows update in over a year. Around once per year or so I do install anti-virus software and run a full scan before restoring the previous Windows image. Just to see what it'll find. Then I restore the image, update everything and create a new one. I've been doing that for years and so far the nastiest thing a scan has found is a naughty cookie or two.

[the_weirdo]

Well at least please let people know of the limitations everywhere that you post your links.
Thank you.

You're right. It's my fault. Sorry about that. When I made the change, I forgot to announce it here. Then I'd completely forgotten about it until hello_hello reported his problem.

I'm not forcing anyone to upgrade. They're free to use whichever OS that suits them. That said, I've my own decision and I'm not trying to please everyone.

[StainlessS]

I'm not forcing anyone to upgrade.

Yes I know, sorry if I sounded curt, was not my intent and is of course your decision.
Anyways, Peace bro :)

PS, Thank you Jonesy (I hate being called that), I'll give it a try :thanks:

[Groucho2004]

I honestly don't know how people get infected.
It's a mystery to me as well. I think it's Pebcac (http://www.urbandictionary.com/define.php?term=Pebcac).

No antivirus program here. No anti-malware program. No software firewall. Just me, XP and Firefox (behind a router). I haven't even run Windows update in over a year. Around once per year or so I do install anti-virus software and run a full scan before restoring the previous Windows image. Just to see what it'll find. Then I restore the image, update everything and create a new one. I've been doing that for years and so far the nastiest thing a scan has found is a naughty cookie or two.
Pretty much the same here. I do however use a software firewall, mainly to monitor any odd activities. Call me paranoid. :)

The only time I got a virus/worm was in the early 2000's (Blaster). At that time I used Win2000, ISDN dialup without any firewall. I just restored my Ghost image and the problem was solved in 5 minutes.

[Selur]

Only the LWLibavVideoSource builds with libav should be able to handle 10bit x264 content, right?

[the_weirdo]

Only the LWLibavVideoSource builds with libav should be able to handle 10bit x264 content, right?

No. Both builds with FFmpeg and Libav should be able to do that.

[Selur]

Strange, for me both don't.
L-SMASH-Works-r729-20141117-32bit-Libav
L-SMASH-Works-r784-20150301-32bit
both only produce garbled output and my script looks like this:
LoadPlugin("G:\MkvCutter\LSMASHSource.dll")
LWLibavVideoSource("H:\Output\HIGH10~1.MKV", cache=false)
http://s17.postimg.org/sjy0vk9zj/test.png
Here's also the mediainfo data of the source:
General
Count : 303
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Unique ID : 173785410236381370390882345944681015379
Unique ID : 173785410236381370390882345944681015379 (0x82BDDA40884D25E1AF571D15FC4FE853)
Count of video streams : 1
Video_Format_List : AVC
Video_Format_WithHint_List : AVC
Codecs Video : AVC
Video_Language_List : English
Complete name : h:\Output\high10_10bit.mkv
Folder name : h:\Output
File name : high10_10bit
File extension : mkv
Format : Matroska
Format : Matroska
Format/Url : http://packs.matroska.org/
Format/Extensions usually used : mkv mk3d mka mks
Commercial name : Matroska
Format version : Version 4 / Version 2
Codec : Matroska
Codec : Matroska
Codec/Url : http://packs.matroska.org/
Codec/Extensions usually used : mkv mk3d mka mks
File size : 7234313
File size : 6.90 MiB
File size : 7 MiB
File size : 6.9 MiB
File size : 6.90 MiB
File size : 6.899 MiB
Duration : 17160
Duration : 17s 160ms
Duration : 17s 160ms
Duration : 17s 160ms
Duration : 00:00:17.160
Duration : 00:00:17:04
Duration : 00:00:17.160 (00:00:17:04)
Overall bit rate : 3372640
Overall bit rate : 3 373 Kbps
Frame rate : 25.000
Frame rate : 25.000 fps
Frame count : 429
Stream size : 143963
Stream size : 141 KiB (2%)
Stream size : 141 KiB
Stream size : 141 KiB
Stream size : 141 KiB
Stream size : 140.6 KiB
Stream size : 141 KiB (2%)
Proportion of this stream : 0.01990
Encoded date : UTC 2015-03-17 20:03:51
File creation date : UTC 2015-03-17 20:03:44.514
File creation date (local) : 2015-03-17 21:03:44.514
File last modification date : UTC 2015-03-17 20:03:51.913
File last modification date (local) : 2015-03-17 21:03:51.913
Writing application : mkvmerge v7.5.0 ('Glass Culture') 64bit built on Jan 26 2015 13:43:13
Writing library : libebml v1.3.1 + libmatroska v1.4.2
Writing library : libebml v1.3.1 + libmatroska v1.4.2
Encoding Gui : Hybrid 2015.03.16.1

Video
Count : 297
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
ID : 1
ID : 1
Unique ID : 6920789142181302940
Format : AVC
Format/Info : Advanced Video Codec
Format/Url : http://developers.videolan.org/x264.h
tml
Commercial name : AVC
Format profile : High 10@L3.0
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, CABAC : Yes
Format settings, ReFrames : 4
Format settings, ReFrames : 4 frames
Internet media type : video/H264
Codec ID : V_MPEG4/ISO/AVC
Codec ID/Url : http://ffdshow-tryout.sourceforge.net
/
Codec : V_MPEG4/ISO/AVC
Codec : AVC
Codec/Family : AVC
Codec/Info : Advanced Video Codec
Codec/Url : http://ffdshow-tryout.sourceforge.net
/
Codec profile : High 10@L3.0
Codec settings : CABAC / 4 Ref Frames
Codec settings, CABAC : Yes
Codec_Settings_RefFrames : 4
Duration : 17160
Duration : 17s 160ms
Duration : 17s 160ms
Duration : 17s 160ms
Duration : 00:00:17.160
Duration : 00:00:17:04
Duration : 00:00:17.160 (00:00:17:04)
Bit rate : 3305524
Bit rate : 3 306 Kbps
Width : 640
Width : 640 pixels
Height : 352
Height : 352 pixels
Pixel aspect ratio : 1.000
Display aspect ratio : 1.818
Display aspect ratio : 16:9
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 25.000
Frame rate : 25.000 fps
Frame count : 429
Resolution : 10
Resolution : 10 bits
Colorimetry : 4:2:0
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10
Bit depth : 10 bits
Scan type : Progressive
Scan type : Progressive
Interlacement : PPF
Interlacement : Progressive
Bits/(Pixel*Frame) : 0.587
Delay : 0
Delay : 00:00:00.000
Delay, origin : Container
Delay, origin : Container
Stream size : 7090350
Stream size : 6.76 MiB (98%)
Stream size : 7 MiB
Stream size : 6.8 MiB
Stream size : 6.76 MiB
Stream size : 6.762 MiB
Stream size : 6.76 MiB (98%)
Proportion of this stream : 0.98010
Writing library : x264 - core 146 r2538 121396c
Writing library : x264 core 146 r2538 121396c
Writing library/Name : x264
Writing library/Version : core 146 r2538 121396c
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x111 / me=hex / subme=5 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=18 / ip_ratio=1.40 / pb_ratio=1.30 / aq=0
Default : Yes
Default : Yes
Forced : Yes
Forced : Yes
colour_description_present : Yes
Matrix coefficients : BT.601
Color range : Limited

[qyot27]

Unless something has changed, it's LSMASHSource itself that doesn't support >8 bit in AviSynth. It's probably just doing a straight input->output treatment of the pixfmt, and since AviSynth doesn't have >8 bit pixfmts, that's what you get. In VapourSynth you'd get the proper image.

[sneaker_ger]

Yes, you have to force a compatible output format:
format="YUV420P8" or format="YUV420P16" (stacked)

[MeteorRain]

both only produce garbled output and my script looks like this:

This is exactly the correct output of a high bit depth video.

You'll need a tool that can display high bit depth preview, or, you'll have to force a 8 bit output, which is YUV420P8 as said above.

[stax76]

What is the runtime situation currently? Doesn't it work without installing a runtime? A few StaxRip users have problems running the plugin, for me it runs but I have installed Visual Studio 2013 Community Edition of course.

[sneaker_ger]

If this is still true they need VC++2013: http://avisynth.nl/index.php/LSMASHSource

[stax76]

How much bigger would the file size be if it was statically linked and provided as 7z download? Could anybody help with a building and uploading this?

[kuchikirukia]

So, is L-SMASH broken for decoding interlaced content out of MKV? I get jumps no mater which field order I use when using QTGMC.

[LigH]

A broken interlacing is more probable; or Telecine instead of Interlacing. Did you provide a sample of your material?

[kuchikirukia]

It deinterlaces with DGDecode. It deinterlaces with L-SMASH out of .h264 (though it sets as 119/2 fps).
Out of MKV with QTGMC it thinks it's 120fps and it jerks back and forth if you set L-SMASH to 30000/1001 (though not quite as bad as if the field order is wrong).

Out of MP4 with LSMASHVideoSource and no filters I got several instances of "failed to make a frame."
And that ain't right: E: never mind, that's in the mp4. First time I used this drive was for this MP4, so there might be an issue with it.
http://s14.postimg.org/t0wxc5cvh/untitled.jpg

[Music Fan]

The problem can come from your mkv : if the original container of your video was ts, and if you opened it directly in MKVmerge, the framerate can be wrong, even if you specified the correct framerate in MKVmerge.
I noticed this problem with several interlaced H264 videos. After remux in MKV, MediaInfo detects VFR while it's CFR.
To avoid this, the ts has to be demuxed in elementary streams before remux in mkv.
But it's not too late, you can still demux mkv in elementary streams and remux it.

[kuchikirukia]

It was extracted with HD streams extractor, and it played at 30fps interlaced / 60fps LAV filter YADIF bobbed.

E: Ok, now it's not doing it. We're getting 60000/1001 and no jumping.

[Music Fan]

E: Ok, now it's not doing it. We're getting 60000/1001 and no jumping.
What did you do to make it work now ? What I explained ?

[Overdrive80]

Can not LSmash indexing avi files encoded with magicyuv???

http://forum.doom9.org/showthread.php?p=1722304#post1722304

[Reel.Deel]

Can not LSmash indexing avi files encoded with magicyuv???

http://forum.doom9.org/showthread.php?p=1722304#post1722304

FFmpeg/Libav does not include (http://forum.doom9.org/showthread.php?p=1708190&highlight=ffmpeg#post1708190) MagicYUV. I just use AviSource.

[LigH]

As long as libavcodec doesn't contain a decoder for MagicYUV, L-SMASH Source may not support this video format. Even though I believe it would be possible to index an AVI regardless of the used codec; but why index a clip if the video codec is not supported in libavcodec, thus neither in ffmpeg nor in related projects like FFMS2 or L-SMASH Source.

[Overdrive80]

Ok, thanks for both. I´ll use avisource.

[stax76]

I asked DG how he sends progress from DGIndex and DGIndexNV, his answer:

void OutputProgress(int progr)
{
static int lastprogress = -1;

if (progr != lastprogress)
{
char percent[20];
DWORD written;

sprintf(percent, "%d\r", progr);
WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), percent, (DWORD) strlen(percent), &written, NULL);
lastprogress = progr;
}
}

It would be very useful for GUI users to see progress.

[videoh]

This is important too for an implementer:

"Every 30 frames, this function is called to write to stdout"

and

"progr is an int 0-100 indicating the percent completed. The caller determines the percent complete from the ratio of the current file position and the size of the file. That way you don't need to know the number of frames in the file."

[Kurtnoise]

why are you posting this ? we are waiting for your patch instead...:rolleyes:

[stax76]

why are you posting this ? we are waiting for your patch instead...:rolleyes:

If it's still to difficult I consider making a patch. :rolleyes:

[foxyshadis]

I think the VapourSynth readme should really point out that the prefix is lsmas. Without it, there's no way to use the filter!

[LouieChuckyMerry]

First, many thanks for L-SMASH works :) . Second, would someone please help me understand why I can't index this (https://www.mediafire.com/?fuvbl9eb9h4sgdd) with LSW? I've tried demuxing-remuxing it as a .ts, .m2ts, .mp4, and a fresh .mkv, all of which result in flashbacks when viewing the preview window in MeGUI ;) . FFMS2 and DGAvcIndex index the file without any issues. Thanks for your time.

[Selur]

adding ,format="YUV420P8" might help with the preview, alternatively you could also add
f3kdb_dither(stacked=false, input_depth=10)

[LouieChuckyMerry]

Thanks for your help (and patience), Selur, and for not simply shouting "10 BIT!", not that I would've known what to do even if I'd noticed ;) . Both methods did the job (although the first was three-times faster), so now I've now a new trick for my bag :thanks: . In your opinion, is there a three-times improvement in quality? I can't see any difference, but my "monitor" is a 14" laptop screen.

[Selur]

Sorry, not sure now FFVideoSource does the dithering from 10bit to 8bit compared to f3kdb_dither.
I normally only add f3kdb_dither for preview purposes, for encoding I stick with 10bit. :)

Cu Selur

[foxyshadis]

Sorry, not sure now FFVideoSource does the dithering from 10bit to 8bit compared to f3kdb_dither.
I normally only add f3kdb_dither for preview purposes, for encoding I stick with 10bit. :)

Cu Selur

ffms2 & lsmash leave it default, where SWScale uses a very fast, basic fixed 8x8 pattern grid for >8-bit to 8-bit YUV. For processing & encoding that's good enough. It uses a nicer Floyd-Steinburg noise diffusion for all yuv->rgb.

[LigH]

I guess the fast pattern is "Bayer" dither?

[foxyshadis]

Exactly. They really should at least use DitherPost's method of creating some patterns at run-time, instead of a single compiled-in one, but ffmpeg does things their way.

[8-BaLL]

I was getting Access Violation trying to open a MKV file using LWLibavVideoSource. Looks like LSMASH cant handle MKV containers, right?

[LigH]

Not in general. If the content is not corrupt, and the container spec compliant, there is no reason to crash.

Try to re-multiplex this file with mkvmerge. Any error messages?

[8-BaLL]

Thanks for the info. In fact Ive just checked again and now it works :) Looks like I had some weird behaviour in AVSPmod. It would say "Access Violation" on MKV files no matter which one I selected. After selecting a .ts file, it seems to handle all MKVs again.

Again thanks for clarifying ;) LSMASH is the only source I use for HD stuff, pretty stable and precise. Not saying its not recommended for SD stuff, I just think DGdecode is more suited for mpeg2 stuff (DVDs).

[videoh]

I just think DGdecode is more suited for mpeg2 stuff (DVDs). To avoid anyone misinterpreting this, I point out that DGDecNV handles AVC, MPEG2, and VC1 in the same frame-accurate manner; there is no special sauce for MPEG2 streams. It handles HD perfectly fine. And finally, it is not buggy for MKVs as you said you experienced with LSMASH. In no way is it specialized for MPEG2 or DVDs.

I would be very surprised if LSMASH didn't also work perfectly fine for MPEG2 and DVDs. Did you experience any issues?

[LigH]

L-SMASH Works will probably not support a set of VOB segments as easily as DGMPGDec did. It will prefer one contiguous source file instead.

But as long as the source is not corrupt, it should handle all supported container and content formats really well.

[stax76]

Is there a technical reason why MP4 files can be opened directly without indexing but not MKV files?

I just think DGdecode is more suited for mpeg2 stuff (DVDs).

DG tools are solid but I think FFVideoSource will work just as well, with LWLibavVideoSource I had problems last time with a NTSC source, I'll try it again. StaxRip is x64 only so DGDecode isn't even a option.

[LigH]

L-SMASH Works contains two demultiplexers: libavformat and L-SMASH.

The L-SMASH demultiplexer supports only "ISO Media" containers and relies on media file internal index chunks. So it does not need to create an own, but fails if one is missing in the media file or is corrupt.

The libavformat demultiplexer does not rely on any media file internal index, therefore it supports also containers which do not even have an internal key frame index; but that means that it must create its own.

To support MKV containers while relying on their internal key frame index, it would have to support a third demultiplexer, probably.

[AMED]

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)

[hello_hello]

As long as libavcodec doesn't contain a decoder for MagicYUV, L-SMASH Source may not support this video format. Even though I believe it would be possible to index an AVI regardless of the used codec; but why index a clip if the video codec is not supported in libavcodec, thus neither in ffmpeg nor in related projects like FFMS2 or L-SMASH Source.

I was looking for some info and found LigH's post above, but I was wondering.....

Why is it I can successfully index an MKV containing MagicYUV video with MeGUI and ffms2, but when I save the script and try to open it in MPC-HC, it displays an error about not being able to find a video stream. It displays normally in MeGUI's preview. Is it a splitter thing?

L-Smash kind of works the same way, except when indexing it creates the index file, then complains about not being able to find the video stream, but if I open MeGUI's Script Creator and load the index file as the input video it works just as ffms2 does. If I save the script and try to load it for encoding though, it's back to the "can't find the video" error.

A pic of MeGUI's Script Creator opening an MKV containing MagicYUV video via LWLibavVideoSource. In the background is the Script Creator preview happily displaying the video. If I save the script (keeping the script creator and preview open for the screenshot below) and try to load it for encoding, the result is the error message being displayed in the foreground.
I'm curious as to how that'd work.......

http://s8.postimg.org/kipmybx0x/magicyuv.jpg (http://postimg.org/image/kipmybx0x/)

[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.

[an3k]

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.

Ok, thank you. These are the steps I took on a clean Ubuntu Server 14.04.3 installation with the required packages (git, gcc) already installed:

1) git clone https://github.com/l-smash/l-smash.git
2) cd l-smash/
3) ./configure
4) make
5) make install
6) cd ../
7) git clone https://github.com/VFR-maniac/L-SMASH-Works.git
8) cd L-SMASH-Works/
9) ./configure

Here I'm getting an error ("-bash: ./configure: No such file or directory") because there is no file at all (except .gitignore) in this directory but four directories AviSynth, AviUtil, common and VapourSynth. Only in AviUtil and VapourSynth I can find a file called configure and because I need L-SMASH for VS I guess I have to cd into that directory before ./configure (That's what I meant with "make install inside the VapourSynth directory" :)) thus

10) cd VapourSynth/
11) ./configure

Here I experience the next error (the same I experienced every time I tried it before) and I have no clue why:./configure
~/L-SMASH-Works/VapourSynth ~/L-SMASH-Works/VapourSynth
~/L-SMASH-Works/VapourSynth
CFLAGS/LDFLAGS checking...
warning: pkg-config or pc files not found, lib detection may be inaccurate.
checking for liblsmash...
error: liblsmash checking failed
error: lsmash.h might not be installed or some libs missing.
l-smash compiled and got installed correctly, not a single warning or error and the default path configure for L-SMASH Works uses (/usr/local/ and /usr/local/lib/) are correct. I even symlinked liblsmash.pc and lsmash.h into ~/L-SMASH-Works/VapourSynth directory and also into ~/L-SMASH-Works/common but that doesn't helped too.

I guess I'm missing here something?!

[qyot27]

sudo apt-get install checkinstall
L-SMASH:
git clone git://github.com/l-smash/l-smash.git
cd l-smash
./configure
make -j$(nproc)
sudo checkinstall --pkgname=lsmash --pkgversion="0:$(git rev-list --count HEAD)-g$(git rev-parse --short HEAD)" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --fstrans=no --default
LSMASHSource:
git clone git://github.com/VFR-maniac/L-SMASH-Works.git
cd L-SMASH-Works/VapourSynth
./configure
make -j$(nproc)
sudo checkinstall --pkgname=vslsmashsource --pkgversion="1:$(git rev-list --count HEAD)-g$(git rev-parse --short HEAD)" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --stripso=yes --addso=yes --fstrans=no --default

[an3k]

I noticed a problem with the configure script itself. Without ffmpeg installed it shows the following error./configure
~/L-SMASH-Works/VapourSynth ~/L-SMASH-Works/VapourSynth
~/L-SMASH-Works/VapourSynth
CFLAGS/LDFLAGS checking...
warning: pkg-config or pc files not found, lib detection may be inaccurate.
checking for liblsmash...
error: liblsmash checking failed
error: lsmash.h might not be installed or some libs missing.However, with ffmpeg installed is shows./configure
~/L-SMASH-Works/VapourSynth ~/L-SMASH-Works/VapourSynth
~/L-SMASH-Works/VapourSynth
CFLAGS/LDFLAGS checking...
checking for liblsmash...
checking for libavformat...
checking for libavcodec...
checking for libswscale...

settings...
CC = gcc
LD = gcc
STRIP = strip
CFLAGS = -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include
LDFLAGS = -fPIC -L. -L/usr/local/lib -L${exec_prefix}/lib -shared
LIBS = -pthread -L/usr/local/lib -llsmash -lavformat -lavcodec -lswresample -lswscale -lavutil -lm
SONAME = libvslsmashsource.so.868
SOFLAGS = -Wl,-soname,libvslsmashsource.so.868
PREFIX = /usr/local
VSPLUGINDIR = ${libdir}/vapoursynth

configure finished.
type 'make' : compile libvslsmashsource.so.868So the problem is that if libavformat and/or libavcodec and/or libswscale is not present it shows that liblsmash is not present (which in fact is).

Now, after configure successfully finishes I went onto make and I get a new error:gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -c ../common/lwlibav_audio.c -o ../common/lwlibav_audio.o
../common/lwlibav_audio.c:31:63: fatal error: libavresample/avresample.h: No such file or directory
#include <libavresample/avresample.h> /* Resampler/Buffer */
^
compilation terminated.
make: *** [../common/lwlibav_audio.o] Error 1
After cp'ing the libavresample directory from the ffmpeg-2.8.4 directory (after ffmpeg was ./configure'd && make'ed && make install'ed) into the L-SMASH-Works/VapourSynth directory I get past this point but then a new error occurs:gcc -Wl,-soname,libvslsmashsource.so.868 -fPIC -L. -L/usr/local/lib -L/usr/local/lib -shared -Wl,-s -o libvslsmashsource.so.868 lsmashsource.o video_output.o libavsmash_source.o lwlibav_source.o \
../common/utils.o ../common/qsv.o ../common/libavsmash.o ../common/libavsmash_video.o ../common/lwlibav_dec.o ../common/lwlibav_video.o ../common/lwlibav_audio.o ../common/lwindex.o \
../common/video_output.o -pthread -L/usr/local/lib -llsmash -lavformat -lavcodec -lswresample -lswscale -lavutil -lm
/usr/bin/ld: /usr/local/lib/liblsmash.a(description.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/liblsmash.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [libvslsmashsource.so.868] Error 1However, this error is gone after you go back into the ffmpeg-2.8.4 directory and do
1) ./configure --enable-shared
2) make
3) make install

And at this point ffmpeg, l-smash and L-Smash Works were successfully built and installed. But the remaining question is: Is all of this the expected behavior, especially the manual cp of the libavresample directory? :)

sudo apt-get install checkinstall
L-SMASH:
git clone git://github.com/l-smash/l-smash.git
cd l-smash
./configure
make -j$(nproc)
sudo checkinstall --pkgname=lsmash --pkgversion="0:$(git rev-list --count HEAD)-g$(git rev-parse --short HEAD)" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --fstrans=no --default
LSMASHSource:
git clone git://github.com/VFR-maniac/L-SMASH-Works.git
cd L-SMASH-Works/VapourSynth
./configure
make -j$(nproc)
sudo checkinstall --pkgname=vslsmashsource --pkgversion="1:$(git rev-list --count HEAD)-g$(git rev-parse --short HEAD)" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --stripso=yes --addso=yes --fstrans=no --defaultThis is excellent. Thank you very much for that! Since I don't want all the required configure & make dependencies on the final server I really love it. One short question: How do I know if I have to use --stripso=yes and/or --addso=yes or not?

[qyot27]

--addso=yes is necessary for any shared libraries, so you don't have to run sudo ldconfig. --stripso=yes is mostly to make sure the shared libs are stripped, which really only cuts down on filesize (and may have an impact on install speed, since it takes less time to cp the files into the install dirs); for libs that don't strip automatically for non-debug builds, --stripso=yes will take care of that.

Just build FFmpeg with avresample support (--enable-avresample). The issue with the -fPIC error is due to PIC being required on 64-bit. Using --enable-pic when configuring FFmpeg may avert that error if you still want those as static rather than shared.

[an3k]

--addso=yes is necessary for any shared libraries, so you don't have to run sudo ldconfig. --stripso=yes is mostly to make sure the shared libs are stripped, which really only cuts down on filesize (and may have an impact on install speed, since it takes less time to cp the files into the install dirs); for libs that don't strip automatically for non-debug builds, --stripso=yes will take care of that.

Just build FFmpeg with avresample support (--enable-avresample). The issue with the -fPIC error is due to PIC being required on 64-bit. Using --enable-pic when configuring FFmpeg may avert that error if you still want those as static rather than shared.
Thank you very much! I got everything I needed successfully compiled but all with shared libs and before I continue with static ones I want to fix some maybe errors I encounter.

When running this script through vspipe (or manually in Python) I get the below error:import vapoursynth as vs

# get the core instance
core = vs.get_core()

# open a video file; clip is now a clip object
clip = core.lsmas.LibavSMASHSource("sample.mkv")

# set the clip to be output
clip.set_output()vapoursynth@encoder:~$ vspipe test.vpy - | x264 --crf 22 --input-res 1920x1080 - -o sample_recode.264
raw [info]: 1920x1080p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: profile High, level 4.0
[importer: Error]: failed to find the matched importer.
Script evaluation failed:
Python exception: [Fatal]: Failed to read an input file

Traceback (most recent call last):
File "src/cython/vapoursynth.pyx", line 1489, in vapoursynth.vpy_evaluateScript (src/cython/vapoursynth.c:27016)
File "test.vpy", line 8, in <module>
clip = core.lsmas.LibavSMASHSource("sample.mkv")
File "src/cython/vapoursynth.pyx", line 1381, in vapoursynth.Function.__call__ (src/cython/vapoursynth.c:25311)
vapoursynth.Error: [Fatal]: Failed to read an input file



vapoursynth@encoder:~$
When I use the same test.vpy script but open a raw h.264 source I get the following error (this time no vspipe because it outputs nothing):vapoursynth@encoder:~$ python3.4
Python 3.4.3 (default, Oct 14 2015, 20:28:29)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth as vs
>>> core = vs.get_core()
>>> clip = core.lsmas.LibavSMASHSource("sample.264")
Segmentation fault (core dumped)as H.264
vapoursynth@encoder:~$Before Python crashes I see [H.264: Info]: Analyzing stream as H.264 where Segmentation fault (core dumped)as H.264 is in the above paste

EDIT: core.lsmas.LWLibavSource("sample.264") works perfectly also with the sample.mkv

[qyot27]

LibavSMASHSource is for MP4 (and probably MOV and other ISO Base Media) files only. LwLibavSource is the general-use source filter.

[speedyrazor]

Hi, I am using the below script to open a Quicktime Prores HQ (10 bit video) file which has multi channel / multi track audio (24 bit audio). Just want to check I am doing it correctly?

v=lsmashvideosource("movie.mov", stacked=true, format="YUY2")
a1 = lsmashAudioSource("movie.mov", track=1)
a2 = lsmashAudioSource("movie.mov", track=2)
a3 = lsmashAudioSource("movie.mov", track=3)
a4 = lsmashAudioSource("movie.mov", track=4)
a5 = lsmashAudioSource("movie.mov", track=5)
a6 = lsmashAudioSource("movie.mov", track=6)
a7 = lsmashAudioSource("movie.mov", track=7)
a = MergeChannels(a1,a2,a3,a4,a5,a6,a7)
AudioDub(a,v)

The file is opening and displaying picture and audio, but takes a couple of minutes to open a large 130GB HD file.

[MysteryX]

It takes time to open because it first needs to index the file. Which means, at the very least, reading 130GB from your hard drive. Then it caches the result in a file.

[sneaker_ger]

lsmashxxxxxsource does not create index files

[LigH]

But LSMASH{Audio|Video}Source can only read ISO Media containers, like e.g. MP4, 3GPP, or MOV ... oh, MOV. You are lucky. :D

But then there must be another reason why AviSynth with L-SMASH Works needs some time to prepare the access. Maybe it's in the structure of the MOV file so it needs to be scanned completely for all required header data.

[an3k]

LibavSMASHSource is for MP4 (and probably MOV and other ISO Base Media) files only. LwLibavSource is the general-use source filter.

That explains it. Thank you :)

[speedyrazor]

Hi, love using LibavSMASHSource as there is no indexing, but it seems there maybe an issue, as we are using this with VapourSynth and on quite a few video files it is crashing VSPipe, issue reported here:

http://forum.doom9.org/showthread.php?p=1753452&highlight=LWLibavSource+simply+doesn%27t+test.avi#post1753452

[Myrsloik]

I've already submitted a pull request that fixes a lot of the bad behavior that caused the crashes. As soon as the author merges it you'll at least be getting proper error messages and no crashes.

[speedyrazor]

I've already submitted a pull request that fixes a lot of the bad behavior that caused the crashes. As soon as the author merges it you'll at least be getting proper error messages and no crashes.
Is that fixes in Vapoursynth or LibavSMASHSource or both, just checking what I will need to update?
Good news though, thanks.

[huhn]

someone an idea why i get: "cannot load file "C:\Program Files (x86)\AviSynth+\plugins64+\LSMASHSource.dll". platform returned code 1114: a dynamic link libary (DLL) initialiation routine failed."?


for LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\LSMASHSource.dll")

[sl1pkn07]

and in plugin64? without +

[huhn]

already tried that no change i even tried: D:\AviSynth\LSMASHSource.dll

the content of the folder is the folder avisynth from the 64 bit lsmash x64 7z

[sl1pkn07]

have you installed vc++2015?

[huhn]

i have installed 2015 redistributable 14.0.23506 32/64 bit. and "all" others too.

[sl1pkn07]

and the rest of dlls? avcodec,avformat,avresampleavutil,swscale? (included in the zip)

[huhn]

avcodec-57.dll, avformat-57.dll, avresample-3.dll, avutil-55.dll and swscale-4.dll are all in the plugin folder together with LSMASHsource.dll. do i need them in the system32 folder?

[sl1pkn07]

no, not need put in system directory

works for me in the same directory of LSMASHsource.dll

i put in C:\Program Files (x86)\AviSynth+\plugins(64)

[speedyrazor]

I see there is a new version on the link in the first post:

L-SMASH-Works-r875-20160202-64bit.7z

[sl1pkn07]

I see there is a new version on the link in the first post:

works in same way on old or new version

[huhn]

so i guess this is "yet another windows 10 user rights issue".

is there an easy way to change the default pluginfolder for avisynth+?

i didn't installed it in the program files folder but it still created the plugin folder there.

i guess some where deep in the registry?

[LigH]

A Microsoft Community thread (http://answers.microsoft.com/en-us/windows/forum/windows_vista-networking/error-1114-dynamic-link-library-dll-intialization/f6245128-52f8-4fb7-a66b-9928c483cf8a?db=5&auth=1) suggests running the System File Checker (https://support.microsoft.com/en-us/kb/929833) ("sfc /scannow" in an Admin console) to fix possibly missing system libraries; may help or not...

You can easily specify several more plugin paths for AviSynth+, also in areas not monitored by the UAC.

[huhn]

worth a try thank both of you.

i will look into changing the plugin folder path later. i hope i find all needed informations.

edit:"sfc /scannow" as admin didn't find any issues

and the build in administrator didn't worked too. i don't see a reason why a different plugin folder should work when it doesn't work with the admin account.

so i'm pretty much out of ideas.
i guess time to reinstall windows next weekend.

[WorBry]

Hi,
I'm wanting to install L-Smash on Mint KDE 17.3 (AMD 64) and, if successful, Kubuntu 15.10 (AMD 64). I have VapourSynth installed on both from this ppa:

https://launchpad.net/~djcj/+archive/ubuntu/vapoursynth

I also installed the "Extra Plugins" package (which got installed to /usr/lib/x86_64-linux-gnu/vapoursynth), but unfortunately L-Smash was not included.

So I'm left with the prospect of trying to install it myself, with absolutely no experience in installing VapourSynth plugins, or compiling anything really. Still very new to linux.

I found earlier in the thread though a method described for installing L-Smash and L-SMASH Works on Ubuntu, so I thought I'd give it a try, on Mint first.

sudo apt-get install checkinstall
L-SMASH:
git clone git://github.com/l-smash/l-smash.git
cd l-smash
./configure
make -j$(nproc)
sudo checkinstall --pkgname=lsmash --pkgversion="0:$(git rev-list --count HEAD)-g$(git rev-parse --short HEAD)" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --fstrans=no --default
LSMASHSource:
git clone git://github.com/VFR-maniac/L-SMASH-Works.git
cd L-SMASH-Works/VapourSynth
./configure
make -j$(nproc)
sudo checkinstall --pkgname=vslsmashsource --pkgversion="1:$(git rev-list --count HEAD)-g$(git rev-parse --short HEAD)" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --stripso=yes --addso=yes --fstrans=no --default

Following that procedure, I now have the unpacked git clone folders for l-smash and l-SMASH Works sitting in my Home directory. But when I apply ./configure I get these errors:

~/l-smash > ./configure
generating config.mak ...
error: invalid CFLAGS/LDFLAGS

~/L-SMASH-Works/VapourSynth > ./configure
~/L-SMASH-Works/VapourSynth ~/L-SMASH-Works/VapourSynth
~/L-SMASH-Works/VapourSynth
CFLAGS/LDFLAGS checking...
error: invalid CFLAGS/LDFLAGS


Not a promising start. Would appreciate advice on what to do?

[TheFluff]

well, you could start where configure tells you to, by checking what's in your CFLAGS and LDFLAGS (to see what's in an environment variable on a unix-based system, say echo $VARIABLENAME)

if you spent half as much time reading error messages and pasting them into google as you do posting on forums I'd wager you'd be a lot further along right now than you are

edit: nevermind, checking what's in your env CFLAGS/LDFLAGS probably won't help. I took a look at configure and it adds a bunch of stuff; you're gonna have to check config.log and see why it fails. My gut says your compiler is too old but who knows.

[WorBry]

if you spent half as much time reading error messages and pasting them into google as you do posting on forums I'd wager you'd be a lot further along right now than you are.

Why are you being so obnoxious. You did the same to me on that VapourSynth thread, where I ended up requesting advice on how to install to L-Smash on Linux, to which no-one responded. After exhaustive google searches to find some documentation, I returned here, and after winding my way page by page through this lengthy thread, I finally found something that looked promising. And now you've followed me here and are doing the same thing again.

well, you could start where configure tells you to, by checking what's in your CFLAGS and LDFLAGS (to see what's in an environment variable on a unix-based system, say echo $VARIABLENAME)

....edit: nevermind, checking what's in your env CFLAGS/LDFLAGS probably won't help. I took a look at configure and it adds a bunch of stuff; you're gonna have to check config.log and see why it fails. My gut says your compiler is too old but who knows.

What makes you think I even understand what you are talking about. If I did, I wouldn't be asking the questions I have been. So why pile more on, just to make me look dumb? Please stop it. In my experience, people who really know their stuff don't treat other people that way.

[LigH]

@ TheFluff: Blaming people for having no experience doesn't give them experience. ;)

@ WorBry: Try to skip the emotional parts and read the technical parts again; showing us the content of your "config.log" (generated during the ./configure run, an error message already here should have alerted you) may help guessing a reason. It will probably be large, so using one of the many "pastebin services" out there is recommendable.

[WorBry]

Thank-you. It's now well into the small hours here, so I'll come back on this tomorrow.

[TheFluff]

If you want to get any serious work done on Linux (other than the basic computer desktop things such as word processing, spreadsheets, web browsing and email) you gotta learn at least the very basics of compiling stuff. Blame nerds for it or whatever you want but that's just how it is, you need to learn to deal with it. The people you're currently putting your questions in this forum (which is a forum for digital video software development, not a Linux basics forum) are not the kind of people who are all that interested in writing yet another "how to compile things under Linux for complete beginners" guide just for you. Your questions are decently well formulated but the reason nobody is answering them is that they are elementary, answering them will not solve the actual problem (just help you one more step on the long way to actually finding out what the real problem is) and people can't be bothered to hold your hand through your first battles with a Linux developer environment.

If you don't want this frustration, there are two avenues available to you:
1) You can man up and go read some guides that explain what CFLAGS and LDFLAGS are (try typing "what is cflags" into Google, for example), what config.log is and why it's important (it's a standard feature in almost every configure script on the planet, it's not something unique to L-SMASH) and some basic build troubleshooting so you can at least ask the right questions, ones that don't require the respondent to begin their answer with the compiler equivalent of explaining how to copypaste text, or
2) Go back to Windows, where the hardest problem you can expect to encounter is figuring out what folder to put a .dll in.

The underlying problem here is that Linux people tend to distribute software in source form, and if you're installing software from source you kinda need to know something about compilers and build environments to solve any issues at all. You don't necessarily need to be a programmer (although it certainly helps), but again, this is just how Linux is, and you need to learn to deal with it.

What makes you think I even understand what you are talking about. If I did, I wouldn't be asking the questions I have been. So why pile more on, just to make me look dumb? Please stop it. In my experience, people who really know their stuff don't treat other people that way.
The answer I gave (look in config.log) is as much of an answer to the question you posed as anyone could hope to come up with, given the info you provided. It was not a smoke screen or an insult.

In my experience, people who really know their stuff don't treat other people that way.
have you ever read anything linus torvalds has written?
because boy howdy the open source community sure doesn't like people asking questions, ask the source code or suffer

[jpsdr]

No one has any idea of the issue i have, described in post #456 (http://forum.doom9.org/showpost.php?p=1752997&postcount=456) ?

[TheFluff]

No one has any idea of the issue i have, described in post #456 (http://forum.doom9.org/showpost.php?p=1752997&postcount=456) ?

Not really, but since it's complaining about not recognizing PRIu64 that points to either something being off with your standard includes (inttypes.h in this case) or the .c files being compiled as C89 instead of C99 or something like that (note that it's only complaining about the .c files). Can't really give you a good answer, I've never built it under Windows myself.

[WorBry]

If you want to get any serious work done on Linux ......

No, I don't particularly, at least not at this point. I just want to get Vapoursynth up and running with some standard routines for processing the variety of video formats I use or may encounter. That work I am serious about.


....because boy howdy the open source community sure doesn't like people asking questions, ask the source code or suffer

And by the way, that has not at all been my experience when visiting linux forums. Very welcoming and chilled. People with all levels of experience always willing to help and many people addressing the same level of newbie queries as myself. No condescension or frosty go figure it yourself because you are in the open source world now. But in this particular case (installing L-Smash for VapourSynth) I couldn't obtain the pertinent information needed and so it was logical to address it here. And yes, if I manage to get this sorted, I might in turn be able to help others struggling with the same problem. That's what the Linux community ethos is about, surely.

Now I'm asking you politely, please don't respond to any more of my posts, or weigh in on any of the replies that I may receive from others.

Thank you.

[WorBry]

.....read the technical parts again; showing us the content of your "config.log" (generated during the ./configure run, an error message already here should have alerted you) may help guessing a reason.

The config.log generated in the L-Smash-Works>VapourSynth folder simply states:

all command lines:


---------------------------------
CFLAGS/LDFLAGS checking...
int main(void){ return 0;}
gcc conftest.c -o conftest -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fPIC -L. -L/usr/local/lib -L${exec_prefix}/lib
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
1

I can find no config.log generated in the l-smash folder, or in any of the sub-folders, or indeed anywhere in the Home directory..hidden files included. Tried it repeatedly.

http://i.imgur.com/98ptisp.png

[WorBry]

OK, I've just tried again, this time in Kubuntu 15.10 (AMD 64) and have made some progress. This was using the same commands as before:

sudo apt-get install checkinstall
L-SMASH:
git clone git://github.com/l-smash/l-smash.git
cd l-smash
./configure
make -j$(nproc)
sudo checkinstall --pkgname=lsmash --pkgversion="0:$(git rev-list --count HEAD)-g$(git rev-parse --short HEAD)" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --fstrans=no --default
LSMASHSource:
git clone git://github.com/VFR-maniac/L-SMASH-Works.git
cd L-SMASH-Works/VapourSynth
./configure
make -j$(nproc)
sudo checkinstall --pkgname=vslsmashsource --pkgversion="1:$(git rev-list --count HEAD)-g$(git rev-parse --short HEAD)" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --stripso=yes --addso=yes --fstrans=no --default


L-Smash installed OK, stating that it has been saved to

~l-smash/lsmash_1384-g3408947-1_amd64.deb

but moving on to L-Smash-Works I've again hit an obstacle at ./configure:

~/L-SMASH-Works/VapourSynth$ ./configure
~/L-SMASH-Works/VapourSynth ~/L-SMASH-Works/VapourSynth
~/L-SMASH-Works/VapourSynth
CFLAGS/LDFLAGS checking...
warning: pkg-config or pc files not found, lib detection may be inaccurate.
checking for liblsmash...
error: liblsmash checking failed
error: lsmash.h might not be installed or some libs missing.


Config.log reports:

ll command lines:


---------------------------------
CFLAGS/LDFLAGS checking...
int main(void){ return 0;}
gcc conftest.c -o conftest -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fPIC -L. -L/usr/local/lib -L${exec_prefix}/lib
0
int main(void){ return 0;}
gcc conftest.c -o conftest -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fPIC -L. -L/usr/local/lib -L${exec_prefix}/lib
0
int main(void){ return 0;}
gcc conftest.c -o conftest -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -fPIC -L. -L/usr/local/lib -L${exec_prefix}/lib
0

---------------------------------
warning: pkg-config or pc files not found, lib detection may be inaccurate.

---------------------------------
checking for liblsmash...
#include <lsmash.h>
int main(void){lsmash_create_root(); return 0;}
gcc conftest.c -o conftest -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -fPIC -L. -L/usr/local/lib -L${exec_prefix}/lib -llsmash -lavformat -lavcodec -lswscale -lavutil
/usr/bin/ld: cannot find -lavformat
/usr/bin/ld: cannot find -lavcodec
/usr/bin/ld: cannot find -lswscale
/usr/bin/ld: cannot find -lavutil
collect2: error: ld returned 1 exit status
1

---------------------------------
error: liblsmash checking failed


I have ffmpeg installed:

~$ ffmpeg
ffmpeg version 2.7.6-0ubuntu0.15.10.1 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 20151010
configuration: --prefix=/usr --extra-version=0ubuntu0.15.10.1 --build-suffix=-ffmpeg -enable-frei0r --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enablble-libmp3lame --enable-libopenjpeg --enable-openal --enable-libopus --enable-libpulse -webp --enable-libxvid --enable-libzvbi --enable-opengl --enable-x11grab --enable-libdc13
libavutil 54. 27.100 / 54. 27.100
libavcodec 56. 41.100 / 56. 41.100
libavformat 56. 36.100 / 56. 36.100
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 16.101 / 5. 16.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.100 / 1. 2.100
libpostproc 53. 3.100 / 53. 3.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...


So is it a question of pointing whatever to the right directory or something?

[Groucho2004]

How about some de-cluttering and moving the gcc stuff to a dedicated thread?

[WorBry]

Might be a good idea. And then there would be a point of reference for anyone searching for the same answers.

[jones1913]

@WorBry

The log file from your mint attempt points to a missing 'crt1.o'. A quick google search shows that this file is part of package 'libcX-dev'.
So first check if you have a similar package installed. On Debian/Ubuntu based distros you often need 'XXX-dev' packages to compile things.
Otherwise if crt1.o exist on your system then it could be a problem with pointer to the right path. ($LIBRARY_PATH or so...)

At your attempt with kubuntu there is a problem with 'pkg-config', google should point you to the right direction.

As a side note: here on Manjaro Linux (Arch Linux based) I was able to compile l-smashsource at the first try without installing any additional packages.
Apart from that it is not necessary because l-smash and l-smashsource are available via the AUR (Arch User Repository), so installation takes only a few clicks.

[qyot27]

There is no ffmpeg-dev in Debian and its derivatives that can install all of the right dev libraries. The -dev packages are separated per-library (http://packages.ubuntu.com/search?keywords=ffmpeg-dev&searchon=names&suite=wily&section=all), so you'd probably need to do this before attempting to build L-SMASH-Works:
sudo apt-get install Package libavcodec-ffmpeg-dev libavdevice-ffmpeg-dev libavfilter-ffmpeg-dev libavformat-ffmpeg-dev libavresample-ffmpeg-dev libavutil-ffmpeg-dev libpostproc-ffmpeg-dev libswresample-ffmpeg-dev libswscale-ffmpeg-dev

Although quite honestly, I'd just build FFmpeg from git and do it that way.

[WorBry]

Thanks.

OK, resuming after a lengthy power cut, I've got a bit further with the L-Smash Works install on Kubuntu 15.10,but now the:

make -j$(nproc)

won't complete:

~$ git clone git://github.com/VFR-maniac/L-SMASH-Works.git
Cloning into 'L-SMASH-Works'...
remote: Counting objects: 5179, done.
remote: Total 5179 (delta 0), reused 0 (delta 0), pack-reused 5179
Receiving objects: 100% (5179/5179), 2.48 MiB | 3.64 MiB/s, done.
Resolving deltas: 100% (3258/3258), done.
Checking connectivity... done.
bryan@bryans-kubuntu:~$ cd L-SMASH-Works/VapourSynth
bryan@bryans-kubuntu:~/L-SMASH-Works/VapourSynth$ ./configure
~/L-SMASH-Works/VapourSynth ~/L-SMASH-Works/VapourSynth
~/L-SMASH-Works/VapourSynth
CFLAGS/LDFLAGS checking...
checking for liblsmash...
checking for libavformat...
checking for libavcodec...
checking for libswscale...

settings...
CC = gcc
LD = gcc
STRIP = strip
CFLAGS = -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu
LDFLAGS = -fPIC -L. -L/usr/local/lib -L${exec_prefix}/lib -shared
LIBS = -L/usr/local/lib -llsmash -lm -lavformat-ffmpeg -lavcodec-ffmpeg -lswscale-ffmpeg -lavutil-ffmpeg
SONAME = libvslsmashsource.so.875
SOFLAGS = -Wl,-soname,libvslsmashsource.so.875
PREFIX = /usr/local
VSPLUGINDIR = ${libdir}/vapoursynth

configure finished.
type 'make' : compile libvslsmashsource.so.875
bryan@bryans-kubuntu:~/L-SMASH-Works/VapourSynth$ make -j$(nproc)
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c lsmashsource.c -o lsmashsource.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c video_output.c -o video_output.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c libavsmash_source.c -o libavsmash_source.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c lwlibav_source.c -o lwlibav_source.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c ../common/utils.c -o ../common/utils.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c ../common/qsv.c -o ../common/qsv.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c ../common/libavsmash.c -o ../common/libavsmash.o
video_output.c: In function ‘get_vs_output_pixel_format’:
video_output.c:263:13: warning: implicit declaration of function ‘strcasecmp’ [-Wimplicit-function-declaration]
if( strcasecmp( format_name, format_table[i].format_name ) == 0 )
^
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c ../common/libavsmash_video.c -o ../common/libavsmash_video.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c ../common/lwlibav_dec.c -o ../common/lwlibav_dec.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c ../common/lwlibav_video.c -o ../common/lwlibav_video.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c ../common/lwlibav_audio.c -o ../common/lwlibav_audio.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c ../common/lwindex.c -o ../common/lwindex.o
gcc -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu -c ../common/video_output.c -o ../common/video_output.o
../common/libavsmash.c: In function ‘libavsmash_get_track_by_media_type’:
../common/libavsmash.c:206:9: warning: ‘track_id’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if( lsmash_construct_timeline( root, track_id ) < 0 )
^
gcc -Wl,-soname,libvslsmashsource.so.875 -fPIC -L. -L/usr/local/lib -L/usr/local/lib -shared -Wl,-s -o libvslsmashsource.so.875 lsmashsource.o video_output.o libavsmash_source.o lwlibav_source.o ../common/utils.o ../common/qsv.o ../common/libavsmash.o ../common/libavsmash_video.o ../common/lwlibav_dec.o ../common/lwlibav_video.o ../common/lwlibav_audio.o ../common/lwindex.o ../common/video_output.o -L/usr/local/lib -llsmash -lm -lavformat-ffmpeg -lavcodec-ffmpeg -lswscale-ffmpeg -lavutil-ffmpeg
/usr/bin/ld: /usr/local/lib/liblsmash.a(description.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/liblsmash.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
GNUmakefile:23: recipe for target 'libvslsmashsource.so.875' failed
make: *** [libvslsmashsource.so.875] Error 1


The log says to recompile with -fPIC. Trying to find out how to do that:

http://stackoverflow.com/questions/13812185/how-to-recompile-with-fpic

Looking at the config.mak file -fPIC is already there isn't it?

CC = gcc
LD = gcc
STRIP = strip
CFLAGS = -Os -ffast-math -Wall -std=c99 -pedantic -I. -I. -fPIC -I/usr/local/include -fexcess-precision=fast -I/usr/local/include -I/usr/include/x86_64-linux-gnu
LDFLAGS = -fPIC -L. -L/usr/local/lib -L${exec_prefix}/lib -shared
LIBS = -L/usr/local/lib -llsmash -lm -lavformat-ffmpeg -lavcodec-ffmpeg -lswscale-ffmpeg -lavutil-ffmpeg
SRCDIR = .
DESTDIR =
prefix = /usr/local
exec_prefix = ${prefix}
libdir = ${exec_prefix}/lib
vsplugindir = ${libdir}/vapoursynth
SRC_SOURCE = lsmashsource.c video_output.c libavsmash_source.c lwlibav_source.c ../common/utils.c ../common/qsv.c ../common/libavsmash.c ../common/libavsmash_video.c ../common/lwlibav_dec.c ../common/lwlibav_video.c ../common/lwlibav_audio.c ../common/lwindex.c ../common/video_output.c
BASENAME=vslsmashsource
SONAME=libvslsmashsource.so.875
SONAME_LN=libvslsmashsource.so
SOSUFFIX=so
SOFLAGS=-Wl,-soname,libvslsmashsource.so.875

[TheFluff]

You're asking better questions.

The issue here seems to be that you installed liblsmash as a static library (the error message says the problem appeared when trying to link /usr/local/lib/liblsmash.a - on Linux, static libraries have the .a extension while shared ones are .so) but now you're trying to link libvslsmashsource to it and that's a shared library. That won't work in this case (for reasons obscure and arcane, and I can't say I understand them myself). The top answer to the Stackoverflow question you linked actually gave you the correct solution to the problem (although it's definitely hard to figure out how to apply the solution to your problem if you don't already know the answer): you need to get rid of that liblsmash.a and recompile it as a shared library instead (or just install a shared library too, I expect the linker to be able to figure out which one to use). I dunno how you installed it though so exactly how to uninstall it is up to you to figure out - if you made it from source, "make uninstall" in the directory where you compiled it might work.

e: nvm, looks like you built it yourself. No need to uninstall it, just compile it again from the start but instead of just running ./configure, run ./configure --enable-shared

[WorBry]

I just followed this procedure:

sudo apt-get install checkinstall
L-SMASH:
git clone git://github.com/l-smash/l-smash.git
cd l-smash
./configure
make -j$(nproc)
sudo checkinstall --pkgname=lsmash --pkgversion="0:$(git rev-list --count HEAD)-g$(git rev-parse --short HEAD)" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --fstrans=no --default
LSMASHSource:
git clone git://github.com/VFR-maniac/L-SMASH-Works.git
cd L-SMASH-Works/VapourSynth
./configure
make -j$(nproc)
sudo checkinstall --pkgname=vslsmashsource --pkgversion="1:$(git rev-list --count HEAD)-g$(git rev-parse --short HEAD)" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --stripso=yes --addso=yes --fstrans=no --default

Tried:
./configure --enable-shared

Appears not to be an option:

~/L-SMASH-Works/VapourSynth$ ./configure --enable-shared
~/L-SMASH-Works/VapourSynth ~/L-SMASH-Works/VapourSynth
~/L-SMASH-Works/VapourSynth
error: unknown option --enable-shared


~/L-SMASH-Works/VapourSynth$ ./configure --help
Usage: [PKG_CONFIG_PATH=/foo/bar/lib/pkgconfig] ./configure [options]
options:
-h, --help print help (this)

--prefix=PREFIX install architecture-independent files into PREFIX
[/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files into EPREFIX
[PREFIX]
--libdir=DIR install libs in DIR [EPREFIX/lib]
--vs-plugindir=DIR location of VapourSynth plugin directory,
default is [libdir]/vapoursynth

--extra-cflags=XCFLAGS add XCFLAGS to CFLAGS
--extra-ldflags=XLDFLAGS add XLDFLAGS to LDFLAGS
--extra-libs=XLIBS add XLIBS to LIBS

--target-os=TARGET_OS select target operating system
--cross-prefix=PREFIX use PREFIX for compilation tools
--sysroot=SYSROOT root of cross-build tree

[TheFluff]

Wrong configure. The L-SMASH-Works configure doesn't have --enable-shared since you can't build it as static (would make no sense since it's a plugin). L-SMASH is the one you need to redo.

[qyot27]

It's L-SMASH itself that would need to be built shared, not L-SMASH-Works. The problem is that L-SMASH only uses -fPIC when building as a shared library. You have basically two options here: rebuild it as shared like TheFluff suggested, or rebuild as static but force the use of -fPIC in the CFLAGS (by appending ./configure with --extra-cflags="-fPIC"). checkinstall should be smart enough to do the general update tango so that you don't have a spare liblsmash.a without -fPIC laying around, but if you'd rather uninstall first, the command would be sudo apt-get purge lsmash.

EDIT: Beat to it. Oh well.

EDIT 2: Also, if you rebuild L-SMASH as shared, the checkinstall command would need the --stripso=yes --addso=yes options added to it.

[jpsdr]

Not really, but since it's complaining about not recognizing PRIu64 that points to either something being off with your standard includes (inttypes.h in this case) or the .c files being compiled as C89 instead of C99 or something like that (note that it's only complaining about the .c files). Can't really give you a good answer, I've never built it under Windows myself.
Thanks, this gives me a lead, to figure out why it was compiling under VS2013 and not anymore under VS2015.
I'll follow the C99 hint, maybe there was something set by default under VS2013 and not anymore under VS2015, or VS2015 broke something (i hope not...), but anyway, it's something i can start with.

[speedyrazor]

Hi, I have hit a problem opening a Quicktime Prores in Avisynth, which has 1 audio track with 10 channels of audio in it. It works with 1 track with 2 audio channels, but with this file that has 10 channels I am getting this error:

LSMASHAudioSource: failed to open resampler.
(C:\Users\me\Desktop\test.avs, line1)

Here is the avs script:

LSMASHAudioSource(source="10_ch_test.mov", track=2)

I am using 'LSMASHSource-AviSynth-plugin-r859-static-32bit'.
I will attached a small movie sample later. Is there anything i can do to get round this, is it a channel limitation?

Kind regards.

[jpsdr]

I've investigate a little more, issue with VS2015 is that apparently it didn't like line like this :

"Failed to find %s track %"PRIu32".\n"

The issue is not that PRIu32 is not defined, it's defined, what it didn't like is the way the line is writen.
I've not been able to find a way it didn't like for now... :(

[jpsdr]

Ok, i've figure out the issue.
Like a lot of people, VS2015 doesn't like when things are too tight, it needs space, so writing this :

"Failed to find %s track %" PRIu32 ".\n"

instead of this :

"Failed to find %s track %"PRIu32".\n"

solves the issue.
Is there someone i can provide/send a diff patch by mail to put on the github ?
Or should i try to make a PR ?

[WorBry]

It's L-SMASH itself that would need to be built shared, not L-SMASH-Works. The problem is that L-SMASH only uses -fPIC when building as a shared library. You have basically two options here: rebuild it as shared like TheFluff suggested, or rebuild as static but force the use of -fPIC in the CFLAGS (by appending ./configure with --extra-cflags="-fPIC"). checkinstall should be smart enough to do the general update tango so that you don't have a spare liblsmash.a without -fPIC laying around, but if you'd rather uninstall first, the command would be sudo apt-get purge lsmash.

EDIT: Beat to it. Oh well.

EDIT 2: Also, if you rebuild L-SMASH as shared, the checkinstall command would need the --stripso=yes --addso=yes options added to it.

Thanks all,

And the good news is I'm now up and running, on Kubuntu 15.10 (AMD 64) at least.

No problem opening native HD AVC (mp4 and mov) clips from various camcorders/DLSR's. But I cannot open AVCHD.mts clips from Canon, Panasonic and Sony models at all. Which is a bit frustrating, as it was my main reason for wanting to try L-Smash.

Loading a basic VapourSynth script into VSEditor:

import vapoursynth as vs
core = vs.get_core()
clip = core.lsmas.LWLibavSource(source=r"Path..../TestHFG10.mts",fpsnum=30000,fpsden=1001)
clip.set_output()

Opening Preview, there is brief pause and then VSEditor crashes. An lwi index file is generated though.

Searching for answers I came across this case:

https://github.com/VFR-maniac/L-SMASH-Works/issues/42

Ironically, the downloaded "sample.m2ts" clip from that post opened just fine with LWLibavSource. Tried running a gdb test (as cited in that thread) with my own mts clips:

Example gdb vsedit:
(note, the script file was named LSmashSource.vpy, but it was using LWLibavSource as above)

~$ gdb --args vsedit /home/bryan/Documents/LSmashSource.vpy
GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vsedit...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/vsedit /home/bryan/Documents/LSmashSource.vpy
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeba4d700 (LWP 2099)]
QWidget::insertAction: Attempt to insert null action
[New Thread 0x7fffda18d700 (LWP 2100)]
[Thread 0x7fffeba4d700 (LWP 2099) exited]
[Thread 0x7fffda18d700 (LWP 2100) exited]
[Inferior 1 (process 2095) exited normally]
(gdb) quit


VSEditor opened with "Failed to open the file........" error message.

Not sure where to go next with this. I can post a sample lwi index file if it would give any clues.

No problem opening these AVCHD mts files with LWLibavSource in AVISynth, by the way.

[qyot27]

gdb wouldn't be much use to you the way you've built the libs; it requires leaving all the debug symbols in the binaries (all of them, preferably; FFmpeg, L-SMASH, L-SMASH-Works, VapourSynth, and VSEditor).

If you have the hard drive space, I'd just run the *.mts files through mkvmerge first and only work with the Matroska copies.

[WorBry]

gdb wouldn't be much use to you the way you've built the libs; it requires leaving all the debug symbols in the binaries (all of them, preferably; FFmpeg, L-SMASH, L-SMASH-Works, VapourSynth, and VSEditor).

Ah, OK.

If you have the hard drive space, I'd just run the *.mts files through mkvmerge first and only work with the Matroska copies.

Already tried that. The remuxed mkv files behave the same way as the mts files.

[speedyrazor]

Hi, I have hit a problem opening a Quicktime Prores in Avisynth, which has 1 audio track with 10 channels of audio in it. It works with 1 track with 2 audio channels, but with this file that has 10 channels I am getting this error:

LSMASHAudioSource: failed to open resampler.
(C:\Users\me\Desktop\test.avs, line1)

Here is the avs script:

LSMASHAudioSource(source="10_ch_test.mov", track=2)

I am using 'LSMASHSource-AviSynth-plugin-r859-static-32bit'.
I will attached a small movie sample later. Is there anything i can do to get round this, is it a channel limitation?

Kind regards.

Attached is a small 1 frame sample, which shows the error.

[WorBry]

Interesting.

It's not as if I've burned my bridges with Windows and AVISynth though, and I have other reliable options there for AVCHD (DGDecIM) - so it's not such a big deal really.

I just find it a bit odd that the AVISynth version of L-Smash I have installed (r804 in MeGUI) has no problem opening these mts files. And also why this VapourSynth version should open Sony AVHD m2t clips without any issues. So whatever it is that causing this version to choke on (Canon and Panasonic) mts files specifically must surely be pretty minor? Like I said, an index file is generated.

[kuchikirukia]

http://s000.tinyupload.com/?file_id=72586136885519263005

DGDecode (CPU=4, info=3) + QTGMC: Works well enough to srestore
LSMASH + QTCMC: Horribly broken
FFMS2 + QTGMC: Horribly broken

Why the vast difference?

[Sharc]

ffms2 (still) has issues with interlaced sources afaik.
Don't know about LSMASH though.

[LigH]

Too few details. Before I download it: What do you mean by "broken"? How does it look without QTGMC? Did you enforce the correct field order (not all source plugins tell them correctly in all cases)?

[kuchikirukia]

Too few details. Before I download it: What do you mean by "broken"? How does it look without QTGMC? Did you enforce the correct field order (not all source plugins tell them correctly in all cases)?

It seems to switch to BFF. DGDecode handles this.

[WorBry]

It seems to switch to BFF...

I've just run a few tests with a couple of 1080/50i and 1080/60i AVCHD.mts clips from a Panasonic DSLR and Canon camcorder. I cant test them in Vapoursynth with LWLibavSource because they won't load at all (as reported above). But testing with ffms2 in Vapoursynth the output was definitely BFF. That's on the evidence of the back and to movement of the fields with:

clip = core.std.SeparateFields(clip, tff=True)

...and likewise of the frames after:

clip = haf.QTGMC(clip, Preset='Medium', TFF=True)


Seen both on Preview in VSEditor and after encoding to UTVideo.

Tried adding:

clip = core.std.SetFrameProp(clip, prop="_FieldBased", intval=2)

after ffms2 and before QTGMC, but it made no difference.

Testing the same clips with ffms2 and LWLibavSource in AVISynth, the QTGMC 50/60p encodes (UTVideo YV12) looked OK. But when doing the time honoured field order test:

SeparateFields()
AssumeTFF()

and looking at the movement of the fields in VirtualDub. With ffms2, I noticed that upon seeking to any particular frame, the movement was at "first back and to", suggesting BFF, but then after advancing a number of frames (I didn't count) it reverted back to a TFF pattern. But if I just let the script run through from frame 0 to finish, it looked to be all TFF. Testing with LWLibavSource the field movement pattern was consistently TFF when seeking to any frame.

That's all I can say.

[Sharc]

I did few tests again with ffms2. Forget it as a source filter for interlaced material. It messes up with the field order.
LWLibavVideoSource seems to work. I prefer DG tools though (DGdecNV).

[WorBry]

LWLibavVideoSource seems to work

But not the Vapoursynth version with AVCHD.mts files:


..No problem opening native HD AVC (mp4 and mov) clips from various camcorders/DLSR's. But I cannot open AVCHD.mts clips from Canon, Panasonic and Sony models at all. Which is a bit frustrating, as it was my main reason for wanting to try L-Smash.

Loading a basic VapourSynth script into VSEditor:

import vapoursynth as vs
core = vs.get_core()
clip = core.lsmas.LWLibavSource(source=r"Path..../TestHFG10.mts",fpsnum=30000,fpsden=1001)
clip.set_output()

Opening Preview, there is brief pause and then VSEditor crashes. An lwi index file is generated though.

Searching for answers I came across this case:

https://github.com/VFR-maniac/L-SMASH-Works/issues/42

Ironically, the downloaded "sample.m2ts" clip from that post opened just fine with LWLibavSource......

......Not sure where to go next with this. I can post a sample lwi index file if it would give any clues.

No problem opening these AVCHD mts files with LWLibavSource in AVISynth, by the way.

Is there no interest in fixing this? Despite the DSLR video boom and increasing trend to native progressive HD-AVC, and now UHD-AVC, mov and mp4 formats, there are still a lot of people recording AVCHD.

[TheFluff]

you can't randomly swap ffmpeg dll's around, the abi changes all the damn time, of course it's not gonna work

just link it statically like everyone else; plugins depending on shared libraries is an awful idea

[lansing]

Hi, I wanted to save the cache index file outside the source file location so that I can directly read those huge blu-ray video without extracting to local. I am looking for something like saving them to the same directory as the script file instead.

I had read the document for the cache argument but I couldn't find an option to do it.

[Music Fan]

Hi, I wanted to save the cache index file outside the source file location so that I can directly read those huge blu-ray video without extracting to local. I am looking for something like saving them to the same directory as the script file instead.

I had read the document for the cache argument but I couldn't find an option to do it.
You can try cache=false, if I understand well what you need (it creates index outside the RAM), but I believe you can't select directory to write this index.

[dipje]

For the record, I've stopped using FFMS2 (in Vapoursynth) because of issues with 10-bit ProRes and my Sony DSLR AVCHD files (1080p25 / 1080p50).

That's why I switched to l-smash. At the moment, that was the thing that's working.

And it's still working fine on r875 (x64 Vapoursynth that is). So not all AVCHD streams are crashing apparently, mine are still working fine.

[TalasNetrag]

When trying to open a H.264 10bit video, LWLibavVideoSource only return a greenish artefact picture.

[stax76]

It's over a year the author posted here: http://forum.doom9.org/search.php?searchid=7538802

He posted 5 days ago at the issue tracker: https://github.com/VFR-maniac/L-SMASH-Works/issues

For a bug report it's good to have some script, log file and a sample of course.

[sneaker_ger]

When trying to open a H.264 10bit video, LWLibavVideoSource only return a greenish artefact picture.
That's normal. AviSynth only natively supports 8 bit so l-smash's 10/16 bit output looks psychedelic. The simplest way to handle the problem is to tell l-smash to dither down to 8 bit:
LWLibavVideoSource("source.mkv", format="YUV420P8")

http://forum.doom9.org/showthread.php?t=173088
http://avisynth.nl/index.php/High_bit-depth_Support_with_Avisynth

[TalasNetrag]

That's normal. AviSynth only natively supports 8 bit so l-smash's 10/16 bit output looks psychedelic. The simplest way to handle the problem is to tell l-smash to dither down to 8 bit:
LWLibavVideoSource("source.mkv", format="YUV420P8")]

FFVideoSource opens the video without any extra parameters, does that mean that FFVideoSource converts it down by itself? Is there any downside going from 10->8->10 (or 12)bits?

[sneaker_ger]

does that mean that FFVideoSource converts it down by itself?
Yes, FFVideoSource dithers everything to 8 bit without asking.

Is there any downside going from 10->8->10 (or 12)bits?
Well, you lose a bit of intermediate precision which means you might introduce some extra banding. Is it bad enough to worry about? Maybe, maybe not. It's subjective.

[Groucho2004]

Is there any downside going from 10->8->10 (or 12)bits?
You don't have to. Have a look at Dithertools (http://forum.doom9.org/showthread.php?p=1386559#post1386559).

[TalasNetrag]

You don't have to. Have a look at Dithertools (http://forum.doom9.org/showthread.php?p=1386559#post1386559).

Ok, after looking at Dithertools I have this setup now:
1. Open h.264 10bit video with LWLibavVideoSource(stacked=true)
2. Do nothing
3. Dither down to 10bit with Dither_quantize()
4. Reencode the video with x264-10bit

The Script:

LWLibavVideoSource("test.mkv", format="YUV420P16", stacked=true)
#~ AssumeFPS("ntsc_video")
Trim(20511, 22248)
Dither_quantize(bitdepth=10, reducerange=true)
Dither_out()


Encoding:

avs2yuv -raw "test.avs" -o - | x264-10bit --preset slower --tune animation --crf 18 --demuxer raw --input-depth 10 --input-res 768x576 --fps 29.97 --output "test.h264" -


Is this how it's supposed to be done? Because thats kinda inconvenient just to avoid dithering down to 8bit.

Use Bitdepth(from=16,to=8) from my HDRCore tools
I want to avoid going down to 8bits.

[sneaker_ger]

If you don't want to do any further processing (except Trim()), just re-encode, you don't need any extra plugins:
LWLibavVideoSource("test.mkv")
Trim(20511, 22248)
avs2yuv -raw "test.avs" -o - | x264-10bit --preset slower --tune animation --crf 18 --demuxer raw --input-depth 10 --input-res 768x576 --fps 30000/1001 --output "test.h264" -

[Music Fan]

3. Dither down to 10bit with Dither_quantize()
Why do you have to dither down to 10 bit while your source is already in 10 bit ?

[LigH]

Because thats kinda inconvenient just to avoid dithering down to 8bit.


I want to avoid going down to 8bits.

But AviSynth only supports 8 bits per color component.

If you want a frameserver which supports more than that natively, without applying workarounds, try something different than AviSynth. Maybe VapourSynth.

[qyot27]

Is this how it's supposed to be done? Because thats kinda inconvenient just to avoid dithering down to 8bit.
Just use a 10-bit x264 that includes the AviSynth 16-bit patch (https://github.com/astrataro/x264_tMod/commit/42227cae1291165f1a39ee5536b1646e75534540) so you can stitch interleaved >8bit back together. No piping required. Any other way to do this while using AviSynth requires piping.

For that matter, that build of x264 might very well have that patch in it, in which case the pipe would be absolutely unnecessary except for the part where you're using the wrong >8bit hack format.

[TalasNetrag]

If you don't want to do any further processing (except Trim()), just re-encode, you don't need any extra plugins

For now I only wanted to see how to open and encode the video, further processing is supposed to be inserted into the "2. Do nothing" part later.

Why do you have to dither down to 10 bit while your source is already in 10 bit ?

Because the documentation of Dithertools said that I shoud dither it down from stack16 to 10bit for the encoder, or use --input-depth 16 if not dithering down and let the encoder to it.

[LigH]

further processing is supposed to be inserted into the "2. Do nothing" part later.

This "further processing" would have to be aware of such 16-bit-per-component workarounds. You shall not expect every filter to know how to handle such special videos.

[TalasNetrag]

Using L-SMASH 32bit with Vapoursynth portable 32bit always crashes regardles of input file. Using Vapoursynth 64bit and L-SMASH 64bit works fine.

[kuchikirukia]

Problem file:
http://www.filedropper.com/title001-002

LSMASH thinks there's 86210 fields in this episode, dgdecode 86602. QTGMC can put it together fed by dgdecode, but with LSMASH it's not just wrong field order, it comes out combed. QTGMC normally nukes combing from orbit.

http://s15.postimg.org/xcf7tavtz/dgdecode_qtgmc.png (http://postimg.org/image/xcf7tavtz/)

http://s15.postimg.org/wbez46euf/lsmash_qtgmc.png (http://postimg.org/image/wbez46euf/)

[poisondeathray]

Problem file:
http://www.filedropper.com/title001-002

LSMASH thinks there's 86210 fields in this episode, dgdecode 86602. QTGMC can put it together fed by dgdecode, but with LSMASH it's not just wrong field order, it comes out combed. QTGMC normally nukes combing from orbit.


I get identical results for your sample in dgdecode and l-smash r859 . Which version of l-smash are you using ?

l-smash/ffms2 are less reliable when leaving mpeg2 in mkv, and will sometimes report the wrong framerate. But the field/frame count was the same, just the fps "off" when left in mkv (which you could fix with assumefps(30000,1001) )

[kuchikirukia]

No idea what version since it doesn't say. 13,036,032 bytes created ‎October ‎29, ‎2015, ‏‎10:35:26 PM.

It did it from m2v too.
I'll update.

Oh, MeGUI's updater says r804. Since I don't recall manually updating it's probably still that.

e: I'm still getting the same issue with r877, and from m2v. I remade the lwi's.

[ravewulf]

RGB24 support partly broken:
Reading an RGB24 clip (created with AviSynth+ffmpeg, tested ffvhuff and ffv1 codecs) results in error "LWLibavVideoSource: bgr0 is not supported." Manually setting LWLibavVideoSource to use format="rgb24" works. So my assumption is that it isn't recognizing that bgr0 = RGB24. RGB32/RGBA works as expected.

Issue has been submitted at https://github.com/VFR-maniac/L-SMASH-Works/issues/51

[LigH]

@ qyot27:

In January, you discussed with an3k (http://forum.doom9.org/showthread.php?p=1753032#post1753032) how to build L-SMASH Works under Linux. Unfortunately, this procedure seems to require a few packages a prepared MSYS environment (like the one provided by XhmikosR) does not contain: checkinstall, apt, git, sudo (well, sudo may not be necessary at all due to the lack of a secure user management in MSYS; I made git available by installing Git-for-Windows). So I wonder how to make an LSMASHSource.dll in MSYS/MinGW-x64 if that is possible. Will that lead to previously compiling ffmpeg (enabling shared, avresample, pic) too?
_

Well, probably, to include libavformats / libavcodec.

In this case I guess that the media-autobuild_suite may be a good base to continue on, it can build ffmpeg shared...

[qyot27]

@ qyot27:

In January, you discussed with an3k (http://forum.doom9.org/showthread.php?p=1753032#post1753032) how to build L-SMASH Works under Linux. Unfortunately, this procedure seems to require a few packages a prepared MSYS environment (like the one provided by XhmikosR) does not contain: checkinstall, apt, git, sudo (well, sudo may not be necessary at all due to the lack of a secure user management in MSYS; I made git available by installing Git-for-Windows). So I wonder how to make an LSMASHSource.dll in MSYS/MinGW-x64 if that is possible. Will that lead to previously compiling ffmpeg (enabling shared, avresample, pic) too?
_

Well, probably, to include libavformats / libavcodec.

In this case I guess that the media-autobuild_suite may be a good base to continue on, it can build ffmpeg shared...
I don't recall ever trying to build L-SMASH-Works under MSys (well, MSys2, since it has a proper - and up-to-date - package management system), but as I understand it the issues with the libs are slightly different on Windows in regards to PIC and whatnot.

The VapourSynth plugin should be able to be compiled fully static, save for LSMASHSource.dll in the final step; it's the AviSynth plugin that can't be built by MinGW-w64 and would seem to enforce the shared libav* libs thing (but I haven't tried building the AviSynth plugin for a long time, since I hate dealing with Visual Studio). g++ can't build AviSynth plugins because the C++ name mangling schemes and various other errata are incompatible, so the only way to get MinGW-w64 to build a working LSMASHSource AviSynth plugin would be to implement a C-plugin interface for it.

apt is simply the package management system on Debian-family Linux distros, and checkinstall allows users to build packages quickly so they're managed through apt rather than the mess that can ensue by having non-logged 'make install' steps littering /usr or /usr/local. With a regular 'make install', the only way to deal with later uninstallation is to run 'make uninstall' from the source tree, which means either keeping the source tree around (taking up space for something you're probably not touching), or re-running the build process for the sole reason of uninstalling the application/library (which is a waste of time).

For MSys this is moot since package management is virtually nonexistent there, and with MSys2 you might be able to manage something by playing around with pacman and PKGBUILD recipes the same way it'd be done on Arch Linux (but I have no experience with that; I use MSys2 as a means of having the GNU userland and related utilities available on Windows and keeping them up-to-date, not for compiling things).

The recent announcement that Windows 10 will have an Ubuntu-based Linux compatibility layer (https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux) will probably allow for Windows users to follow the exact same steps as the Linux cross-compiling tutorials, provided they set up the MinGW-w64 environment first (again, covered by said cross-compiling tutorials). Heck, as long as the binaries aren't kernel-level, the cross-compiling probably wouldn't even be necessary.

[LigH]

MSYS2 is the base of jb-alvarado's media-autobuild_suite, so I guess something could be done inside here. I know they use package management (e.g. pacman) to keep it up-to-date, and they use several multi-developer source managers (at least svn, git, and hg). So I guess I could ask there if adding AVS/VPY Source DLLs could be achieved easily. The rest of the required packages is already downloaded and built anyway.

[jones1913]

So I guess I could ask there if adding AVS/VPY Source DLLs could be achieved easily.
For vpy plugins that should be possible. But like qyot said, avs plugins can not be build with gcc, only with visual studio.

[Groucho2004]

But like qyot said, avs plugins can not be build with gcc, only with visual studio.
Sorry to be pedantic but this should read "avs cpp plugins can not be build with gcc, only with visual studio." C-plugins can be built with gcc.

[jones1913]

Ah right. The majority of avs plugins are cpp plugins though (afaik).

The only 'c' plugin I know of is the 'ffms2 c' plugin, but I never used it.

[stax76]

Ah right. The majority of avs plugins are cpp plugins though (afaik).

The only 'c' plugin I know of is the 'ffms2 c' plugin, but I never used it.

ffms2 c version leaks memory unlike cpp version, I think there is a yadif c version, yadifmod2 is cpp

[Groucho2004]

Ah right. The majority of avs plugins are cpp plugins though (afaik).

The only 'c' plugin I know of is the 'ffms2 c' plugin, but I never used it.
Some C-plugs, although most of them quite dated:
avscurveflow.dll
avsshock.dll
equlines.dll
ibob.dll
smartdecimate.dll
transition.dll
avsinpaint.dll
yadif.dll

[StainlessS]

Of the C Plugins mentioned by G2004 above, only the last two are v2.5 C plugins, the rest are version v2.0 plugs (at least the ones that I have).

ie v2.5

avsinpaint.dll
yadif.dll

[Motenai Yoda]

Ok, after looking at Dithertools I have this setup now:
1. Open h.264 10bit video with LWLibavVideoSource(stacked=true)
2. Do nothing
3. Dither down to 10bit with Dither_quantize()
4. Reencode the video with x264-10bit

Is this how it's supposed to be done? Because thats kinda inconvenient just to avoid dithering down to 8bit.

I want to avoid going down to 8bits.
Pretty simple

- long way

1. Open h.264 10bit video with LWLibavVideoSource(stacked=false)
2. Reencode the video with x264-10bit
using
x264-10bit --preset slower --tune animation --crf 18 --input-depth 16 --output "test.h264" "test.avs"
even if I suggest you to pipe with avs2yuv or avs4x26x to an x64 x264's build.

- short way

1. Reencode the video with x264-10bit
using
x264-10bit --preset slower --tune animation --crf 18 --output "test.h264" "test.mkv"

[sneaker_ger]

I think x264 ignores --input-depth when using AviSynth input so your first example won't work.

[Motenai Yoda]

Yep for raw input only XD but I think it should be extended to avs input too;
also is more wrong coz lsmash return a 10bit reduced clip not a 16bit ones @_@.

[qyot27]

Not even a month ago. (http://forum.doom9.org/showpost.php?p=1760495&postcount=542) The patch to use --input-depth with AviSynth has been around a loooong time.

[Motenai Yoda]

Not even a month ago. (http://forum.doom9.org/showpost.php?p=1760495&postcount=542) The patch to use --input-depth with AviSynth has been around a loooong time.

well Komisar don't apply this patch to his own builds, and taro's last builds is 2yo

[Reel.Deel]

well Komisar don't apply this patch to his own builds, and taro's last builds is 2yo

Try jpsdr's t_mod built: https://github.com/jpsdr/x264/releases

[speedyrazor]

Hi, I have hit a problem opening a Quicktime Prores in Avisynth, which has 1 audio track with 10 channels of audio in it. It works with 1 track with 2 audio channels, but with this file that has 10 channels I am getting this error:

Code:
LSMASHAudioSource: failed to open resampler.
(C:\Users\me\Desktop\test.avs, line1)

Here is the avs script:

Code:
LSMASHAudioSource(source="10_ch_test.mov", track=2)

I am using 'LSMASHSource-AviSynth-plugin-r859-static-32bit'.

Attached is a small 1 frame sample, which shows the error.

Is there an 8 Channel audio limitation?
Anyone else had this issue?

[LigH]

I just read a similar explanation last week, but where? ... Such professional MOVs do not contain "one #-channel track", but "# tracks to be interleaved and interpreted like channels".

At least I hope that is a similar case...

[speedyrazor]

I just read a similar explanation last week, but where? ... Such professional MOVs do not contain "one #-channel track", but "# tracks to be interleaved and interpreted like channels".

At least I hope that is a similar case...

But is there a solution?

[LigH]

You may have to access all the tracks in parallel, and manually interleave them to a multi-channel track, while knowing their assignments. Possibly even outside AviSynth first.

I only remember having read something. I don't know in detail, sorry...

[Lebowsky]

hi, this might be a completely stupid question, but I can't have it running on windows 7/Avisynth 2.60. I placed all 32bit dlls from the zip into C:\Program Files (x86)\AviSynth\plugins and installed the C++ 2015 x86 redist as well. When simply loading the plugin and doing version() I get a "cannot open file". What am I missing here?

EDIT: used older version of the plugin and dlls, and now I can load the plugin without issue. Sorry about that!

[sneaker_ger]

Don't be sorry for reporting problems. Others - including me - have problems with later versions as well. The static build seems to work, though. At least for me.
https://www.dropbox.com/sh/3i81ttxf028m1eh/AABfmloLIoByXYQUZ7bVg_3na/LSMASHSource-AviSynth-plugin-r877-msvc-32bit.7z?dl=1

[StainlessS]

@Lebowsky, Glad you got it sorted but,
When simply loading the plugin and doing version() I get a "cannot open file".

It sounds like you are using LoadPlugin, plugs in the Plugins (AutoLoad) directory do not need loading, it is done automatically on script startup.

[Lebowsky]

It sounds like you are using LoadPlugin, plugs in the Plugins (AutoLoad) directory do not need loading, it is done automatically on script startup.

yes I was troubleshooting, making sure I wasn't making a mistake in my call to LWLibavVideoSource.

Anyway, other question :) Can you use LWLibavVideoSource "as is" with Avisynth MT? I need to use QTGMC on my source, and I'd like to use multithreading because at the moment it's encoding at 1fps in 1 CPU only even though I have an i7-4770... :D Using less demanding deinterlacers it's blazing fast though. Anyway, QTGMC can make the most out of multithreading, but if LWLibavVideoSource doesn't support it it's not much use to try. Not sure about the whole large address awareness thing either...

[LigH]

Can you use LWLibavVideoSource "as is" with Avisynth MT?

Of course. What made you doubt? It doesn't matter whether it's auto-loaded or explicitly loaded.

You just should start with a single-instance MT mode (e.g. 5) for this source filter (possibly following a Preroll command to buffer its output) and switch to the multi-instance MT mode (2) afterwards. As often recommended. For most source filters (it is usually not wise to try to read a source multi-threaded, only the following filters should be parallelized).

For some combinations of content and container (e.g. PAFF interlaced AVC in TS), it may be useful to limit to 'threads=1'.
_

:o 4000 posts...

[StainlessS]

4000 posts...

http://cosgan.de/images/smilie/musik/n015.gifhttp://cosgan.de/images/smilie/musik/e050.gifhttp://cosgan.de/images/smilie/musik/e050.gifhttp://cosgan.de/images/smilie/musik/e050.gifhttp://cosgan.de/images/smilie/musik/n015.gif

How bout that. http://www.cosgan.de/images/smilie/sportlich/f030.gif

http://www.cosgan.de/images/smilie/set/144.gif http://www.cosgan.de/images/smilie/set/140.gif http://www.cosgan.de/images/smilie/set/140.gif http://www.cosgan.de/images/smilie/set/140.gif

[Lebowsky]

Of course. What made you doubt? It doesn't matter whether it's auto-loaded or explicitly loaded.

You just should start with a single-instance MT mode (e.g. 5) for this source filter (possibly following a Preroll command to buffer its output) and switch to the multi-instance MT mode (2) afterwards. As often recommended. For most source filters (it is usually not wise to try to read a source multi-threaded, only the following filters should be parallelized).

For some combinations of content and container (e.g. PAFF interlaced AVC in TS), it may be useful to limit to 'threads=1'.
_

:o 4000 posts...

just wasn't sure whether it worked as multi-threaded or not, as you need to install a bunch of modified dlls for the MT version to work properly (granted none of them are source importers). all good then :)

[LigH]

You have to install modified DLLs because these DLLs need to work with a current programming interface version of AviSynth MT since RC 4, to the final version 2.60.

This is not related to L-SMASH Source. Mainly because you will usually not run L-SMASH Source in multiple instances. The decoders inside L-SMASH Source may run with several threads (except you limit threads to 1); but you won't run several copies of L-SMASH Source at the same time to read the same source file, that would be possibly risky and even inefficient. Read the file once, buffer a range of decoded frames, and then let the filters work in parallel with the buffered decoded frames.

[StainlessS]

Well, its just a guess but everything seems easier in German,
Spellings and typing are always more simple, dont you think,

LigH, with 41,000 posts, dear me, that's a lot in any bodies book.
(Methinks LigH, is being shy, here).

EDIT: :)

[Lebowsky]

yep, got it. thanks!

[LigH]

Well, its just a guess but everything seems easier in German,

From the German intro of Sesame Street:

Der, die, das
...
Wieso, weshalb, warum
...

Translated to English: :p

The, the, the
...
Why, why, why
...

[LigH]

To avoid a continuing violation of rule 3 (some mods are strict here), I guess we should get rid of answers #574;575;578;579;581;582. And this. Thanks for the celebration, but it's over. :cool:

[speedyrazor]

Don't be sorry for reporting problems. Others - including me - have problems with later versions as well. The static build seems to work, though. At least for me.
https://www.dropbox.com/sh/3i81ttxf028m1eh/AABfmloLIoByXYQUZ7bVg_3na/LSMASHSource-AviSynth-plugin-r877-msvc-32bit.7z?dl=1

Yeah, I can't seem to get any of the latest versions working, all I get is:

Script error: there is no function named "LSMASHAudioSource"

I have 09/01/2016 version working, but replacing it with 07/03/2016 gives me the error.

Anyone have any suggestions please?

[sneaker_ger]

Did you try the build I linked? Did you install the c++ redistributable that's linked in the 7z file? Are you on Windows XP?

[speedyrazor]

Did you try the build I linked? Did you install the c++ redistributable that's linked in the 7z file? Are you on Windows XP?

Sorry, my mistake, I didn't install the c++ redistributable that's linked in the 7z file. Once I installed this, everything worked as expected.
All working fine now.
Sorry for the confusion.

Regards.

[asarian]

Sigh. LWLibavVideoSource crashes my AviSynth:

Avisynth: access violation at 0x000E539E in C:\Program Files (x86)\AviSynth\plugins\avformat-57.dll,
attempting to read from 0xFFFFFFFF

And LSMASHVideoSource throws this:

[importer: Error]: failed to find the matched importer.

(Both on a .m2ts file).

[speedyrazor]

You may have to access all the tracks in parallel, and manually interleave them to a multi-channel track, while knowing their assignments. Possibly even outside AviSynth first.

I only remember having read something. I don't know in detail, sorry...

What do you mean "access all the tracks in parallel"?

[stax76]

@asarian

Where is the file from? Most robust TS filter is DGDecNV.

[asarian]

@asarian

Where is the file from? Most robust TS filter is DGDecNV.

The file is just a Taylor Swift DVD I demuxed with tsMuxer (to remove the 3/2 pulldown) to an m2ts.

And yes, I normally use DGDecNV, but that seems incompatible somehow with KNLMeansCL, so I figured I try a different frame input filter.

[stax76]

The file is just a Taylor Swift DVD I demuxed with tsMuxer (to remove the 3/2 pulldown) to an m2ts.

And yes, I normally use DGDecNV, but that seems incompatible somehow with KNLMeansCL, so I figured I try a different frame input filter.

I have horrible experience with TS and avoid it at any cost, two alternatives are PS and MKV.

[asarian]

I have horrible experience with TS and avoid it at any cost, two alternatives are PS and MKV.

I'm getting the same error for the input file muxed to mkv:

Avisynth error:
LSMASHVideoSource [Fatal]: Failed to read an input file

[stax76]

The tsmuxer output is probably bad, MakeMKV is in my experience the best solution.

[asarian]

Keep in mind that DGSource reads the m2ts/mkv just fine. It's just that I can't use it now, as it clashes with KNLMeansCL usage further down the line (in QTGMC).

[jackoneill]

For DVDs d2vsource tends to work just fine, no remuxing needed. For the pulldown there is TFM + TDecimate. Err, I mean, DGDecode, not d2vsource.

[LigH]

What do you mean "access all the tracks in parallel"?

You may need a tool which can extract all 10 tracks to single mono WAVs before you could try to interleave them to a 10-channel audio track in whichever format (would you even know which track would have to be mapped to which channel?); I doubt that eac3to or BeSweet can handle MOVs, I don't know any specific tool related to QuickTime which could help you here, and I wonder how complex an ffmpeg command line could become...

[asarian]

For DVDs d2vsource tends to work just fine, no remuxing needed. For the pulldown there is TFM + TDecimate. Err, I mean, DGDecode, not d2vsource.

Thx. :) I still have an (optimized) DGDecode 1.5.8 version lying around somewhere.

[speedyrazor]

You may need a tool which can extract all 10 tracks to single mono WAVs before you could try to interleave them to a 10-channel audio track in whichever format (would you even know which track would have to be mapped to which channel?); I doubt that eac3to or BeSweet can handle MOVs, I don't know any specific tool related to QuickTime which could help you here, and I wonder how complex an ffmpeg command line could become...

I really need an avisynth audio filter that can work with more than 8 channels of audio in a Prores file which DOES NOT need to index the file (as indexing takes far too long in an HD movie).
Any suggestions please?

[LigH]

Then try to use not LwLibav*Source() but LSMASH*Source() filters of L-SMASH Works (LSMASHSource.dll). They use not libavformats with indexing, but the L-SMASH demultiplexer of ISO Base Media containers (like MP4, MOV, 3GPP) which relies on contained chunks only.

(P.S.: ^ Oh, you already did.)

Or try the older QTSource (which will probably require QuickTime installed).

BTW: I found the post in the LAV Filters thread (http://forum.doom9.org/showthread.php?p=1763719#post1763719) where one had 8 mono tracks instead of one 8-channel track. But if MediaInfo is correct, you have one 10-channel track, with included assignment information (which confuses me, though).

10 channels of 24 bit each, little endian LPCM, makes 11.5 Mbps audio. A heavy weight.

General
Count : 309
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Count of video streams : 1
Count of audio streams : 1
Video_Format_List : ProRes
Video_Format_WithHint_List : ProRes
Codecs Video : apch
Video_Language_List : English
Audio_Format_List : PCM
Audio_Format_WithHint_List : PCM
Audio codecs : PCM
Complete name : 10_ch_test_1_frame1.mov
File name : 10_ch_test_1_frame1
File extension : mov
Format : MPEG-4
Format : MPEG-4
Format/Extensions usually used : mp4 m4v m4a m4b m4p 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma f4v
Commercial name : MPEG-4
Format profile : QuickTime
Internet media type : video/mp4
Codec ID : qt
Codec ID/Url : http://www.apple.com/quicktime/download/standalone.html
Codec : MPEG-4
Codec : MPEG-4
Codec/Extensions usually used : mp4 m4v m4a m4b m4p 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma f4v
File size : 65293
File size : 63.8 KiB
File size : 64 KiB
File size : 64 KiB
File size : 63.8 KiB
File size : 63.76 KiB
Duration : 82
Duration : 82ms
Duration : 82ms
Duration : 82ms
Duration : 00:00:00.082
Duration : 00:00:00:02
Duration : 00:00:00.082 (00:00:00:02)
Overall bit rate mode : CBR
Overall bit rate mode : Constant
Overall bit rate : 6370049
Overall bit rate : 6 370 Kbps
Frame rate : 24.000
Frame rate : 24.000 fps
Frame count : 2
Stream size : 3135
Stream size : 3.06 KiB (5%)
Stream size : 3 KiB
Stream size : 3.1 KiB
Stream size : 3.06 KiB
Stream size : 3.062 KiB
Stream size : 3.06 KiB (5%)
Proportion of this stream : 0.04801
HeaderSize : 3111
DataSize : 62182
FooterSize : 0
IsStreamable : Yes
Encoded date : UTC 2016-02-18 06:29:23
Tagged date : UTC 2016-02-18 06:29:23
File creation date : UTC 2016-04-30 07:49:27.846
File creation date (local) : 2016-04-30 09:49:27.846
File last modification date : UTC 2016-02-18 04:29:24.000
File last modification date (local) : 2016-02-18 06:29:24.000
Writing library : Apple QuickTime 7.7.3
Writing library : Apple QuickTime 7.7.3
Encoded_Library_Name : Apple QuickTime
Encoded_Library_Version : 7.7.3
com.apple.quicktime.player.movie.audio.m : (Binary)

Video
Count : 311
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 1
ID : 5
ID : 5
Format : ProRes
Commercial name : ProRes
Format version : Version 0
Format profile : 422 HQ
Codec ID : apch
Codec ID/Url : http://www.apple.com/quicktime/download/standalone.html
Codec : apch
Codec : apch
Codec/CC : apch
Duration : 82
Duration : 82ms
Duration : 82ms
Duration : 82ms
Duration : 00:00:00.082
Duration : 00:00:00:02
Duration : 00:00:00.082 (00:00:00:02)
Source duration : 83
Source duration : 83ms
Source duration : 83ms
Source duration : 83ms
Source duration : 00:00:00.083
Bit rate mode : CBR
Bit rate mode : Constant
Bit rate : 201408
Bit rate : 201 Kbps
Width : 320
Width : 320 pixels
Height : 240
Height : 240 pixels
Pixel aspect ratio : 1.000
Display aspect ratio : 1.333
Display aspect ratio : 4:3
Rotation : 0.000
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 24.000
Frame rate : 24.000 fps
Frame count : 2
Source frame count : 2
Color space : YUV
Chroma subsampling : 4:2:2
Scan type : Progressive
Scan type : Progressive
Bits/(Pixel*Frame) : 0.109
Stream size : 2098
Stream size : 2.05 KiB (3%)
Stream size : 2 KiB
Stream size : 2.0 KiB
Stream size : 2.05 KiB
Stream size : 2.049 KiB
Stream size : 2.05 KiB (3%)
Proportion of this stream : 0.03213
Source stream size : 2098
Source stream size : 2.05 KiB (3%)
Source stream size : 2 KiB
Source stream size : 2.0 KiB
Source stream size : 2.05 KiB
Source stream size : 2.049 KiB
Source stream size : 2.05 KiB (3%)
Source_StreamSize_Proportion : 0.03213
Writing library : fmpg
Writing library : fmpg
Language : en
Language : English
Language : English
Language : en
Language : eng
Language : en
Encoded date : UTC 2016-02-18 06:28:50
Tagged date : UTC 2016-02-18 06:29:23
colour_description_present : Yes
colour_description_present_Original : Yes
matrix_coefficients_Original : BT.601

Audio
Count : 254
Count of stream of this kind : 1
Kind of stream : Audio
Kind of stream : Audio
Stream identifier : 0
StreamOrder : 0
ID : 2
ID : 2
Format : PCM
Commercial name : PCM
Format settings : Little / Signed
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : lpcm
Codec : PCM
Codec : PCM
Codec/Family : PCM
Codec/CC : lpcm
Codec settings : Little / Signed
Codec settings, Endianness : Little
Codec settings, Sign : Signed
Duration : 42
Duration : 42ms
Duration : 42ms
Duration : 42ms
Duration : 00:00:00.042
Duration : 00:00:00.042
Bit rate mode : CBR
Bit rate mode : Constant
Bit rate : 11520000
Bit rate : 11.5 Mbps
Channel(s) : 10
Channel(s) : 10 channels
Channel positions : Front: L C R, Side: L, Back: L C R, LFE
ChannelLayout : L R C LFE Ls Rs Lc Rc Cs Lsd
Sampling rate : 48000
Sampling rate : 48.0 KHz
Samples count : 2016
Resolution : 24
Resolution : 24 bits
Bit depth : 24
Bit depth : 24 bits
Stream size : 60060
Stream size : 58.7 KiB (92%)
Stream size : 59 KiB
Stream size : 59 KiB
Stream size : 58.7 KiB
Stream size : 58.65 KiB
Stream size : 58.7 KiB (92%)
Proportion of this stream : 0.91985
Encoded date : UTC 2016-01-30 00:32:09
Tagged date : UTC 2016-02-18 06:29:23

P.S.: Your error message was:

LSMASHAudioSource: failed to open resampler.

I wonder if the sample format (24b LE) is the reason – or indeed the channel count (but it doesn't mix down?).

[asarian]

Sigh. LWLibavVideoSource crashes my AviSynth:

Avisynth: access violation at 0x000E539E in C:\Program Files (x86)\AviSynth\plugins\avformat-57.dll,
attempting to read from 0xFFFFFFFF

Still surprised LWLibavVideoSource crashes like this. I have it installed in VapourSynth as well, at it works flawlessly there. I tried it with an .mkv version (of the same file I use LWLibavVideoSource for in VS), but still no go.

N.B. On a slightly funny note, don't call your software L-SMASH-Works-r877-20160307-32bit, when it doesn't work at all. :) Or at least not always.

[fvisagie]

Still surprised LWLibavVideoSource crashes like this. I have it installed in VapourSynth as well, at it works flawlessly there.

Running out of memory could also crash Avisynth, at least. You can only directly compare the two LWLibavVideoSource() instances when they run on the same machine with the same host processes, inputs and Avisynth scripts.

[asarian]

Try using the static build (LSMASHSource-AviSynth-plugin-r877-msvc-32bit) and see if it still crashes.

That's a good idea, thx! :) I will try it as soon as the current job finishes.

[asarian]

^^ Yep, the static dll of LWLibavVideoSource works just fine! Thanks again! :)

[asarian]

Yikes, does LWLibavSource even support VC1?! Getting tons of these:

x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTX 980
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.1
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe
[vc1 @ 00000236bd0cbe80] warning: first frame is no keyframe

[LigH]

I just answered the same question in the VideoHelp forum (http://forum.videohelp.com/threads/378381-FFmpeg-and-VC-1-!) (please don't cross-post...):

If it couldn't decode VC-1 at all, it would fail, and you would get not the expected video output. These warnings are probably to be ignored. I wonder how their display was enabled at all.

[Groucho2004]

Googling this warning yields quite a number of hits and it's not just VC1 streams that cause it.

[LigH]

If also the video output is wrong, I wonder if it may be "interlaced VC-1" which was usually not completely supported by libavcodec. A brief sample could help, and a verbose MediaInfo analysis (extended mode).

[asarian]

My bad for the cross-post. I supplied a sample, and further info. here:

wm-sample (http://forum.videohelp.com/threads/378381-FFmpeg-and-VC-1-%21)

[LigH]

With VapourSynth x64 R32 and VSLSMASHSource (2016-02-02) from StaxRip x64 v1.3.4.0, I get a crash loading the .vpy in VirtualDub x64 v1.10.4: "Python exception: [Fatal]: Failed to read an input file"; but I am quite sure the filename is correct, and I should have installed all MS VC++ runtimes in x86 and x64.

[sneaker_ger]

You're not trying to open a non-ISO base media file format file using LibavSMASHSource instead of LWLibavSource, are you?

[LigH]

Oops, that's indeed the mistake, I c&p from a template opening an MP4 before.
__

VirtualDub x64 shows the video correctly; x264 encoded without any vc1 warnings, there was only one before y4m [info]:

[mpegts @ 0000000000599120] Failed to open codec in av_find_stream_info

[asarian]

You're not trying to open a non-ISO base media file format file using LibavSMASHSource instead of LWLibavSource, are you?

Nope. :) The line I use, in VapourSynth, is:

vid = core.lsmas.LWLibavSource ("f:/jobs/wm-sample.m2ts")

[asarian]

Why, the matter appears to be resolved:

http://forum.videohelp.com/threads/378381-FFmpeg-and-VC-1-%21?p=2443991&viewfull=1#post2443991

With a big thanks to LigH.de for all his testing!!

[bilditup1]

Does anybody know if LSmash (LWLibavAudioSource) can properly decode 5.1 AC3 streams with 2.0 sections without mucking things up (having the 2.0 sections sound like the chipmunks?). eac3to and nic don't appear to be able to, but I don't actually know anything about how AC3 decoding works.

[LigH]

If your source is an SD TS from DVB with MPEG-2 video, Project-X can help cutting out stereo scenes (e.g. inserted advertizing). Unfortunately, it doesn't support HD TS (e.g. from DVB-S2) with AVC video.

There may be other more universal tools helping you to cut TS based on audio format ranges, which I don't know in detail (e.g. TS Sniper?). They may also be able to exchange scenes of different audio formats with silence of the surrounding format, I believe (if I'm not wrong)...

[tebasuna51]

Does anybody know if LSmash (LWLibavAudioSource) can properly decode 5.1 AC3 streams with 2.0 sections...

Seems your question is related to http://forum.doom9.org/showthread.php?t=173525

Pure decoders can't manage these kinds of streams.

Maybe you can try a Directshow decoder than add special functions to match your speakers config. If your speaker config is 2.0 the output must be 2.0, if is 5.1 the output must be 5.1

Your source seems HD them Project-X can't help you, I never try TS Sniper like LigH suggest, or you can use the method propossed in the related post.

[Music Fan]

TSDoctor lets you choose to keep the 2.0 or the 5.1 part of a video (and thus cuts video where it cuts sound) but it's not free.

[sneaker_ger]

Seems your question is related to http://forum.doom9.org/showthread.php?t=173525

Pure decoders can't manage these kinds of streams.
lwlibavaudiosource() seems to play it at least. I think it uses the layout of the first sample unless set otherwise.
I do hear artifacts but I don't know if they are a result of the problems with the stream you mentioned.

[tebasuna51]

lwlibavaudiosource() seems to play it at least. I think it uses the layout of the first sample unless set otherwise.
I do hear artifacts but I don't know if they are a result of the problems with the stream you mentioned.

You are rigth.
Using lwlibavaudiosource() to decode the mentioned samples I obtain a full 5.1 output with FC and LFE muted in 2.0 parts (SL and SR seems the same than FL and FR).

But I don't know if mantain the video sync, bilditup1 can do the test.

[Selur]

Got an avi which crashes LWLibavSource (64bit).
-> FORGET it, updated to r901 and now it works

[poisondeathray]

Does anybody know what the deal is with "h264_qsv" as a decoder for l-smash ? Does it need to be compiled in a special way ?

In the readme

+ 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.

[qyot27]

http://www.intel.com/content/www/us/en/cloud-computing/quicksync-video-ffmpeg-install-valid.html

[poisondeathray]

http://www.intel.com/content/www/us/en/cloud-computing/quicksync-video-ffmpeg-install-valid.html

Thanks, I use the ones linked on the first page as an avisynth plugin from the_weirdo's Dropbox. I'm assuming it wasn't enabled in those , because the CPU usage and speed is the same. I don't know how to compile it for avisynth.

I have qsv enabled in ffmpeg, using an autobuild script, but not for avisynth l-smash

[Selur]

using latest r911 with
clip = core.lsmas.LibavSMASHSource(source="/home/selur/Desktop/test.mp4") -> I get a Segmantation Fault with vsedit
using:
clip = core.lsmas.LWLibavSource(source="/home/selur/Desktop/test.mp4", cache=0) everything is fine
uploaded the test.mp4 file to my GoogleDrive (https://drive.google.com/drive/folders/0B_WxUS1XGCPASUZibG5XZkRfeTg?usp=sharing)
about the file:
General
Complete name : w:\test.mp4
Format : MPEG-4
Format profile : JVT
Codec ID : avc1 (isom/avc1)
File size : 3.83 MiB
Duration : 1 min
Overall bit rate : 535 kb/s
Encoded date : UTC 2016-08-21 11:33:56
Tagged date : UTC 2016-08-21 11:33:56
Writing application : Hybrid 2016.08.21.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1 min
Bit rate : 532 kb/s
Maximum bit rate : 1 381 kb/s
Width : 720 pixels
Height : 396 pixels
Original height : 406 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.078
Stream size : 3.81 MiB (100%)
Writing library : x264 core 148 r2694 3b70645
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x111 / me=hex / subme=5 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=6 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=0 / crf=18.0 / qcomp=0.50 / qpmin=0 / qpmax=81 / qpstep=4 / vbv_maxrate=150000 / vbv_bufsize=187500 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / pb_ratio=1.30 / aq=0
Encoded date : UTC 2016-08-21 11:33:56
Tagged date : UTC 2016-08-21 11:33:56
Color range : Limited
Matrix coefficients : BT.709

-> Is this a bug in LibavSMASHSource or in vsedit?

-----
Also the file is opened as 720x396 is there a way to open it with the original 720x406 without having to remux it beforehand?

[jriker1]

I have been encoding video with AVISynth and NeatVideo for many years. Recently I switched to using LWLibavVideoSource for MKV sources and noticed that about half the time when the video is done encoding, it's the expected size, however the file will be like a minute or two long. Anyone else have this problem with LWLibavVideoSource?

Thanks.

JR

[Groucho2004]

I have been encoding video with AVISynth and NeatVideo for many years. Recently I switched to using LWLibavVideoSource for MKV sources and noticed that about half the time when the video is done encoding, it's the expected size, however the file will be like a minute or two long. Anyone else have this problem with LWLibavVideoSource?

Thanks.

JR
Without seeing your script and info about your encoding workflow it's basically impossible to give advice.

[jriker1]

Without seeing your script and info about your encoding workflow it's basically impossible to give advice.

So simple didn't bother.

Create AVS File with only:
LWLibavVideoSource("t2a1080-debt.mkv") <-- example
Open in VDub64
Disable audio encoding
Set codec to Lagarith
Load NeatVideo plugin and set it up
Save as AVI

Didn't bother before because assuming there will be nothing here that is telling. But never know.

Thanks.

JR

[Groucho2004]

Does the script look OK if you preview it in VDub? What does VDub report in the File Info dialog?

[jriker1]

I'm trying to reencode right now so can't check, but can say yes it does. I go thru the entire file looking for areas to use for neatvideo cleanup so know the video is there. Way more than a minute anyway.

[jriker1]

OK, done encoding. Looks like it worked this time but as mentioned it sometimes seems to encode fine othertimes also completes but is a very short duration movie. So an 88GB 1 1/2 minute movie. Here is what VDub says when I open the AVS file:

Frame Size: 1920x1080, 23976fps (41708 us)
Length: 167517 frames (1:56:26.85)
Decompressor: Internal DIB decoder (YV12)
Number of keyframes: 167517
frame size: 3110400/3110400/3110400 (508832888k)
delta size: (no delta frames)
data rate: 596600 kbps (0.00% overhead)

Thanks.

jR

[jriker1]

OK I think I see what's happening just not sure why. It happened again. Video is showing as 2157.842fps. This is in the file info in VDub. If I open the source file in MediaInfo it shows 23.976 so source fps is fine. Thoughts?

Note, i will leave my VDub open and wait for a response in case I need to look at something. If I close and open it again in VDub chances are it will work the second time as usually does. Also looks like someone had a fps issue before but got lost in some trolling.

http://forum.doom9.org/showthread.php?p=1710893#post1710893

Thanks.

JR

[fvisagie]

Video is showing as 2157.842fps. This is in the file info in VDub. If I open the source file in MediaInfo it shows 23.976 so source fps is fine.

Well, there's a multiplier of 90 that presumably gets introduced in LWLibavVideoSource(). You could try remuxing the videos in tools like ffmpeg (potentially also to different containers) to see if LWLibavVideoSource() picks up the framerate more reliably then.

Until such time as you find an automatic fix, for now you could consider manually fixing the framerate with something like Assume[Scaled]FPS().

In your testing, remember to use Info() to compare results between MediaInfo, LWLibavVideoSource() and VDub.

HTH.

[LigH]

I wonder if you have a "variable framerate" source. This may have been achieved by assuming a very high base framerate and repeating individual frames different times. AviSynth only supports constant framerates.

Furthermore, I do remember mistakes in some cases of transport streams, depending on attributes of the contained video stream. More details about your original source may be useful.

[jriker1]

If I do reload this in VDub again it comes up 23.976 however here's more information on the file:

General
Count : 291
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Inform : Matroska: 18.4 GiB, 1h 38mn
Unique ID : 239127260858190402181820675171044581556
Unique ID : 239127260858190402181820675171044581556 (0xB3E63C376AF5933DB088DDC34D0C60B4)
Count of video streams : 1
Video_Format_List : AVC
Video_Format_WithHint_List : AVC
Codecs Video : AVC
Video_Language_List : English
Complete name : D:\Conversion\1 - Pre\Mike.mkv
Folder name : D:\Conversion\1 - Pre\Mike
File name : Mike
File extension : mkv
Format : Matroska
Format : Matroska
Format/Url : http://packs.matroska.org/
Format/Extensions usually used : mkv mk3d mka mks
Commercial name : Matroska
Format version : Version 4 / Version 2
Codec : Matroska
Codec : Matroska
Codec/Url : http://packs.matroska.org/
Codec/Extensions usually used : mkv mk3d mka mks
File size : 19792777397
File size : 18.4 GiB
File size : 18 GiB
File size : 18 GiB
File size : 18.4 GiB
File size : 18.43 GiB
Duration : 5912615
Duration : 1h 38mn
Duration : 1h 38mn 32s 615ms
Duration : 1h 38mn
Duration : 01:38:32.615
Overall bit rate mode : VBR
Overall bit rate mode : Variable
Overall bit rate : 26780404
Overall bit rate : 26.8 Mbps
Stream size : 393856830
Stream size : 376 MiB (2%)
Stream size : 376 MiB
Stream size : 376 MiB
Stream size : 376 MiB
Stream size : 375.6 MiB
Stream size : 376 MiB (2%)
Proportion of this stream : 0.01990
Title : Mike
Movie name : Mike
Encoded date : UTC 2016-11-02 15:28:27
File creation date : UTC 2016-11-02 15:28:27.794
File creation date (local) : 2016-11-02 10:28:27.794
File last modification date : UTC 2016-11-02 15:33:37.680
File last modification date (local) : 2016-11-02 10:33:37.680
Writing application : mkvmerge v6.6.0 ('The Edge Of The In Between') built on Dec 1 2013 17:55:00
Writing library : libebml v1.3.0 + libmatroska v1.4.1
Writing library : libebml v1.3.0 + libmatroska v1.4.1
Attachements : cover_land.jpg / small_cover.jpg / small_cover_land.jpg / cover.jpg

Video
Count : 277
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
Inform : English, 26.2 Mbps, 1920*1080 (16:9), at 23.976 fps, AVC (High@L4.1) (CABAC / 2 Ref Frames)
ID : 1
ID : 1
Unique ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format/Url : http://developers.videolan.org/x264.html
Commercial name : AVC
Format profile : High@L4.1
Format settings : CABAC / 2 Ref Frames
Format settings, CABAC : Yes
Format settings, CABAC : Yes
Format settings, ReFrames : 2
Format settings, ReFrames : 2 frames
Internet media type : video/H264
Codec ID : V_MPEG4/ISO/AVC
Codec ID/Url : http://ffdshow-tryout.sourceforge.net/
Codec : V_MPEG4/ISO/AVC
Codec : AVC
Codec/Family : AVC
Codec/Info : Advanced Video Codec
Codec/Url : http://ffdshow-tryout.sourceforge.net/
Codec profile : High@L4.1
Codec settings : CABAC / 2 Ref Frames
Codec settings, CABAC : Yes
Codec_Settings_RefFrames : 2
Duration : 5912621
Duration : 1h 38mn
Duration : 1h 38mn 32s 621ms
Duration : 1h 38mn
Duration : 01:38:32.621
Bit rate mode : VBR
Bit rate mode : Variable
Bit rate : 26247474
Bit rate : 26.2 Mbps
Width : 1920
Width : 1 920 pixels
Height : 1080
Height : 1 080 pixels
Pixel aspect ratio : 1.000
Display aspect ratio : 1.778
Display aspect ratio : 16:9
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 23.976
Frame rate : 23.976 fps
Frame count : 141761
Resolution : 8
Resolution : 8 bits
Colorimetry : 4:2:0
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8
Bit depth : 8 bits
Scan type : Progressive
Scan type : Progressive
Interlacement : PPF
Interlacement : Progressive
Bits/(Pixel*Frame) : 0.528
Delay : 0
Delay : 00:00:00.000
Delay, origin : Container
Delay, origin : Container
Stream size : 19398920567
Stream size : 18.1 GiB (98%)
Stream size : 18 GiB
Stream size : 18 GiB
Stream size : 18.1 GiB
Stream size : 18.07 GiB
Stream size : 18.1 GiB (98%)
Proportion of this stream : 0.98010
Title : Mike
Language : en
Language : English
Language : English
Language : en
Language : eng
Language : en
Default : No
Default : No
Forced : No
Forced : No
Buffer size : 30000000 / 30000000



Based on this is a constant frame rate.

[AzraelNewtype]

this is what fpsnum and fpsden are for. Set them. Love them.

[jriker1]

this is what fpsnum and fpsden are for. Set them. Love them.

Does that mean fpsnum should be set to 23.976 and fpsden should be set to 1? Or you supposed to set fpsnum to 24000 (though I have seen some reference 24001 in general with 23.976) and fpsden to 1001? Wasn't getting it from the doc.

Thanks.

JR

[LigH]

Assume both to be integer, then you will have 24000 : 1001.

[sneaker_ger]

Do a preview of your source, though. L-Smash's fpsnum/fpsden-conversion can get stuttery. Often AssumeFPS() is enough to do the trick because the source isn't really vfr.

[fvisagie]

If I do reload this in VDub again it comes up 23.976

...

Based on this is a constant frame rate.

Is this is an Avisynth script you loaded into VDub, or did you open the video in it directly? If the former, I suspect that Avisynth/L-SMASH would always report the video framerate as constant.

But first see if any of the suggestions help:).

[jriker1]

The above is from Mediainfo so not related to avisynth or vdub for the specs of the video.

I'm questioning if this tool is reliable for my conversions. I switched from several other plugins to avisynth because of various white screens at fast moving transition scenes but if this can't even get a basic frame rate right not good. Never saw another tool do this. Annoyed right now as I just converted another video that I was going to watch tonight and it happened again even though in VDub it said it was 23.976 before conversion. I'm going to try the settings suggested but forcing a setting doesn't sound good considering how reliable all the other tools are around this basic check.

JR

[Thunderbolt8]

is there some standalone exe command I can use to index files with lsmash (like with ffms2.exe)? reason is I would like to have some status progress bar which I dont have when using it inside megui (aside from the increasing filesize display)

[LigH]

I don't know of any. That's also the reason why MeGUI schedules an indexing job first.

[StainlessS]

You could ask the L-Smash guys to output progress every eg 5.0% to DebugView via OutputDebugString().

[Thunderbolt8]

is it normal that LSMASH does the indexing each time the script is called even though when the index file already exists? no updates etc. have been made since that file has been created, but indexing starts anew each time. its rather annoying, when I create an index file with ffms2 and then call that video again, the indexed file is usually regarded as fine and used in contrast to those created with LSMASH.

[LigH]

Indexing should only happen if there is no existing index file already (I believe it does not even check if the file date of the source is newer than the file date of the index).

Is there any possible reason that L-SMASH Source may not be able to identify the index file matching the name of the source file (e.g. non-latin characters, access rights, file attributes)?

[Taurus]

is it normal that LSMASH does the indexing each time the script is called
No, it's not nomal.
LSMASH is indexing a file at first start.
Later on the index file is used for any conversions.
There must be something wrong at your side.
Maybe LigH's suggestions shed some light?

[StainlessS]

This script (originally posted here):- http://forum.doom9.org/showthread.php?p=1707765#post1707765

Can tell how many times MeGUI is opening a script (but not if indexing at every opening, so may not be of use).

(req RT_Stats)

###
# MeGUI_ReOpenCount.avs
# http://forum.doom9.org/showthread.php?p=1707765#post1707765

LOG = "MyLog.txt" COUNTER = "MyCounter.txt"
CNT = (Exist(COUNTER) ? RT_NumberValue(RT_ReadTxtFromFile(COUNTER,Lines=1)) : 0) + 1
RT_Writefile(LOG, "%d ] *** HERE I AM *** @ %s", CNT, RT_LocalTimeString(file=False), Append=True)
RT_Writefile(COUNTER, "%d", CNT, Append=False)

# ...

Colorbars.KillAudio.Trim(0,-10).ConvertToYV12 # Your Script (only 10 frames)

# ...

ScriptClip("""
(current_frame==FrameCount-1)
\ ? RT_Writefile(LOG, "%d ] *** LAST FRAME, CLOSING SCRIPT *** @ %s", CNT, RT_LocalTimeString(file=False), Append=True)
\ : NOP
Return Last
""")
Return Last


Need to make sure that LOG and COUNTER files do not exist before start.

This is result after updating to current developer build a few moments ago.

# Loading avs into MeGUI
1 ] *** HERE I AM *** @ 2016-11-10 20:29:52.609
2 ] *** HERE I AM *** @ 2016-11-10 20:29:53.406
# Click Aspect Ratio Select close button
# ----
# Click AutoEncode button
3 ] *** HERE I AM *** @ 2016-11-10 20:31:17.546
# Click Start
4 ] *** HERE I AM *** @ 2016-11-10 20:32:08.296
5 ] *** HERE I AM *** @ 2016-11-10 20:32:09.281
5 ] *** LAST FRAME, CLOSING SCRIPT *** @ 2016-11-10 20:32:09.343
# Seems to finish then reopen again
6 ] *** HERE I AM *** @ 2016-11-10 20:32:10.234

Above, I paused before moving onto next stage.
Perhaps you can compare with MeGUI log to see what its doing at what times.
(I did not use L-Smash, might want to modify script).

The number of re-opens seems to have been reduced since last I tried, was about 7 opens on initial scan, and then another 5
on AutoEncode/render.

EDIT: Number of re-opens probably depend upon options selected in MeGUI.

[jriker1]

Do a preview of your source, though. L-Smash's fpsnum/fpsden-conversion can get stuttery. Often AssumeFPS() is enough to do the trick because the source isn't really vfr.

You are right on. I did in avisynth:

LWLibavVideoSource("Video.mkv", fpsnum=24000, fpsden=1001)
TextSub("Video.ass")

Output stutters. Really wondering the stability of this tool. Switched to it because referenced before getting these weird white frames flashing on the screen during fast transitions and was wondering if it would help but seems problematic. I'll try removing fpsnum and fpsden and adding .AssumeFPS() to the end of the LWLibavVideoSource line and see if that works.

Thanks.

JR

[Thunderbolt8]

Indexing should only happen if there is no existing index file already (I believe it does not even check if the file date of the source is newer than the file date of the index).

Is there any possible reason that L-SMASH Source may not be able to identify the index file matching the name of the source file (e.g. non-latin characters, access rights, file attributes)?no this shouldnt be the problem.

when I opened the script and it created the index file, when I add this file then to the encoding queue then its fine and its not gonna be created again. but when I load the script again even though the index file already exists then it will be created again.

[LigH]

There might be a feature to delete the index in some cases because L-SMASH Source has no sanity checks, and it happened often that a remaining index file from a previous job was re-used on a different new source, but with the same file name, which caused issues.

[tuanden0]

I have a problem with L-Smash Source of latest meGUI dev server update.

They detect my video fps 23.976 to 25.850 or 23.810 :( I tried use AsumeFPS(2400, 1001) but the fps of output didn't change :( My output video just 25.850.

This is my script

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("LSMASHVideoSource", 3)
LoadPlugin("E:\Encoder\Tools\LSMASHSource.dll")
LWLibavVideoSource("E:\Download\CG\CCNA Network Cisco 480p.mkv")
AsumeFPS(2400, 1001)
Toon(0.7)
SetFilterMTMode("Deblock", 1)
Deblock(quant=33, bOffset=2)
DeHalo_Alpha()
Prefetch(4)


Sorry for my bad English

[Music Fan]

That's 24000, 1001, not 2400, 1001, you forgot a 0. Anyway you shouldn't get 25.850 fps with this setting :confused:

[dipje]

And it's AssumeFPS with two s at the start instead of AsumeFPS.

So I'm guessing that script gives an error so whatever he's seeing, it's an old version of his script or he's even picking the wrong or something. Or a 'cache' in whatever editor you're using?

[tuanden0]

Yay, I change AsumeFPS(2400, 1001) to AssumeFPS(24000, 1001) and it's work. Thank you! :sly::sly::sly:

[jriker1]

Yay, I change AsumeFPS(2400, 1001) to AssumeFPS(24000, 1001) and it's work. Thank you! :sly::sly::sly:

Why not just do AssumeFPS(23.976) ?

[jriker1]

Does LWLibavVideoSource support 4k content? I opened a video in VDub using LWLibavVideoSource pointing to the source file and comes out with a lot of green lines with slight hazy view of the video in the background that you can see in between the green lines.

Thanks.

JR

[sneaker_ger]

Your source is using a bit-depth higher than 8 bit. You can instruct l-smash to dither it down via format="YUV420P8" parameter. (See README included in L-Smash package and AviSynth docs (http://avisynth.nl/index.php/High_bit-depth_Support_with_Avisynth))

[jriker1]

Your source is using a bit-depth higher than 8 bit. You can instruct l-smash to dither it down via format="YUV420P8" parameter. (See README included in L-Smash package and AviSynth docs (http://avisynth.nl/index.php/High_bit-depth_Support_with_Avisynth))

Thanks for the suggestion. Thinking for my workflow that may not be an option (though you didn't know this piece). Since I run all my footage thru a light touch with NeatVideo, doing as you suggest will probably alter the noise footprint making cleanup not as efficient. Probably even though I've had recent issues with it, need to go to ffmpegsource2 for this piece of footage.

Thanks.

JR

[sneaker_ger]

What do you believe ffmpegsource2 will do to your footage?

[jriker1]

What do you believe ffmpegsource2 will do to your footage?

Is it doing the same thing automagically?

[sneaker_ger]

Yes, it is.

[jriker1]

OK, in that case did as suggested and came up correctly.

Thanks!!

[StainlessS]

Why not just do AssumeFPS(23.976) ?

Because 24000,1001 is more accurate, ie
on my calculator 24000/1001 produces 23.97602398,
23.976 is rounded value. :eek:

[LigH]

It's an infinite periodical decimal fraction:
______
24 : 1001 = 0.023976

P.S.:
Are there any plans to include .mpls (Blu-ray playlist) support as input in LWLibavVideoSource? (would be a 'nice to have' feature)

I already asked a similar question in the FFMS2 thread, 4 years ago, regarding DGMPGDec index files (*.d2v), which PGCDemux can produce as well. It was already an unresolved issue for long in their bug/wish tracker at this time.

With the development of AviSynth+, converters are moving towards 64 bit. But the support for VOB segments vanishes as DGMPGDec is not ported as well. And Blu-ray playlists are a quite similar field of use.

[videoh]

DGDecNV supports MPLS playlists. It's not difficult to support.

[LigH]

But requires an Nvidia card. L-SMASH Works instead is a software-only source plugin.

[videoh]

I was just pointing out that for DG tools your logic here is perhaps a stretch. That there is no "official" 64-bit DGMPGDec is irrelevant. The code to support MPLS is not at all difficult. I'll even offer the code to any developer that wants it.

[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. :)

[speedyrazor]

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

In VapourSynth Editor I am using:

import vapoursynth as vs
core = vs.get_core(threads=4)
ret = core.lsmas.LibavSMASHSource(source=r"M:\797.mov")
ret.set_output()

And the error is:

Failed to evaluate the script:
Python exception: [Fatal]: Failed to get media parameters.

Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1491, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:26897)
File "", line 3, in <module>
File "src\cython\vapoursynth.pyx", line 1383, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:25204)
vapoursynth.Error: [Fatal]: Failed to get media parameters.

[poisondeathray]

@speedyrazor - like I said earlier, XDCAM HD422 works in mxf container with lsmash (using LWLibavSource, because it's not MP4/MOV) , so I would try rewrapping it with something like ffmpeg

If you want to upload a sample I can take a look, but I doubt that I'll magically be able to open it when you couldn't with l-smash. Unless maybe you're on different OS ? Im on Windows

You can also try ffms2 as an alternative

[speedyrazor]

@speedyrazor - like I said earlier, XDCAM HD422 works in mxf container with lsmash (using LWLibavSource, because it's not MP4/MOV) , so I would try rewrapping it with something like ffmpeg

If you want to upload a sample I can take a look, but I doubt that I'll magically be able to open it when you couldn't with l-smash. Unless maybe you're on different OS ? Im on Windows

You can also try ffms2 as an alternative

Thanks for your reply, I understand. I have been using LibavSMASHSource so I don't have to index (way too time consuming on a 2 hour HD file). Is there an alternative which I can use that also does not require indexing?

[poisondeathray]

Thanks for your reply, I understand. I have been using LibavSMASHSource so I don't have to index (way too time consuming on a 2 hour HD file). Is there an alternative which I can use that also does not require indexing?

Not that I know of; ffms2 will index

I would use LibavSMASHSource too for MP4/MOV sources for the same reason :)

But I wouldn't call it "way too time consuming", it might take a few minutes.

In avisynth there are directshow alternative source filters that don't require indexing, but they can be less reliable

[manolito]

Probably the best of the DirectShow based source filters is DSS2Mod by forclip used together with LAV Filters. With a sensible "Preroll" value (for "normal" sources I use 15, interlaced HD .TS sources need higher values) this gives surprisingly good results without the need for indexing.


Cheers
manolito

[LigH]

I like it too, as a "backup strategy"; unfortunately, it is not up-to-date with the AviSynth+ and LAV Filters development, the Xvid4PSP release 2.0.0.13 (https://code.google.com/archive/p/xvid4psp/downloads) is from 2013, the x64 DLL (http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins) (Web Archive (http://web.archive.org/web/20160224130625/https://filetea.me/t1siAfoCvW5Sy2d2BbRx2WBjg/dl), no source diff) from 2014: It may or may not work with current versions.

[poisondeathray]

Probably the best of the DirectShow based source filters is DSS2Mod by forclip used together with LAV Filters. With a sensible "Preroll" value (for "normal" sources I use 15, interlaced HD .TS sources need higher values) this gives surprisingly good results without the need for indexing.



Sorry, a bit off topic, but does this fix the missing frame problem ?

All versions of DSS2 / mod I have used have a missing frame

[manolito]

This was discussed in the original thread...
forclip made a few test builds, for two of them (for "ceiling" and "round") the links are dead, but the test version from this post:
https://forum.doom9.org/showthread.php?p=1723627#post1723627
can still be downloaded.

Personally I do not care too much about the first frame missing, as long as audio stays in sync. I deal a lot with TV captures where the beginning is problematic (orphaned B-Frames), and DSS2Mod handles them nicely. I remember a discussion with Donald Graft in a different thread where he defended his method to handle such sources. Instead of discarding those frames (which means that audio must also be cut) his source filters insert repeated frames at the beginning so audio can be left untouched. Just a matter of taste...


Cheers
manolito

[MysteryX]

There's a nasty bug in LWLibavVideoSource causing misplaced frames under certain circumstances
https://forum.doom9.org/showthread.php?p=1814489#post1814489

[lansing]

I'm trying to open a m2ts file with LWLibavVideoSource in vapoursynth, but on my 5G video file, the filter is creating a 760MB lwi cache file, and the script initiation time took about 10 seconds when trying to preview it in the editor, is this normal?

[LigH]

Creating an index file once should be normal. The next times you open the script, the index should be re-used and loading should be more or less immediate.

If the index is recreated each time, though, something may be unusual...

[Groucho2004]

loading should be more or less immediate.Loading and parsing a 760MB text file takes time even with a fast CPU and disk. 10 seconds seems reasonable.

[lansing]

The initiation time always took about 10 seconds even with the index file present, I checked the last modified time of the index file, it didn't change from the initial time it was made, so it's not being rewritten each time.

[MysteryX]

Loading and parsing a 760MB text file takes time even with a fast CPU and disk. 10 seconds seems reasonable.

76MB/s disk read is actually quite good if it's a laptop hard drive

[stax76]

Is it normal that smash source gives only 50 fps for VC1 BD decoding? ffms2 gives 100, D GDecNV outputs green frames and DSS2 (copy back) gives 320 fps.

[`Orum]

Is there any way to get frame type out of this filter, in a manner similar to FFVideoSource()'s "FFPICT_TYPE" variable (http://avisynth.nl/index.php/FFMS2#Exported_AviSynth_variables)? It would be quite handy for a filter I'm working on, and I'd like to support as many source filters as possible.

Or, if you'd like, I can probably write a patch for this and submit it if you'd prefer.

[LigH]

Is the last release now already a year old?

[amayra]

Is the last release now already a year old?
you are right the last Commits on Feb 23, 2017

[LigH]

Well, at least a fresh build with current libav libraries would be nice (e.g. decoding HEVC may have developed since); but I guess new quirks would be required then?

[Sparktank]

+1 for fresh biuld, especially where libav is concerned.

LSmash might not progress, but Libav might.

I don't know, I'm no programmer, but a public repository might help a lot of experienced users.

[qyot27]

I don't know, I'm no programmer, but a public repository might help a lot of experienced users.
There always was?
https://github.com/VFR-maniac/L-SMASH-Works

And there was some recent activity in one of the forks:
https://github.com/hydra3333/L-SMASH-Works

Of course, that does require building L-SMASH itself (https://github.com/l-smash/l-smash) and [FFmpeg or Libav] first, and then the LSMASHSource AviSynth plugin. For the VapourSynth plugin, all of that can be done in GCC, for the AviSynth plugin, you have to use MSVC and manually copy things like AviSynth's headers/lib around first.

[Sparktank]

Thanks for those!

Especially for the hydra3333 fork.

I never really thought to search for it on github in case someone created a fork.

It'll be nice to check on the commits.

[LigH]

As I did not install any MSVC, I'll have to wait for a new binary AviSynth compatible release by anyone else then...

[LigH]

But there is noone else?

[DJATOM]

x64 version (AvisynthPluginInit3) with ffmpeg libs built near 1 month ago: https://mega.nz/#!GTxkmbJD!FgOYX1dJV8XWqus-c-Y2fT9tBRdtOEm5BmZ2nwM4xiw
x86 will require building 32 bit libs for linking, I'm too lazy for this.

[MysteryX]

There's a nasty bug in LWLibavVideoSource causing misplaced frames under certain circumstances
https://forum.doom9.org/showthread.php?p=1814489#post1814489
This bug still hasn't been resolved, so I'll post it again.

[MysteryX]

I was reading this about FFSM2. Does the same issue apply to L-SMASH Source when not using cache file?

FFAudioSource will have to remake any index implicitly created by FFVideoSource and therefore code like
AudioDub( FFVideoSource(X), FFAudioSource(X) )
will require two indexing passes. Apart from the time consumed this is harmless. To work around it open the audio first.

[LigH]

IIRC, only one of them required this quirk, so if it was FFMS2, it's not LSW. But it doesn't hurt to write scripts in this order (if you need audio at all, use it first) in any case.

[masterkivat]

x64 version (AvisynthPluginInit3) with ffmpeg libs built near 1 month ago: https://mega.nz/#!GTxkmbJD!FgOYX1dJV8XWqus-c-Y2fT9tBRdtOEm5BmZ2nwM4xiw
x86 will require building 32 bit libs for linking, I'm too lazy for this.

I hope someone can provide a 32-bit build anytime soon :) :thanks:

[l33tmeatwad]

So this was kind of a pain to figure out so I decided I would post some build notes to help anyone else out trying to compile their own. The static libs build is a single DLL file and the shared libs contains the libav DLLs.

LSMASHSource r941 (hydra3333 Mod (https://github.com/hydra3333/L-SMASH-Works))
Static Libs Build (x86 & x64) (http://www.mediafire.com/file/id4dp2zqha08wvx/) | Shared Libs Build (x86 & x64) (http://www.mediafire.com/file/6pd12ypbvhb8m9c/) | Sources (https://www.mediafire.com/folder/3tv37w2c9ibps/Source)
Bonus: FFMS2 with Shared Libs (http://www.mediafire.com/file/dffpprzgud9xid6/)

Build Notes:
Compiled with Microsoft Visual Studio 2015
Shared Libs & Include Files were copied to the Visual Studio Directories in: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
Patch included with previous releases was applied to FFmpeg before compiling.

Static FFmpeg compiled with:
./configure --toolchain=msvc --enable-gpl --enable-version3 --disable-encoders --disable-programs --disable-filters \
--disable-network --disable-doc --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter --enable-avresample
make install
Shared Libs FFmpeg compiled with:
./configure --toolchain=msvc --enable-gpl --enable-version3 --enable-shared --disable-encoders --disable-programs --disable-filters \
--disable-network --disable-doc --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter --enable-avresample
make install

Visual Studio Project Modifications (x86 Static Build)
Project Properties > Configuration Properties > VC++ Directories
- Include Directories: C:\msys32\usr\local\include
- Library Directories: C:\msys32\usr\local\lib
Project Properties > Configuration Properties > Linker > General
- Additional Library Directories: C:\msys32\usr\local\lib
Project Properties > Configuration Properties > Linker > Input
- Additional Dependencies: libavutil.a;libavcodec.a;libavformat.a;libswscale.a;libavresample.a;

Visual Studio Project Modifications (x64 Static Build)
Project Properties > Configuration Properties > VC++ Directories
- Include Directories: C:\msys64\usr\local\include
- Library Directories: C:\msys64\usr\local\lib
Project Properties > Configuration Properties > Linker > General
- Additional Library Directories: C:\msys64\usr\local\lib
Project Properties > Configuration Properties > Linker > Input
- Additional Dependencies: libavutil.a;libavcodec.a;libavformat.a;libswscale.a;libavresample.a;

Changes to exlibs.cpp (both Static Builds)
//#pragma comment( lib, "libmingwex.a" )
//#pragma comment( lib, "libgcc.a" )
#pragma comment( lib, "lsmash.lib" )
#pragma comment( lib, "bcrypt.lib" )
//#pragma comment( lib, "avutil.lib" )
//#pragma comment( lib, "avcodec.lib" )
//#pragma comment( lib, "avformat.lib" )
//#pragma comment( lib, "swscale.lib" )
//#pragma comment( lib, "avresample.lib" )

Changes to exlibs.cpp (both Builds w/ Shared Libs)
//#pragma comment( lib, "libmingwex.a" )
//#pragma comment( lib, "libgcc.a" )
#pragma comment( lib, "lsmash.lib" )
#pragma comment( lib, "avutil.lib" )
#pragma comment( lib, "avcodec.lib" )
#pragma comment( lib, "avformat.lib" )
#pragma comment( lib, "swscale.lib" )
#pragma comment( lib, "avresample.lib" )

Included Libs:
LibAV (from FFmpeg 4.0) (https://github.com/ffmpeg/ffmpeg/releases)
L-Smash 2.14.5 (https://github.com/l-smash/l-smash/releases)

Other Software:
MSYS2 (https://www.msys2.org/) (i686 & x86_64)
Yasm 1.3.0 (http://yasm.tortall.net/Download.html) (General Use Executables)

[poisondeathray]

Thanks for the updated build

[LigH]

https://cosgan.de/images/smilie/musik/e050.gif
:thanks:

[poisondeathray]

Would it be possible to build an updated vapoursynth vslsmashsource.dll companion please ?

[l33tmeatwad]

Added a copy of FFMS2 that works with the same shared libs in case that's useful for someone, to like safe space and stuff maybe?

[LigH]

That's an interesting bonus. Let's hope they work well.

:thanks:

[l33tmeatwad]

Would it be possible to build an updated vapoursynth vslsmashsource.dll companion please ?
That's low on my priority list, but I'll see what I can do.

[Richard1485]

When decoding 10-bit YUV 4:2:0, is there a need/way to specify whether the source is Rec.709 or Rec.2020? My source is Rec.709.
I'm using this bit of code from the wiki:


## Decoding 10bit, YUV 4:2:0 source
LSMASHVideoSource(<path>, stacked=true, format="YUV420P10")
ConvertFromStacked(bits=10)


It works. I'm just wondering if there's anything else that I need to add.

[sneaker_ger]

Not in that simple script because you are not doing any "real" color conversions (like YUV to RGB or vice versa), only changing the storage format. (But you should set the correct flags in the encoder like x265/x264 you feed the script to.)

[Yanak]

Hello and thank you for the update of L-SMASH,

Previously i was using the FFMS2 shipped with Staxrip ( version 2.23.1 too apparently ), to give it a try I replaced it by the one released with libs and tried to open a .GIF file as input/source and it does not like this :
Indexing using ffmsindex failed with exit code: -1073741701 (0xC000007B)
Tried some other files and getting the same kind of error messages with some MKV's or MP4's containers having some x264 streams inside.

Then tried to replace the ffmsindex.exe provided in the zip file by the one shipped in Staxrip (while keeping all other dll's you provided) and it seems to work like this, not sure what is going on.

Noticed that here https://github.com/FFMS/ffms2/releases there is a different ffmsindex.exe for both x86 and x64 ( hash is different ), while on your release a single one is provided for both, not sure if normal or not.

Using win7 x64 and all the workflow in Staxrip is x64 if this helps.

Thanks a lot :)

Edit : command used triggering the problem when i use your release:

LoadPlugin("H:\StaxRip-x64-1.7.0.6-test\Apps\Plugins\both\ffms2\ffms2.dll")
FFVideoSource("H:\test.mkv", colorspace = "YUV420P8", \
cachefile = "H:\TEMP\test_temp\test.ffindex")

[Richard1485]

Not in that simple script because you are not doing any "real" color conversions (like YUV to RGB or vice versa), only changing the storage format.

Thanks! I should have thought of that. May I ask how I convert the video to 10-bit RGB? (The source is progressive, and I'm using Avisynth+.)

Sorry for this! I've looked at the Wiki but can't work it out. I've never worked with a 10-bit source before...

[Music Fan]

May I ask how I convert the video to 10-bit RGB?
I never did this but it's probably ConvertToRGBP10 ;
http://avisynth.nl/index.php/Avisynthplus_color_formats

And maybe add matrix="Rec709".

[Richard1485]

^ Yeah, thanks. :-) That's what I tried (with the matrix), but I received the standard "There is no function..." error message.

[sl1pkn07]

So this was kind of a pain to figure out so I decided I would post some build notes to help anyone else out trying to compile their own. The static libs build is a single DLL file and the shared libs contains the libav DLLs.

LSMASHSource r941 (hydra3333 Mod (https://github.com/hydra3333/L-SMASH-Works))
Static Libs Build (x86 & x64) (http://www.mediafire.com/file/id4dp2zqha08wvx/) | Shared Libs Build (x86 & x64) (http://www.mediafire.com/file/6pd12ypbvhb8m9c/) | Sources (https://www.mediafire.com/folder/3tv37w2c9ibps/Source)
Bonus: FFMS2 with Shared Libs (http://www.mediafire.com/file/dffpprzgud9xid6/)

Build Notes:
Compiled with Microsoft Visual Studio 2015
Shared Libs & Include Files were copied to the Visual Studio Directories in: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
Patch included with previous releases was applied to FFmpeg before compiling.

Static FFmpeg compiled with:
./configure --toolchain=msvc --enable-gpl --enable-version3 --disable-encoders --disable-programs --disable-filters \
--disable-network --disable-doc --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter --enable-avresample
make install
Shared Libs FFmpeg compiled with:
./configure --toolchain=msvc --enable-gpl --enable-version3 --enable-shared --disable-encoders --disable-programs --disable-filters \
--disable-network --disable-doc --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter --enable-avresample
make install

Visual Studio Project Modifications (x86 Static Build)
Project Properties > Configuration Properties > VC++ Directories
- Include Directories: C:\msys32\usr\local\include
- Library Directories: C:\msys32\usr\local\lib
Project Properties > Configuration Properties > Linker > General
- Additional Library Directories: C:\msys32\usr\local\lib
Project Properties > Configuration Properties > Linker > Input
- Additional Dependencies: libavutil.a;libavcodec.a;libavformat.a;libswscale.a;libavresample.a;

Visual Studio Project Modifications (x64 Static Build)
Project Properties > Configuration Properties > VC++ Directories
- Include Directories: C:\msys64\usr\local\include
- Library Directories: C:\msys64\usr\local\lib
Project Properties > Configuration Properties > Linker > General
- Additional Library Directories: C:\msys64\usr\local\lib
Project Properties > Configuration Properties > Linker > Input
- Additional Dependencies: libavutil.a;libavcodec.a;libavformat.a;libswscale.a;libavresample.a;

Changes to exlibs.cpp (both Static Builds)
//#pragma comment( lib, "libmingwex.a" )
//#pragma comment( lib, "libgcc.a" )
#pragma comment( lib, "lsmash.lib" )
#pragma comment( lib, "bcrypt.lib" )
//#pragma comment( lib, "avutil.lib" )
//#pragma comment( lib, "avcodec.lib" )
//#pragma comment( lib, "avformat.lib" )
//#pragma comment( lib, "swscale.lib" )
//#pragma comment( lib, "avresample.lib" )

Changes to exlibs.cpp (both Builds w/ Shared Libs)
//#pragma comment( lib, "libmingwex.a" )
//#pragma comment( lib, "libgcc.a" )
#pragma comment( lib, "lsmash.lib" )
#pragma comment( lib, "avutil.lib" )
#pragma comment( lib, "avcodec.lib" )
#pragma comment( lib, "avformat.lib" )
#pragma comment( lib, "swscale.lib" )
#pragma comment( lib, "avresample.lib" )

Included Libs:
LibAV (from FFmpeg 4.0) (https://github.com/ffmpeg/ffmpeg/releases)
L-Smash 2.14.5 (https://github.com/l-smash/l-smash/releases)

Other Software:
MSYS2 (https://www.msys2.org/) (i686 & x86_64)
Yasm 1.3.0 (http://yasm.tortall.net/Download.html) (General Use Executables)

this is a avs 2.5 API. can you update this to avs 2.6? greetings

[StainlessS]

^ Yeah, thanks. :-) That's what I tried (with the matrix), but I received the standard "There is no function..." error message.

Got same message here using trial avs+ from a couple of days back (not todays issue).

Tried with RT_Stats Make_Avisynth_BuiltIn_FunctionList.avs
Got this (partial output below)


AviSynth+_0.1_(r2693,_MT,_i386)_ORDERED_Function_List


There follows a list of all function names together with CPP style argument specifiers that inform
Avisynth the argument types and optional names. Optional arguments have square brackets surrounding
their name as in [name] and are followed by a type specifier character that gives the type.
Unnamed arguments are not optional. eg "cc[arg1]b[arg2]i" would be two compulsory unnamed clip args,
followed by optional 'arg1' of type bool and optional 'arg2' of type int.

# Argument type specifier strings.
c - Video Clip
i - Integer number
f - Float number
s - String
b - boolean
. - Any type (dot)
# Array Specifiers
i* - Integer Array, zero or more
i+ - Integer Array, one or more
.* - Any type Array, zero or more
.+ - Any type Array, one or more
# Etc
###################################

BitsPerComponent "c"
BuildPixelType "[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"
ColorSpaceNameToPixelType "s"
CombinePlanes "cccc[planes]s[source_planes]s[pixel_type]s[sample_clip]c"
ComponentSize "c"
ConvertBackToYUY2 "c[matrix]s"
ConvertBits "c[bits]i[truerange]b[dither]f[dither_bits]i[fulls]b[fulld]b"
ConvertTo16bit "c[bits]i[truerange]b[dither]f[dither_bits]i[fulls]b[fulld]b"
ConvertTo8bit "c[bits]i[truerange]b[dither]f[dither_bits]i[fulls]b[fulld]b"
ConvertToFloat "c[bits]i[truerange]b[dither]f[dither_bits]i[fulls]b[fulld]b"
ConvertToMono "c"
ConvertToPlanarRGB "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s"
ConvertToPlanarRGBA "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s"
ConvertToRGB "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s"
ConvertToRGB24 "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s"
ConvertToRGB32 "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s"
ConvertToRGB48 "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s"
ConvertToRGB64 "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s"
ConvertToY "c[matrix]s"
ConvertToY8 "c[matrix]s"
ConvertToYUV411 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s"
ConvertToYUV420 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s"
ConvertToYUV422 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s"
ConvertToYUV444 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s"
ConvertToYUY2 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s"
ConvertToYV12 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s"
ConvertToYV16 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s"
ConvertToYV24 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s"
ConvertToYV411 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s"
Is420 "c"
Is422 "c"
Is444 "c"
IsFloatUvZeroBased ""
IsPackedRGB "c"
IsPlanar "c"
IsPlanarRGB "c"
IsPlanarRGBA "c"
IsRGB "c"
IsRGB24 "c"
IsRGB32 "c"
IsRGB48 "c"
IsRGB64 "c"
IsVideoFloat "c"
IsY "c"
IsY8 "c"
IsYUV "c"
IsYUVA "c"
IsYUY2 "c"
IsYV12 "c"
IsYV16 "c"
IsYV24 "c"
IsYV411 "c"
MergeARGB "cccc"
MergeChroma "cc[chromaweight]f"
MergeLuma "cc[lumaweight]f"
MergeRGB "ccc[pixel_type]s"
NumComponents "c"
PixelType "c"
PlaneToY "c[plane]s"
RemoveAlphaPlane "c"
ShowAlpha "c[pixel_type]s"
ShowBlue "c[pixel_type]s"
ShowGreen "c[pixel_type]s"
ShowRed "c[pixel_type]s"
ShowU "c[pixel_type]s"
ShowV "c[pixel_type]s"
ShowY "c[pixel_type]s"
VToY "c"
VToY8 "c"
YToUV "cccc"
YToUV "cccc"
YToUV "cccc"


This works OK

ColorBars.Killaudio
#ConvertToRGBP10(Matrix="rec709") # Fail
#ConvertToPlanarRGB "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s"
#ConvertBits "c[bits]i[truerange]b[dither]f[dither_bits]i[fulls]b[fulld]b"
ConvertToPlanarRGB() # Presumably dont need matrix here as from RGB
ConvertBits(10)
Info
ConverttoRGB32 # for display


https://s20.postimg.cc/u6wy8varh/R1485.jpg (https://postimages.org/)

EDIT: ConvertBits only works on Planar RGB, but OK on Planar YUV, eg YV12,
produces ColorSpace: YUV420P10, BitsPerComponent: 10.

EDIT:
AviSynth+_0.1_(r2693_ORDERED_Function_List.TXT.7z (Does not included any updated builtin filter definitions for todays updated avs+).
7Zip file ~5KB, expanded ~ 22KB text file.
http://www.mediafire.com/file/3ub7ldg860qdl87/AviSynth+_0.1_%28r2693_ORDERED_Function_List.TXT.7z

EDIT: Have extended partial output of builtin function definitions earlier in this post, Its possible that I may have missed one or two out.

EDIT: Only Single function definitions given in earlier text file, eg BlankClip has multiple alternate arg lists, but the RT_Stats script
cannot output multiple, they all produce same result text (there was no way to parse multiples external to avs Standard, I assume this has not changed in avs+).

EDIT: The ColorSpaceNameToPixelType() listed takes a colorspace name eg "RGBP10" and returns hex 0x90050001 [internal bit flags descriptor].
Perhaps some other missing definition (missing multiple definition) can take a PixelType and produce a clip, maybe eg
BlankClip(PixelType) exists, dont know (or some clip conversion filter).

[Richard1485]

^ I appreciate your help and interest in this problem. With your script, I get an error message that says: "There is no function named ConvertToPlanarRGB()", which baffles me. When I call Version(), the correct AviSynth+ version is displayed: I'm using the one released today (r1576, x64).

[poisondeathray]

I'm using the one released today (r1576, x64).

Seems old ? StainlessS is on r2693 if you look above

[LigH]

Page
long
full
quote
wasting
space
One line

Just a matter of taste? :rolleyes:

If I refer to a specific part of a quote, I crop the quote down to the relevant part. Or just mention "@ author".
__

@ Richard1485:

Still the "ancient" version from http://avs-plus.net/ ... no, this page seems to be abandoned since 2014.

[Richard1485]

Seems old ?

That's very strange, because I reinstalled it today. But you're right. It must be picking up an old version from somewhere. I'll try installing it again.

EDIT: Okay. The version information is now correct. (Thanks, LigH!)

EDIT: Now there's a message about the conversion to RGB being possible only from an 8-bit source. It must be the call to ConvertToRGB32() at the end.

EDIT: Well, if I remove the call to ConvertToRGB32(), the error message goes away, but VirtualDub2 chokes on the video because it "can't locate a decompressor for format "G3[0][10]" (unknown)".

[pinterf]

Ok. In latest avs+ _test_ build, see avs+ topic for r2696, I have made ConvertoRgb32 callable from any bitdepth, helping the previewing. When you removed the conversion, your clip is fed to vdub as planar 10 bit rgb fooucc code: G3[0][10] which is not handled by your system. You may do Convertbits(8).Converttorgb32 or Convertbits(16). Converttorgb64 if you are using avs+ r2664 (latest official). Latter needs Vdub2

[Richard1485]

Yeah, I guessed the reason for the last error message. Thanks! Is ConvertToRGBP10() not an option at present? I'm just trying to get my head round this high bit-depth stuff. ☺

[qyot27]

Is ConvertToRGBP10() not an option at present?
IMO, there's way too many* new pixel formats added to AviSynth+ to add explicit bridging functions for all of them to the core. A better place for them - if you really feel like you need direct shortcuts, rather than using the more generic functions added to AviSynth+ to handle this - would be to break them out into an AVSI file like the colors_rgb list is. Otherwise it's a lot of nearly-identical code copy-pasted over and over again with only minor changes, for each destination format.

*you can see them all listed in the AviSynth+ headers (link directs only to the new set, just scroll up a little for the 2.5/2.6 formats):
https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/include/avisynth_c.h#L146

That's 52 new pixel formats. And most of the internal bridges would just be invoking a combination of ConvertBits and ConvertTo[YUV***|PlanarRGB(A)], which like I said, is much easier to just break out into an AVSI:
function ConvertToRGBP10(clip c)
{
ConvertToPlanarRGB(c)
ConvertBits(10)
}
That is, of course, just an example and doesn't enable most of the underlying extra params from ConvertBits and ConvertToPlanarRGB, but those could be passed through with minimal effort, right there in the AVSI.

[Richard1485]

Oh, I see. I'm not one for writing procedures/functions, but that looks pretty simple. And if that's how they would be implemented internally, then I don't mind doing it the long way. Thanks!

[qyot27]

Obviously, the optimal solution would be for a generic master ConvertToPixelFormat() (or just plain old ConvertTo(), but I figured the main one I suggest should be more explicit about what it does) function that can convert between YUV(A), Y, Planar/Packed RGB(A) and change bitdepth at the same time, either by the user selecting the bitdepth separately or by taking it from the dest format name. A master function like that wouldn't massively reduplicate code and, IMO, would be fine to include in the core*. For instance:
input()
ConvertToPixelFormat("YUV420P16", extra_opts)
or
input()
ConvertToPixelFormat("YUV420", bit_depth=16, extra_opts)
Or you know, the same function as-written could do either of those, since 'YUV420P16' and 'YUV420' are both valid format names; the difference is just whether you'd have to declare any of the extra_opts explicitly because there's also a dedicated bit_depth= parameter.

*and before anyone hits me with the 'AviSynth+ doesn't do implicit conversions' thing, filters shouldn't silently change the input format to do the processing. A master ConvertTo function is always an explicit conversion, so that criticism doesn't apply.

[Richard1485]

That solution does sound feasible. Even if it's never included in the core, perhaps someone will write an .avsi for it all at some point.

[pinterf]

Then there is the z.lib resizer plugin, see z_ConvertFormat as a swiss-army knife.
Color-space, primaries, bit-depth, size conversion - all-in-one.
https://forum.doom9.org/showthread.php?p=1784316

[Gser]

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.

[LigH]

Decoding interlaced VC-1 was always a problem, not sure if it was ever completely fixed... can you provide samples? If it fails for "usual" progressive VC-1 as well, which worked with earlier versions, then there may be a regression in libavcodec?

[sneaker_ger]

Two samples:
https://drive.google.com/file/d/0BwxFVkl63-lERnhlY1pHeW5wbjQ/view (interlaced)
https://drive.google.com/file/d/0BwxFVkl63-lETFVpOWRVVGNfeEU/view (progressive)
(via https://kodi.wiki/view/Samples )

No problem with ffmpeg git.

[videoh]

The files look fine as both decode without problems with DGDecNV and Avisynth+.

I don't understand the big problem with interlaced VC-1. There's nothing special about it.

[LigH]

May be in combination with the container, correct demultiplexing and joining the contained video streams from interleaving segments. FFMS2 used to have issues with interlaced AVC in TS (may have been due to its early dependency on Haali). "Nobody is perfect"... and I know nothing about the details, there are only vague memories.

Quick test: Both L-SMASH Works r929 (20170224) Static in MeGUI and r941 (20180530) Shared fail the same way, already with the progressive source (VC-1_23.976_sample.mkv). FFMS 2.23-1 Static in MeGUI and FFMS2 (bonus) Shared decode it correctly. — Known as L-SMASH-Works issue #58 (https://github.com/VFR-maniac/L-SMASH-Works/issues/58).

At least I hope that they got correctly assigned...

ClearAutoloadDirs()
LoadPlugin("E:\Programme\MeGUI\tools\lsmash\LSMASHSource.dll")
LwLibavVideoSource("VC-1_23.976_sample.mkv")
vs.
ClearAutoloadDirs()
LoadPlugin("E:\Programme\AviSynth+\plugins\LSMASHSource.dll")
LwLibavVideoSource("VC-1_23.976_sample.mkv")

Note: The FFMS2_2.23.1_MSVC_SharedLibs.7z contains 64 bit libav DLL's in the x86 subdirectory. The ones in LSMASHSource_r941_MSVC_SharedLibs_hydra3333.7z are correct for 32 bit.

[Gser]

May be in combination with the container, correct demultiplexing and joining the contained video streams from interleaving segments. FFMS2 used to have issues with interlaced AVC in TS (may have been due to its early dependency on Haali). "Nobody is perfect"... and I know nothing about the details, there are only vague memories.

Quick test: Both L-SMASH Works r929 (20170224) Static in MeGUI and r941 (20180530) Shared fail the same way, already with the progressive source (VC-1_23.976_sample.mkv). FFMS 2.23-1 Static in MeGUI and FFMS2 (bonus) Shared decode it correctly. — Known as L-SMASH-Works issue #58 (https://github.com/VFR-maniac/L-SMASH-Works/issues/58).


Just plain progressive. I remuxed it to m2ts and it played properly, then I reremuxed it to mkv and got the same problems again. So yeah their seems to be a problem with decoding MKV. If I remember correctly this happened even before the update to the new ffmpeg.

PS. Don't make the same mistake I did with updating FFMS, the package only includes the 32-bit version of ffmsindex

[l33tmeatwad]

this is a avs 2.5 API. can you update this to avs 2.6? greetings
Low priority on my todo list, but I'll try to get around to it.

[l33tmeatwad]

Patched LSMASHSource to use swresample instead of avresample since ffms2 now requires that and I like the ability to have these share the same libs without excess bloat. Needs to be tested, it can be found on GitHub (https://github.com/l33tmeatwad/L-SMASH-Works/releases). Would appreciate it if someone with more experience working with the FFmpeg libs would look over it...

[magiblot]

As the wiki (http://avisynth.nl/index.php/LSMASHSource/LWLibavVideoSource) suggests, I tried to set decoder="h264_qsv,mpeg2_qsv" hoping that I would experience a speed boost or a reduction in CPU usage (assuming 'qsv' stands for 'Intel QuickSync Video'), but I saw none.

In fact, it doesn't matter what I put into the decoder parameter, LWLibavVideoSource won't complain at all.

Am I not using this feature properly or is it not implemented yet?

Thanks.

[DJATOM]

It need to be compiled with mfx_dispatcher in order to make qsv decoding works. Also It's not frame accurate, or more precise notice "it might return green frames on seeking". But I still got ~400 fps with 4670k, so I'm using qsv for fast source preview.
I also managed to make cuvid decoder works, but it has issues with seeking as well.

[magiblot]

Oh. Since a index file is created, I was hoping accurate seeking would be possible. Is it still any better than DirectShowSource?

How do I compile the plugin with mfx_dispatcher?

Thanks.

[LigH]

I would assume that the index file is used for all frames only when L-SMASH Source decodes using the software decoder in libavcodec. But if you use a hardware decoder provided by your GPU (if that is implemented at all), then it will need to upload the video stream to be decoded into the decoder chip at least GOP-wise, and lose frame-accurate control partially.

[magiblot]

I have never written or even looked into a video decoder.

However, if I understand right the idea of GOP, and asuming that you seek to a frame in the middle of a GOP, couldn't the source plugin get the decoded GOP from the decoder and then discard frames until it gets to the sought frame?

Since the source video was indexed previously, I guess the source plugin knows where each GOP starts and in what position inside the GOP the requested frame is.

However, I also guess that if it was that simple it would have already been done.

[DJATOM]

Smart decoder might not discard frames behind decoded one in the GOP, as it might be requested upon further seeking. But issue with qsv is by Intel, as they broke something (Donald described this issue on his forum). Probably the only workaround is to check for decoded frame and request new on error.

[Selur]

A fresh build to support av1 would be great. :)
Thanks!

[Monamona]

VFR maniac,

Thank you for providing useful filters.

In the future, is there any chance to have an option to create and read the index file (.lwi) in any directory other than at the source file?

I want to read a file located in DVD or BD by LWLibavVideo(Audio)Source, without copying the file to HDD.

Thank you in advance.

[LigH]

@Monamona:

Reading from authored files on optical discs is not recommendable for at least 2 reasons:

a) authored content may be logically spread across several file segments, and L-SMASH Works cannot read from more than one source file, and surely not follow the logical path (e.g. ProGram Chain across VOB segments of a DVD Video, as defined in IFO files)

b) optical devices are stressed by random instead of sequential reading, and multi-threaded decoding may seek forth and back

To convert with AviSynth based tools, you should always extract a logical "movie" from the optical disc to a harddisk into one continuous file (e.g. MakeMKV can handle both DVD and Blu-ray Video media).

[redbtn]

If cache=0 i get vspipe error. This is L-Smash or VapourSynth problem?
[2019-02-15][02:29:44] "C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --info F:\MKV\input.vpy -
[2019-02-15][02:29:44]
[2019-02-15][02:29:44] [hevc @ 0000020ecf48bc20] missing picture in access unit
[2019-02-15][02:29:44] [hevc @ 0000020ecf48bc20] missing picture in access unit
[2019-02-15][02:29:44] [hevc @ 0000020ecf48bc20] missing picture in access unit
[2019-02-15][02:29:44] [hevc @ 0000020ecf48bc20] missing picture in access unit
[2019-02-15][02:29:44] [hevc @ 0000020ecf48bc20] missing picture in access unit
[2019-02-15][02:29:44] [hevc @ 0000020ecf48bc20] missing picture in access unit
[2019-02-15][02:29:44] [hevc @ 0000020ecf48bc20] missing picture in access unit

and more same strings

[Sparktank]

Thanks for this and FFMPEG updates.

[VS_Fan]

L-SMASH-Works-r935+3-win64-20190401.7z (https://www.mediafire.com/file/x9jh1an91n9bg31/L-SMASH-Works-r935+3-win64-20190401.7z/file)

Thanks, here my problem report:

Avisynth Error: LSMASHVideoSource [Fatal]: Failed to read an input file

vapoursynth.Error: lsmas: failed to open source file.

[VS_Fan]

Sorry, should have tested more before reporting: I thought there was no need for a script as it was just the source filter, I am testing my new batch of 12 recently found DV 199x recordings (AVI).

Your build is fine. I found that instead of LSMASHVideoSource and lsmas.LibavSMASHSource, both LWLibavVideoSource (AviSynth) & lsmas.LWLibavSource (VapourSynth) work just fine on these AVI files.

Thanks again

[LigH]

@VS_Fan: As documented: "LSMASH...Source" functions support only containers compatible to the ISO base media file format (https://en.wikipedia.org/wiki/ISO_base_media_file_format) (MOV, MP4, 3GPP and similar), but not AVI.

@HolyWu: Thank you for the new Win64 build. A pity I can't use it when I need to use legacy AviSynth 2.5 filters which are available for Win32 only.

[fvisagie]

@HolyWu: Thank you for the new Win64 build. A pity I can't use it when I need to use legacy AviSynth 2.5 filters which are available for Win32 only.

And I am on a Win32 *system*, so any update for that would be roundly welcomed! :-)

[stax76]

If I understand it correctly then l-smash for avs will by default output a double width format for 10bit (or more) sources. I can use ConvertFromDoubleWidth to get it into planar but how can I detect in avisynth code if it has double width format and which bit depth it is?

[stax76]

I can do in pseudo code:

if width / height > 3.5 then ConvertFromDoubleWidth

[stax76]

935 from the link above might have a memory leak problem.

[LigH]

If you want to use L-SMASH Works in AviSynth also for audio processing, you may want to prefer LwLibavAudioSource over LSMASHAudioSource even for ISO base media containers. I had an MP4 as source which contains AVC video and AAC audio (surprisingly in 44.1 kHz, possibly accidently resampled). Using LSMASHAudioSource, the audio contained annoying crackles; using LwLibavAudioSource, the sound was clean.

[stax76]

If you want to use L-SMASH Works in AviSynth also for audio processing

Audio processing with avs is not something staxrip does by default.

Which build are you using? Maybe have a look in task manager regarding memory consumption.

[LigH]

My report was not directed specifically to you, stax76, rather to the general audience. :p

I have a file date 2018-05-30. Probably LSMASHSource r941 MSVC hydra3333.

[stax76]

@LigH

staxrip was using 929, I've checked 941 memory usage and it's fine.

L-SMASH Source 941:

http://www.mediafire.com/file/id4dp2zqha08wvx/

[LigH]

I don't think the crackling sound of my issue is related to a memory leak, rather to the L-SMASH demultiplexer handling audio streams incorrectly (the libav demultiplexer instead works correctly).

[Forteen88]

I don't get it, which L-SMASH should I use? Should I use L-SMASH-Works-r935+3-win64-20190401 or L-SMASH Source 941, or l33tmeatwad's "SWResample Test"-version that was released 2018-Jun-20?

[stax76]

Removed parameter stacked. Now supports native high bit depth format.

Sounds awesome, thank you.

[stax76]

What I don't understand is, when I close the avifile API the memory is not instantly reclaimed entirely.

[MeteorRain]

I also have a copy at https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works basically I integrated patches from multiple forks.

Binaries compiled by myself can be found at https://down.7086.in/AviSynthPlus%20Filters/LSMASHSource-Release_r935%2B26.zip .

[Sparktank]

L-SMASH-Works-r935+25-win64-20190711 (https://www.mediafire.com/file/tjtjrwc63vjxi9e/L-SMASH-Works-r935+25-win64-20190711.7z/file)


Thanks for this update!

basically I integrated patches from multiple forks.

Can you tell us a little more about these patches?

[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.

[stax76]

:thanks:

[Atak_Snajpera]

Feature request:
Add option cachefile to LWLibavVideoSource so user can specify where index file will be created.
Example
LWLibavVideoSource("..\video.mkv",cachefile="C:\temp\MyIndex.lwi")

Currently LWLibavVideoSource is creating index file in the same folder as source video and thus creating an annoying mess.

BTW. Standalone indexer similar to ffmsindex.exe would be also useful.

[MeteorRain]

I recalled I found one on GitHub before, but it was not maintained for a few years.

[StainlessS]

To maybe avoid possible misunderstanding and unnecessary work,



ffms2_ORDERED_Function_List


There follows a list of all function names together with CPP style argument specifiers that inform
Avisynth the argument types and optional names. Optional arguments have square brackets surrounding
their name as in [name] and are followed by a type specifier character that gives the type.
Unnamed arguments are not optional. eg "cc[arg1]b[arg2]i" would be two compulsory unnamed clip args,
followed by optional 'arg1' of type bool and optional 'arg2' of type int.

# Argument type specifier strings.
c - Video Clip
i - Integer number
f - Float number
s - String
b - boolean
. - Any type (dot)
# Array Specifiers
i* - Integer Array, zero or more
i+ - Integer Array, one or more
.* - Any type Array, zero or more
.+ - Any type Array, one or more
# Etc
###################################


FFAudioSource "[source]s[track]i[cache]b[cachefile]s[adjustdelay]i[utf8]b[varprefix]s"
FFGetLogLevel ""
FFGetVersion ""
FFIndex "[source]s[cachefile]s[indexmask]i[dumpmask]i[audiofile]s[errorhandling]i[overwrite]b[utf8]b"
FFSetLogLevel "i"
FFVideoSource "[source]s[track]i[cache]b[cachefile]s[fpsnum]i[fpsden]i[threads]i[timecodes]s[seekmode]i[rffmode]i[width]i[height]i[resizer]s[colorspace]s[utf8]b[varprefix]s"

Perhaps it is not the standalone, but plugin function that is required. [Ffindex.Exe is not required to call ffindex() in script].

and just for good luck.


LSMASHSource_ORDERED_Function_List

LSMASHAudioSource "[source]s[track]i[skip_priming]b[layout]s[rate]i[decoder]s"
LSMASHVideoSource "[source]s[track]i[threads]i[seek_mode]i[seek_threshold]i[dr]b[fpsnum]i[fpsden]i[stacked]b[format]s[decoder]s"
LWLibavAudioSource "[source]s[stream_index]i[cache]b[av_sync]b[layout]s[rate]i[decoder]s"
LWLibavVideoSource "[source]s[stream_index]i[threads]i[cache]b[seek_mode]i[seek_threshold]i[dr]b[fpsnum]i[fpsden]i[repeat]b[dominance]i[stacked]b[format]s[decoder]s"

[MeteorRain]

I meant I found a standalone version of lsmash indexing tool on GitHub -- if that was causing misunderstanding.

Although I'm just using symbolic links to link the source into encoding directory, so no pollution to the sources.

[StainlessS]

Was intended just incase Atak_Snajpera thought ffmsindex.exe was required for indexing in script via ffmsindex(clip).
[I at one time thought that the executable was necessary for indexing].

[stax76]

cachefile feature would be very helpful and it would be awesome if the filter would write progress like 'Progress: 1%' to stdout.

Please note that any code can write to stdout, console tools can but GUIs and libraries like LSMASHSource.dll can do that as well.

An indexing app would be nice but using ffmpeg or vspipe will work as well:

Using proc As New Proc
proc.Header = "Index LWLibav"
proc.Encoding = Encoding.UTF8

If p.Script.Engine = ScriptEngine.AviSynth Then
proc.File = Package.ffmpeg.Path
proc.Arguments = "-i " + p.Script.Path.Escape + " -hide_banner"
Else
proc.File = Package.vspipe.Path
proc.Arguments = p.Script.Path.Escape + " NUL -i"
End If

proc.AllowedExitCodes = {0, 1}
proc.Start()
End Using

[manolito]

Another question about the different LSMASH versions...

A while ago Ligh recommended to use the LSMASH versions which come with the current MeGUI distribution. Maybe not the latest and greatest, but proven and well tested. I did that (pleasantly surprised about the included latest XP-compatible version), and the non-XP version from the MeGui download is r929.

I used this version without any problems, but now I see that there are some newer builds which also incorporate a couple of patches, and I am curious again... :)

There is r941 by hydra3333, and also interesting is r935 by MeteorRain. I only need the 32-bit versions, and they should work under classic AVS 2.60 as well as under the latest AVS+ version. And stability is my major concern.

I did some test conversions with r935 by MeteorRain under classic AVS 2.61 Alpha without any problems. 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?

Cheers
manolito

[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

[Reel.Deel]

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

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

The same patch set HolyWu used, which was copied from enccc (https://github.com/enccc/L-SMASH-Works/tree/mod), and one more patch to use swresample instead of avresample, which was copied from l33tmeatwad (https://github.com/l33tmeatwad/L-SMASH-Works).

I've started a section in the LSMASHSource wiki (http://avisynth.nl/index.php/LSMASHSource#Archived_Downloads) 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]

L-SMASH-Works-r935+31-20190818 (https://www.mediafire.com/file/ext0tds407sodbq/L-SMASH-Works-r935+31-20190818.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 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.

[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]

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-scripts/blob/master/L-SMASH/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]

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 (https://down.7086.in/AviSynthPlus%20Filters/LSMASHSource-Release_r935%2B33.zip)
Commit Diff (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/commit/9613f894ed40e67104c4f3df335c9e322b9c5d1f)

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/dldzx9smmbxf60m/vc1_sample.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
https://i.imgsafe.org/79/798bacc148.png

PS. yes I have latest driver installed.

[DJATOM]

@Atak_Snajpera
HW decoder is actually inactive on your screenshot.

[Atak_Snajpera]

@Atak_Snajpera
HW decoder is actually inactive on your screenshot.

But CPU usage is 3 times lower so it works.
https://i.imgsafe.org/7b/7bde32fd60.png

Also there is H/W indicator
https://i.imgsafe.org/7b/7ba4848e67.png

[MeteorRain]

https://down.7086.in/AviSynthPlus%20Filters/LSMASHSource-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. :)

[MeteorRain]

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

[Natty]

:thanks:https://down.7086.in/AviSynthPlus%20Filters/LSMASHSource-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]

@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/avsrepo/blob/master/local/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.

[Atak_Snajpera]

L-SMASH-Works_20190903.7z (https://github.com/HolyWu/L-SMASH-Works/releases/download/20190903/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.php?p=1883899#post1883899

[FranceBB]

L-SMASH-Works_20190903.7z (https://github.com/HolyWu/L-SMASH-Works/releases/download/20190903/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!

[Atak_Snajpera]

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.
https://i.imgsafe.org/5c/5c0a9ddd47.png

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]

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]

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.

[videoh]

Thank you, HolyWu.

[Reel.Deel]

L-SMASH-Works_20190903.7z (https://github.com/HolyWu/L-SMASH-Works/releases/download/20190903/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 (https://github.com/HolyWu/L-SMASH-Works/commits/master) says otherwise, am I missing something?

MeteorRain's L-Smash GitHub repo (https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/commits/master) is up-to-date minus the your recent commits.

[Atak_Snajpera]

Two issues with latest version

1) Corrupted (grey frames) frames after seeking
Sample -> https://www.mediafire.com/file/ana6jo26jz4n6sw/Aquaman_sample.mkv/file
https://i.imgsafe.org/54/547128fbf2.png
https://i.imgsafe.org/54/5471b5bdd2.png

2) webm with AV1 returns this error
Sample -> https://www.mediafire.com/file/lq3xmqsdeewme38/Stream2_AV1_HD_6.8mbps.webm/file
https://i.imgsafe.org/54/5471d29141.png

[Atak_Snajpera]

1. I got that sample from an ripbot user. I guess that this avc was originally muxed by makemkv. IT is odd that Simple remuxing (MKV to mkv)with latest mkvtoolnix did not fix that issue.
2.ok

[sneaker_ger]

The PPS changes mid-stream (pic_init_qp_minus26 changes). Mkvmerge seems to detect this when doing a "full" remux (1. demux to ES. 2. mux ES) and prepends the SPS/PPS to every keyframe. In the original sample it is only prepended on an actual change compared to the prior keyframe. Since both frame #97 and #104 use the same pic_init_qp_minus26 frame #104 does not have this prepended PPS. Then decoder tries to use first/global pic_init_qp_minus26 and breaks.

[Atak_Snajpera]

Crash after seeking
Sample -> https://www.mediafire.com/file/xhcyglsbsz4nbgm/camcorder_25i_4-3.avi/file
https://i.imgsafe.org/66/66c8bb586f.png
https://i.imgsafe.org/66/66c920bbbd.png

FFVideoSource works fine.

[Atak_Snajpera]

Cannot reproduce. I'm using seek-test.py (https://gist.github.com/dubhater/3a2c8a59841cae49ecae25cd47ff78d2) for testing.

Because your tool does not check ALL frames.

Just try to open this script in MPC-HC.

LoadPlugin("LSMASHSource.dll")
LWLibavVideoSource("camcorder_25i_4-3.avi",cachefile="camcorder_25i_4-3.avi.lwi")
Trim(233,-1)

https://i.imgsafe.org/68/682fd279e1.png

[poisondeathray]

Atak - can you share your Seek Tester tool ?

[videoh]

One way to test all frames is to put Reverse() at the end of your script and then play the video.

[ChaosKing]

Because your tool does not check ALL frames.


The script does check all frames.

I tested it via lsmas.LWLibavSource() and avisource.AVISource("myscript.avs) in vapoursynth -> no seeking issues.

EDIT
Tried also Reverse() in my avs script, still frame accurate.

EDIT2
If I open the avs (with reverse) in vsedit i get an error

vapoursynth.Error: Avisynth read error:
CAVIStreamSynth: System exception - Access Violation at 0x00007FFB37302EB8

But there is no crash via vspipe...

EDIT3
Argh tested with the wrong script... so I tested it again ... VS is fine, but AVS crashes! But only with reverse.
Reverse in my avsisynth script -> instant crash System exception - Access Violation at 0x00007FFB37302EB8
LWLibavVideoSource("camcorder_25i_4-3.avi")
#Reverse()


std.Reverse() in VS is not frame accurate anymore.
avisource.AVISource(args.file).std.Reverse()

log files
- lsmash in VS https://pastebin.com/anyvB4pf
- avisyource + reverse in VS https://pastebin.com/XFkuT9JT (it aborts after 3 errors)

EDIT4
lsmas.LWLibavSource(args.file).std.Reverse() -> lsmas: failed to get video track. Now I'm confused.

EDIT5
ok ... final results
VS
lsmas.LWLibavSource(args.file) #ok
lsmas.LWLibavSource(args.file).std.Reverse() #ERR failed to get video track.

AVS via VS - script: LWLibavVideoSource("camcorder_25i_4-3.avi")
avisource.AVISource(args.file) # ok
avisource.AVISource(args.file).std.Reverse() # not frame accurate

AVS script with:
LWLibavVideoSource("camcorder_25i_4-3.avi")
reverse()
= instant crash: System exception - Access Violation at 0x00007FFB37302EB8

EDIT 6 - Bonus round
Remuxed it to mkv

VS
lsmas.LWLibavSource(args.file) # ok
lsmas.LWLibavSource(args.file).std.Reverse() # [importer: Error]: failed to find the matched importer.

AVS via VS
avisource.AVISource(args.file) # ok
avisource.AVISource(args.file).std.Reverse() #ok

avs+reverse via vdub still crashes.

[videoh]

Does anybody care?

[ChaosKing]

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


Update to FFmpeg 4.2.1.
VideoSource: Add parameter prefer_hw to conveniently switch between software and hardware decoder. Consult README for details.
Fix seeking issue in CUVID decoding.
Fix hardware decoder outputting YUV420P8 by default on high bit depth clip.
Optimize P010->YUV420P10 conversion for hardware decoder by SSE2.
LWLibav: Fix access violation in avi file when seeking randomly.

Fixed all errors for me :thanks:

[FranceBB]

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


Update to FFmpeg 4.2.1.
VideoSource: Add parameter prefer_hw to conveniently switch between software and hardware decoder. Consult README for details.
Fix seeking issue in CUVID decoding.
Fix hardware decoder outputting YUV420P8 by default on high bit depth clip.
Optimize P010->YUV420P10 conversion for hardware decoder by SSE2.
LWLibav: Fix access violation in avi file when seeking randomly.


Once again, thank you! :D

[poisondeathray]

Fix seeking issue in CUVID decoding.


Thanks,

I can confirm this does fix issues on previous lsmash builds .

Very nice :)

[Reel.Deel]

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


Update to FFmpeg 4.2.1.
VideoSource: Add parameter prefer_hw to conveniently switch between software and hardware decoder. Consult README for details.
Fix seeking issue in CUVID decoding.
Fix hardware decoder outputting YUV420P8 by default on high bit depth clip.
Optimize P010->YUV420P10 conversion for hardware decoder by SSE2.
LWLibav: Fix access violation in avi file when seeking randomly.


I cannot load the following apng image with LWLibavSource(). It gives the error LWLibavVideoSource: failed to get the video track. I only tried with latest avs+ (x64).
I tried with L-SMASH-Works_20190903 / 0906 / 0910 and even MeteorRain's LSMASHSource-r935+34 but all of them give the same error. Last version that works is L-SMASH-Works-r935+26-20190811. Gifs work fine though.

https://imgur.com/download/9qLuzS4/

[poisondeathray]

"Regular" PNG isn't working either (images, or PNG in MOV) . There were a bunch of ffms2 versions like that earlier as well

[qyot27]

PNG support requires zlib.

[poisondeathray]

Is there an AVC in MXF parsing issue with L-SMASH-Works_20190910 ?

1a) 10bit422 AVC can be read in MP4 but not MXF "failed to get video track" . But "L-SMASH-Works-r935+3-win64-20190401" was able to read both
1b) But rewrapping that AVC stream into a TS makes it readable

2) 8bit422 MPEG2 in MXF can be read, so can't be a "global" MXF issue with this version

[poisondeathray]

Sorry false alarm . I can't reproduce the issue now. Maybe some windows weirdness (I rebooted somewhere in between) or something I mixed up

[Atak_Snajpera]

Another possible bug. L-SMASH does not return some frames.

https://i.postimg.cc/L5M5bzMn/Untitled-1.png
Again FFVideoSource works fine.

https://i.postimg.cc/4yP54vZS/Untitled-2.png

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

Sample -> https://www.mediafire.com/file/4f7onn4q2l0jo92/TEST.mkv/file

[Atak_Snajpera]

L-Smash does not fallback to software decoders automatically like written in documentation.

+ prefer_hw (default : 0)
Whether to prefer hardware accelerated decoder to software decoder.
Have no effect if 'decoder' is specified.
- 0 : Use default software decoder.
- 1 : Use NVIDIA CUVID acceleration for supported codec, otherwise use default software decoder.
- 2 : Use Intel Quick Sync Video acceleration for supported codec, otherwise use default software decoder.

For example I have NVIDIA card and it works fine with prefer_hw=1 but my CPU does not support Intel Quick Sync Video so with prefer_hw=2 i get this
https://i.imgsafe.org/a7/a7129ea9ab.png

I would also suggest value -1 as AUTO
+ prefer_hw (default : 0)
Whether to prefer hardware accelerated decoder to software decoder.
Have no effect if 'decoder' is specified.
-1 : Use first available hardware decoder,otherwise use default software decoder.
0 : Use default software decoder.
1 : Use NVIDIA CUVID acceleration for supported codec, otherwise use default software decoder.
2 : Use Intel Quick Sync Video acceleration for supported codec, otherwise use default software decoder.

[Atak_Snajpera]

L-Smash detects this mpeg-2 as 59.94 fps instead of 23.976.

Sample -> https://www.mediafire.com/file/jp0a2hh8wz9uevy/Mpeg2-wrongfps.mkv/file

LoadPlugin("LSMASHSource.dll")
LWLibavVideoSource("Mpeg2-wrongfps.mkv")
info
Trim(0,-1)

And yes again FFVideoSource correctly returns 23.976.

[tebasuna51]

L-Smash detects this mpeg-2 as 59.94 fps instead of 23.976.

Like must be.

eac3to v3.34
command line: "C:\Portable\eac3to\eac3to.exe" "C:\tmp\Mpeg2-wrongfps.mkv"
------------------------------------------------------------------------------
MKV, 1 video track, 0:01:00, 60p /1.001
1: MPEG2, 480p24 /1.001 (16:9) with pulldown flags
[v01] The video bitstream framerate field doesn't match the container framerate. <WARNING>

Also DGSource output fps 59.94 because is the fps forced by the container (mkv header show this fps).
Many times we force the fps to be other than video stream to sync with audio.

If the true fps is 23.976 the mkv must be remuxed with that fps.

[fg118942]

HolyWu ver. 20190910.1
Cannot be read if non-ASCII characters are included in the path of a specific file.

For example, this file.
http://www.minori.ph/download/files/wind_demo.mpg

avs file
A = LWLibavAudioSource("C:\テスト\wind_demo.mpg")
V = LWLibavVideoSource("C:\テスト\wind_demo.mpg")
AudioDub(V, A)

[Atak_Snajpera]

Like must be.



Also DGSource output fps 59.94 because is the fps forced by the container (mkv header show this fps).
Many times we force the fps to be other than video stream to sync with audio.

If the true fps is 23.976 the mkv must be remuxed with that fps.
It should prioritize stream fps like ffms2. All duplicated frames should be automatically discarded.

https://i.imgsafe.org/b7/b7a76eb3fa.png

eac3to v3.34
command line: "C:\Portable\eac3to\eac3to.exe" "C:\tmp\Mpeg2-wrongfps.mkv"
------------------------------------------------------------------------------
MKV, 1 video track, 0:01:00, 60p /1.001
1: MPEG2, 480p24 /1.001 (16:9) with pulldown flags
[v01] The video bitstream framerate field doesn't match the container framerate. <WARNING>

[tebasuna51]

It should prioritize stream fps like ffms2.

It is your opinion, not mine.
The mkv is wrong muxed, point.

I extract the .m2v from the container with

eac3to Mpeg2-wrongfps.mkv Mpeg2-wrongfps.m2v -stripPulldown

And now LWLibavVideoSource("Mpeg2-wrongfps.m2v") work fine.

[Atak_Snajpera]

It is your opinion, not mine.
The mkv is wrong muxed, point.

MkvToolnix does that if you import vob files.

[fg118942]

I tried AVSMeter and VirtualDub2 and both program render the avs without any problem. However AvsPmod failed. Hence it's the program's issue.

It seems that it cannot be read when the character encoding of the avs file is Shift JIS.
In the case of UTF-8, it was able to read.

Is it possible to modify it to work correctly even if the character encoding is Shift JIS?
Otherwise, the AviUtl plug-in will have problems.

[Groucho2004]

It seems that it cannot be read when the character encoding of the avs file is Shift JIS.
In the case of UTF-8, it was able to read.

Is it possible to modify it to work correctly even if the character encoding is Shift JIS?
Otherwise, the AviUtl plug-in will have problems.
It should work if you change your system locale to Japanese.

[Atak_Snajpera]

Seeking directly in VOB is broken as well. (That's why I remux to mkv with MKVToolnix)
https://i.imgsafe.org/b8/b8325a6496.png

Sample -> https://www.mediafire.com/file/ofuict89kudp98d/VTS_05_1_0.VOB/file

[tebasuna51]

MkvToolnix does that if you import vob files.

Seems than MkvToolnix read the

1: MPEG2, 480p24 /1.001 (16:9) with pulldown flags

like 30/1.001 interlaced then put 60p /1.001 like fields per second.

Maybe we need a feature/option request for MkvToolnix to ignore pulldown flags (like eac3to -stripPulldown) to obtain a mkv progressive at 24 /1.001

But for me it is not a problem of L-SMASH.

[stax76]

@HolyWu

There is an access violation happening with foreign ANSII characters like ü.

https://en.wikipedia.org/wiki/Windows-1252

https://mega.nz/#F!bkkByaIa!6I5p9jkfXCT-oMQljTF9Rw

[ChaosKing]

@HolyWu

There is an access violation happening with foreign ANSII characters like ü.

https://en.wikipedia.org/wiki/Windows-1252

https://mega.nz/#F!bkkByaIa!6I5p9jkfXCT-oMQljTF9Rw
Tested on german win10
UTF8 -> ok
Ansi -> access violation

But even the Windows Editor saves in UTF8 now...

[stax76]

Try with cachefile parameter, that's what is likely causing it because old builds without cachefile parameter are fine.

edit:

There is clearly an issue with this file but it's arbitrary, sometimes it loads, sometimes the staxrip preview shows access violation and other times StaxRip and VirtualDub2 silently terminate. :(

[stax76]

Thanks for the fix and the new build. :thanks:

[fg118942]

The issue seems to be solved.
Thank you so much.

[-QfG-]

I have trouble with the last both versions. Except Violation Error, if i will indexing my DNxHR HQX Content in a Quicktime Container.

[Atak_Snajpera]

https://github.com/HolyWu/L-SMASH-Works/releases/download/20190914/L-SMASH-Works_20190914.7z


VideoSource: Fix fallback to software decoder in prefer_hw.
LWLibav: Fix access violation in file name manipulation.





I'm not able to fix it. Need investigation by the origianl developer. A workaround is to extract the video track as .m2v file and it will work fine. Or alternatively use MPEG2Source which should be reliable for MPEG2 streams.




Please try and see whether the latest build fix your issue.

Ok. Would IT be difficult to add that auto option regarding hardware decoding? I'm asking because in distributed encoding mode some machines may have NVIDIA GPU and some Intel GPU.

[Atak_Snajpera]

https://github.com/HolyWu/L-SMASH-Works/releases/download/20190917/L-SMASH-Works_20190917.7z


VideoSource: Add prefer_hw=3.


It is almost perfect... ;) However... Lsmash does not check if hardware decoder supports specific codec. I have a Kepler GPU which does not support HEVC decoding and in this case prefer_hw=1/3 returns an error message.

[redbtn]

First of all, thank you HolyWu for updates!
Can I ask what matter to use hardware decoder? I have Nvidia RTX 2060, but I did test and didn't notice difference in encoding speed.
What decoder is preferred in my case? Thank you!

[poisondeathray]

First of all, thank you HolyWu for updates!
Can I ask what matter to use hardware decoder? I have Nvidia RTX 2060, but I did test and didn't notice difference in encoding speed.
What decoder is preferred in my case? Thank you!

It depends on your scenario

e.g if the bottleneck is your encoder/ encoding settings, or some filters, maybe offloading the decoding to GPU might not make much of a difference

eg. If decoding only uses 0.5% of your CPU (maybe SD footage), it might not make much of a difference either

Other scenarios might be different. e.g. Decoding UHD/4K footage might take significant CPU resources. Offloading that decoding task to GPU should free up CPU cycles to encode faster (if using a "CPU encoder" )

[redbtn]

It depends on your scenario

e.g if the bottleneck is your encoder/ encoding settings, or some filters, maybe offloading the decoding to GPU might not make much of a difference

eg. If decoding only uses 0.5% of your CPU (maybe SD footage), it might not make much of a difference either

Other scenarios might be different. e.g. Decoding UHD/4K footage might take significant CPU resources. Offloading that decoding task to GPU should free up CPU cycles to encode faster (if using a "CPU encoder" )Thank you for explaining. I encode 4k HDR > 1080p HDR using x265 and VapourSynth. So, I will try again, maybe I will see the difference. Is it right, that both software and hardware decoders work the same and no difference in quality or stability? Can I safely choose hardware decoder for all my encodes and don't worry about something goes wrong?

[poisondeathray]

Thank you for explaining. I encode 4k HDR > 1080p HDR using x265 and VapourSynth. So, I will try again, maybe I will see the difference. Is it right, that both software and hardware decoders work the same and no difference in quality or stability? Can I safely choose hardware decoder for all my encodes and don't worry about something goes wrong?

Money back guarantee :)

There were differences in earlier versions with CUVID, but this version looks to have fixed it

I don't think there has been enough testing to ensure everything works 100%

If something goes wrong, report it . That's the only way stuff gets fixed

[stax76]

Can I ask what matter to use hardware decoder? I have Nvidia RTX 2060, but I did test and didn't notice difference in encoding speed.
What decoder is preferred in my case? Thank you!

How many CPU cores? I don't think you gain something substantial if you have more than 4 cores, that's what my encoding test showed, sw 60 fps, hw 61 fps.

StaxRip hasn't the most efficient drawing implementation, dealing with 4K in the crop and preview dialog users get a noticeable improvement with a HW decoder.

[redbtn]

How many CPU cores? I don't think you gain something substantial if you have more than 4 cores, that's what my encoding test showed.

StaxRip hasn't the most efficient drawing implementation, dealing with 4K in the crop and preview dialog users get a noticeable improvement with a HW decoder.I have I5-9400f 6 core processor. On preset Slower x265 with some minor changes i get 2.4-2.6 fps.
So, if I can't see any difference after tests, the best way choose software decoder, right?

[Atak_Snajpera]

I have I5-9400f 6 core processor. On preset Slower x265 with some minor changes i get 2.4-2.6 fps.
So, if I can't see any difference after tests, the best way choose software decoder, right?

No wonder you see no differences with hardware decoding if encoder is only requesting on average 1 frame every 400ms.

[MeteorRain]

Hardware decoder can easily reach 200fps on 1080p source.

[Atak_Snajpera]

Hardware decoder can easily reach 200fps on 1080p source.

Decoding speed with blu-ray avc source is around 130fps on Kepler.
For comparison:
Q8200@2.8GHz reaches 100fps (~85% cpu usage)
Xeon E5-2690@3.2GHz reaches 440fps (~75% cpu usage)

[MeteorRain]

Thanks for correcting. Although those fps are "free" fps that does not fight with encoding speed at all. When transcoding HEVC 4k, having hardware decoder can free up large portion of CPU resources and leave them for encoding. I'd still use hardware decoder whenever possible to me.

[Atak_Snajpera]

Thanks for correcting. Although those fps are "free" fps that does not fight with encoding speed at all. When transcoding HEVC 4k, having hardware decoder can free up large portion of CPU resources and leave them for encoding. I'd still use hardware decoder whenever possible to me.

In theory yes but in practice no. Encoder will still be responsible for about 98% of CPU time. You will only see difference If you encode hevc 4k 100Mbps to low resolution with x264 and preset superfast.

[DJATOM]

If you're using heavy filters (like eedi3 or mdegrain), you'll definitely see an improvement in speed with HW decoder.

[Atak_Snajpera]

If you're using heavy filters (like eedi3 or mdegrain), you'll definitely see an improvement in speed with HW decoder.

Nope because those filters work on CPU creating additional bottleneck.

[DJATOM]

Nope because those filters work on CPU creating additional bottleneck.

Yeah, and offloading decoder to GPU saves CPU cycles for encoder and filters.

[sneaker_ger]

Atak_Snajpera is right. The more of my CPU time "cake" is spent on filtering and encoding the less impact HW decoding will make on speed. It doesn't mean HW decoding won't make encoding faster it's just that the percentage goes down. (Exception is if my CPU isn't utilized 100%.)

Imagine you use AV1 encoder with placebo settings and very slow filtering (QTGMC+waifu2x) and software decoding of source. Then 99% of CPU time is spent on encoding+filtering, 1% on SW decoding. If you replace SW decoding with HW decoding you only free up that 1%. If you use no filtering and very fast encoder settings (x264 preset ultrafast) maybe you have 70% encoding and 30% SW decoding. Then replacing SW by HW decoding can increase speed much more.

[Atak_Snajpera]

Yeah, and offloading decoder to GPU saves CPU cycles for encoder and filters.

You do not realize how encoding chain works. Encoder determines how fast IT needs frames from decoder. Any filtering in avisynth will only slow down frame requests.

[ChaosKing]

# Latest lsmash Nvidia gpu
Output 3001 frames in 34.80 seconds (86.24 fps) # SMDegrain(clip, tr=1)
Output 3001 frames in 88.24 seconds (34.01 fps) # SMDegrain(clip, tr=3)
# CPU
Output 3001 frames in 40.83 seconds (73.51 fps) # SMDegrain(clip, tr=1)
Output 3001 frames in 95.05 seconds (31.57 fps) # SMDegrain(clip, tr=3)
Tested on ryzen 2600, GTX 1070 in vapoursynth
source is 1080p AVC

[DJATOM]

You do not realize how encoding chain works. Encoder determines how fast IT needs frames from decoder. Any filtering in avisynth will only slow down frame requests.

I'm talking about CPU usage, not how frame requests works. Obviously software decoder will leave less room for other stuff and that was my point. You still can repeat your mantra about frame requests, but you can't say "software decoder is free for CPU", right?

[Atak_Snajpera]

I'm talking about CPU usage, not how frame requests works. Obviously software decoder will leave less room for other stuff and that was my point. You still can repeat your mantra about frame requests, but you can't say "software decoder is free for CPU", right?

Check this out!

CPU: Intel Q8200@2.8GHz
GPU: NVidia GT 710 (Kepler)
SSD: Yes

Source Blu-ray John Carter (first 10 minutes)
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=3, N=18
Muxing mode : Container profile=@0.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 10 min 0 s
Bit rate mode : Variable
Bit rate : 26.9 Mb/s
Maximum bit rate : 40.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.541
Stream size : 1.88 GiB (98%)
Default : No
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


ScriptSW.avs
LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("C:\Temp\Video.mkv",cachefile="C:\Temp\Video.mkv.lwi",prefer_hw=0)
return video

ScriptHW.avs
LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("C:\Temp\Video.mkv",cachefile="C:\Temp\Video.mkv.lwi",prefer_hw=1)
return video

Decoding speed test in AVSMeter
Software Decoding
Log file created with: AVSMeter 2.9.6 (x64)
Script file: C:\Temp\scriptSW.avs

[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1.0 (Build 7601)

CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.80GHz / Yorkfield (Core 2 Quad) 2M
MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1
4 physical cores / 4 logical cores

Video card: NVIDIA GeForce GT 710
GPU version: GK208
Video memory size: 1024 MiB
OpenCL version: OpenCL 1.2 CUDA
Graphics driver version: 26.21.14.3615 (NVIDIA 436.15) / Win7 64


[Avisynth info]
VersionString: AviSynth+ 0.1 (r2772, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2018-12-20, 12:55:18 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+


[Clip info]
Number of frames: 14405
Length (hh:mm:ss.ms): 00:10:00.809
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: i420
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 14405 (0 - 14404)
FPS (min | max | average): 76.92 | 256.0 | 124.1
Process memory usage (max): 85 MiB
Thread count: 10
CPU usage (average): 92.8%

GPU usage (average): 1%
VPU usage (average): 0%
GPU memory usage: 130 MiB

Time (elapsed): 00:01:56.122


[Script]
LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("C:\Temp\Video.mkv",cachefile="C:\Temp\Video.mkv.lwi",prefer_hw=0)
return video


Hardware Decoding
Log file created with: AVSMeter 2.9.6 (x64)
Script file: C:\Temp\scriptHW.avs

[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1.0 (Build 7601)

CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.80GHz / Yorkfield (Core 2 Quad) 2M
MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1
4 physical cores / 4 logical cores

Video card: NVIDIA GeForce GT 710
GPU version: GK208
Video memory size: 1024 MiB
OpenCL version: OpenCL 1.2 CUDA
Graphics driver version: 26.21.14.3615 (NVIDIA 436.15) / Win7 64


[Avisynth info]
VersionString: AviSynth+ 0.1 (r2772, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2018-12-20, 12:55:18 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+


[Clip info]
Number of frames: 14405
Length (hh:mm:ss.ms): 00:10:00.809
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: i420
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 14405 (0 - 14404)
FPS (min | max | average): 38.94 | 148.9 | 122.6
Process memory usage (max): 91 MiB
Thread count: 8
CPU usage (average): 13.2%

GPU usage (average): 22%
VPU usage (average): 99%
GPU memory usage: 230 MiB

Time (elapsed): 00:01:57.449


[Script]
LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("C:\Temp\Video.mkv",cachefile="C:\Temp\Video.mkv.lwi",prefer_hw=1)
return video

Results when encoding in x264 (logs -> https://www.mediafire.com/file/9cs3pj8d2funidx/Logs.7z/file )
https://i.imgsafe.org/28/286ce8b657.png

The slower encoder the less you get from hardware decoding! It would be even worse if I added any filtering in AviSynth like MDegrain. Not to mention about a lot slower x265. Deal with it! Most of the time you get placebo effect

[MeteorRain]

Time saved is time saved. Whatever slower preset you choose, the amount of CPU resource HW decoder saves you is basically the same.

The CPU resources saved always equals to the total cost of SW decoder demands, minus the effort to copy pictures from graphics card buffer, right?

Saving 5 minutes off 10 minutes ultrafast encoding is great, but saving 5 minutes off 50 minutes medium encoding is not bad either.
It's like upgrading your CPU from 3600 to 3600X for free. It's a free 5 minutes, I'll take it.

[DJATOM]

Fortunately I'm using Vapoursynth nowadays. Looks like it's both fine with HW and SW decoding (no penalty over HW decoding with heavy filtering).

[Atak_Snajpera]

Time saved is time saved. Whatever slower preset you choose, the amount of CPU resource HW decoder saves you is basically the same.

The CPU resources saved always equals to the total cost of SW decoder demands, minus the effort to copy pictures from graphics card buffer, right?

Saving 5 minutes off 10 minutes ultrafast encoding is great, but saving 5 minutes off 50 minutes medium encoding is not bad either.
It's like upgrading your CPU from 3600 to 3600X for free. It's a free 5 minutes, I'll take it.

Keep in mind that this was the BEST case scenario. Add some MDegrain or/and some HDR->SDR tonemapping plus x265 and you will be lucky if you even see 1 minute saved! It's simple! The more you throw tasks on CPU the less speed gap between software and hardware decoding you get.

[MeteorRain]

What's wrong with 1 minute saved?

[videoh]

Keep in mind that this was the BEST case scenario. Add some MDegrain or/and some HDR->SDR tonemapping plus x265 and you will be lucky if you even see 1 minute saved! It's simple! The more you throw tasks on CPU the less speed gap between software and hardware decoding you get. The absolute time saved depends only on the stream length, not the amount of SW stuff you do. Yes, the percent savings gets reduced by more SW work, but not the absolute amount as you suggest: "you will be lucky if you even see 1 minute saved".

[videoh]

What's wrong with 1 minute saved? Atak would refuse a free ten-dollar bill because it is too small. ;)

[Atak_Snajpera]

Atak would refuse a free ten-dollar bill because it is too small. ;)

Neuron2 triggered when somebody attacks hardware decoding... I wonder why... ;)

[videoh]

BTW, many filters have been GPU accelerated and there is nothing to stop others from being ported to GPU. It's not just about the decoder.

[Atak_Snajpera]

Bonus x265
https://i.imgsafe.org/28/286ce86c97.png

[videoh]

Ah, data. Sweet.

If you make available that 10-minute source clip I'd like to try this with a high-end nVidia GPU (2080 Ti) and DGSource() under both Avisynth+ and Vapoursynth (native). Can you please do that for us? Thank you. If you need access to my FTP just send me a PM.

DJATOM says he can't duplicate your effect so it would be nice to get some other data points.

[MeteorRain]

Actually I would like to see some performance testing on downscaling 4K UHD BD to 1080P and encoded by x265 medium. I assume this is a very legit scenario.

[videoh]

Sure, let's do both. But we should all use the same stream.

[redbtn]

Actually I would like to see some performance testing on downscaling 4K UHD BD to 1080P and encoded by x265 medium. I assume this is a very legit scenario.Which downscaler should I use? I can make tests. I prefer spline64 for 4k to 1080p, but maybe there are something better?

[Sparktank]

Sure, let's do both. But we should all use the same stream.

Ooh, this sounds fun.
new thread? get everyone involved.

GTX 1060 3GB checking in.

[Sparktank]

Bonus x265
https://i.imgsafe.org/28/286ce86c97.png

Also, how do you make these graphs?

[MeteorRain]

Which downscaler should I use? I can make tests. I prefer spline64 for 4k to 1080p, but maybe there are something better?

Has anyone tried GPU resizer from DGSource?

[DJATOM]

I've tried it for downscaling of some movie and it was fine. Didn't tested on anime.

[Atak_Snajpera]

Ah, data. Sweet.

If you make available that 10-minute source clip I'd like to try this with a high-end nVidia GPU (2080 Ti) and DGSource() under both Avisynth+ and Vapoursynth (native). Can you please do that for us? Thank you. If you need access to my FTP just send me a PM.

DJATOM says he can't duplicate your effect so it would be nice to get some other data points.

Uploading in progress... Will take probably few hours.

New test with added very useful MDegrain2 (can reduce file size in Constant Quality by factor of 1.7x). I did only 4 tests because it takes way to much time!

ScriptSW.avs
LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("C:\Temp\Video.mkv",cachefile="C:\Temp\Video.mkv.lwi",prefer_hw=0)
Loadplugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
fv2=MAnalyse(super,isb=false,delta=2,overlap=4)
bv2=MAnalyse(super,isb=true,delta=2,overlap=4)
video=MDegrain2(video,super,bv1,fv1,bv2,fv2,thSAD=400)
video=Prefetch(video,4)
return video


ScriptHW.avs
LoadPlugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("C:\Temp\Video.mkv",cachefile="C:\Temp\Video.mkv.lwi",prefer_hw=1)
Loadplugin("C:\Program Files (x86)\RipBot264\Tools\AviSynth plugins\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
fv2=MAnalyse(super,isb=false,delta=2,overlap=4)
bv2=MAnalyse(super,isb=true,delta=2,overlap=4)
video=MDegrain2(video,super,bv1,fv1,bv2,fv2,thSAD=400)
video=Prefetch(video,4)
return video

https://i.imgsafe.org/37/37bfdbdafa.png

[videoh]

Atak,

Any chance you can share your stream as I requested?

[Atak_Snajpera]

Also, how do you make these graphs?

LibreOffice calc

[Atak_Snajpera]

Atak,

Any chance you can share your stream as I requested?

It is being uploaded right now to mediafire...will take few hours.

[poisondeathray]

What was the "proper" way to MT GPU filters ?

I remember some issue in the KNLMeans discussion, or videoh mentioning something , but I can't find the posts

If you test just the source filter alone with cuvid, it seems abnormally slow , regardless of the filter MT Mode or prefetch >1 value . Thrashing or something . But seems ok in vapoursynth with native threading

[Groucho2004]

What was the "proper" way to MT GPU filters ?There is none. There is no speed benefit and it just eats more graphics memory. Modern cards have their own "multi-threading".

[Atak_Snajpera]

What was the "proper" way to MT GPU filters ?

I remember some issue in the KNLMeans discussion, or videoh mentioning something , but I can't find the posts

If you test just the source filter alone with cuvid, it seems abnormally slow , regardless of the filter MT Mode or prefetch >1 value . Thrashing or something . But seems ok in vapoursynth with native threading

I recommend putting GPU filters after Prefetch.

[Atak_Snajpera]

Atak,

Any chance you can share your stream as I requested?

http://www.mediafire.com/file/dh86soca2m66n6b/video.mkv/file

[videoh]

Got it. Thank you, Atak.

[hydra3333]

GTX 1060 3GB checking in.
Well, I have a 3900X/cheapie-2060-Super/vapoursynth-portable/DG-tools/Win10x64, if someone wants to provide a script and a couple of lines outlining how to measure the time. The 3900X is a tad crippled though, with only 2666 RAM awaiting some 3600 to arrive (hence the 3900X infinity fabric is running at 3/4 of "normal").

[DJATOM]

I also have 3900X with Asus ROG Crosshair Hero 7 mobo and 2x 16 GB RAM (OC to 3333 MHz) + RTX2070 (Gigabyte Gaming OC, 3 fans). Unfortunately I don't have much time to tinker with scripts this week, but can run some batches before I'll go to sleep.

[Selur]

Using 20190917 I have some problem with a mkv(interlaced avc,wav) using:
core.lsmas.LWLibavSource(source="Il Silenzio (Melissa Venema) [Live in Maastricht II] (N).mkv", format="YUV420P8", cache=0, prefer_hw=1)
only one frame is returned
using:
core.lsmas.LWLibavSource(source="Il Silenzio (Melissa Venema) [Live in Maastricht II] (N).mkv", format="YUV420P8", cache=0, prefer_hw=0)
vspipe and vsviewer simply close. :)
DGSource and FFVideoSource (ffms2 and ffms2k) both work.
Same happens with AvsPmod and avs2yuv when using:
LWLibavVideoSource("C:\Users\Selur\Desktop\Il Silenzio (Melissa Venema) [Live in Maastricht II] (N).mkv",cache=false,format="YUV420P8", prefer_hw=1)
(only one Frame)
and
LWLibavVideoSource("C:\Users\Selur\Desktop\Il Silenzio (Melissa Venema) [Live in Maastricht II] (N).mkv",cache=false,format="YUV420P8", prefer_hw=0)
program closes.
(as expected using prefer_hw=3 also returns one frame)

Uploaded the source to my GoogleDrive (https://drive.google.com/open?id=1D77BWzCD0UWs2S6188rLFbut5_4O7pgo).
(Using Ryzen 7 1800X, Windows 10, 32GB RAM, GeForce GTX 1070Ti in case it helps.)

Cu Selur

[Atak_Snajpera]

Using 20190917 I have some problem with a mkv(interlaced avc,wav) using:
core.lsmas.LWLibavSource(source="Il Silenzio (Melissa Venema) [Live in Maastricht II] (N).mkv", format="YUV420P8", cache=0, prefer_hw=1)
only one frame is returned
using:
core.lsmas.LWLibavSource(source="Il Silenzio (Melissa Venema) [Live in Maastricht II] (N).mkv", format="YUV420P8", cache=0, prefer_hw=0)
vspipe and vsviewer simply close. :)
DGSource and FFVideoSource (ffms2 and ffms2k) both work.
Same happens with AvsPmod and avs2yuv when using:
LWLibavVideoSource("C:\Users\Selur\Desktop\Il Silenzio (Melissa Venema) [Live in Maastricht II] (N).mkv",cache=false,format="YUV420P8", prefer_hw=1)
(only one Frame)
and
LWLibavVideoSource("C:\Users\Selur\Desktop\Il Silenzio (Melissa Venema) [Live in Maastricht II] (N).mkv",cache=false,format="YUV420P8", prefer_hw=0)
program closes.
(as expected using prefer_hw=3 also returns one frame)

Uploaded the source to my GoogleDrive (https://drive.google.com/open?id=1D77BWzCD0UWs2S6188rLFbut5_4O7pgo).
(Using Ryzen 7 1800X, Windows 10, 32GB RAM, GeForce GTX 1070Ti in case it helps.)

Cu Selur

Indeed. Instant crash in my SeekTester tool
https://i.imgsafe.org/a2/a21dadf4db.png

Update: It looks like video has to be demuxed to raw .264 in order to be correctly decoded by LSMASH.

Update2: Demuxed .264 does not crash LSMASH but some frames are missing after seeking.
https://i.imgsafe.org/a2/a25398f5fb.png

[videoh]

Check this out! Can you please give me the x264 version you used and a link to get it? Thank you.

BTW, DGSource() on a 2080 Ti gives 500 fps for your stream compared to your 124 fps for SW, and 122 fps for your ancient GT 710.

[Atak_Snajpera]

Just download latest. Ask uncle google for directions.

[videoh]

First test with your stream to x64:

DGSource + 2080 Ti: 4:30

That is to be compared to your 13:21 for SW.

Looks like a fine boost to me.

[poisondeathray]

First test with your stream to x64:

DGSource + 2080 Ti: 4:30

That is to be compared to your 13:21 for SW.

Looks like a fine boost to me.


What about compared to your SW?

Comparing 2 different CPU's setups is less relevant if his is an old Q8200 and you have something probably 10 years newer and with more cores

[videoh]

Oy, OK, I never wanted lsmash or any of that on my PC but I'll see what I can do for you. BTW, I have only a lowly 7700K @4.2GHz. Your request is fair and reasonable.

[MeteorRain]

Actually this is the first time I noticed that's a q8200, which was launched 11 years ago.

This brings me the question. What kind of hardware spec range should we expect in daily benchmarks.
Shall we even care about how the performance is to encode x265 1080p on an 11 years old CPU?
Shall we focus on some more "modern" hardware?

IMHO, even E5v1 and SNB desktop series are considered a bit outdated now.

[poisondeathray]

Actually this is the first time I noticed that's a q8200, which was launched 11 years ago.

This brings me the question. What kind of hardware spec range should we expect in daily benchmarks.
Shall we even care about how the performance is to encode x265 1080p on an 11 years old CPU?
Shall we focus on some more "modern" hardware?

IMHO, even E5v1 and SNB desktop series are considered a bit outdated now.



It really doesn't matter, as long as the relevant testing and background info is provided for context. Some people have older than 10 year old hardware, some older 3rd or 4th computers laying around. It might be useful info for them. But given limited time constraints - I would put higher priority testing on newer hardware if possible

But the question here was measuring the effect of off loading "GPU" decoding on actual encoding speed. So the delta on the same hardware needs to be tested, not comparing different CPU hardware. Obviously the Q8200 will be slower for encoding in every situation

[poisondeathray]

Oy, OK, I never wanted lsmash or any of that on my PC but I'll see what I can do for you. BTW, I have only a lowly 7700K @4.2GHz.

haha, not even to check out the emerging "competition" ? :D

What if you have some non supported video format by Nvidia/CUVID ?

Thanks

[Atak_Snajpera]

First test with your stream to x64:

DGSource + 2080 Ti: 4:30

That is to be compared to your 13:21 for SW.

Looks like a fine boost to me.

Facepalm.jpg . You can't even do proper testing like i did.

[DJATOM]

Actually this is the first time I noticed that's a q8200, which was launched 11 years ago.

This brings me the question. What kind of hardware spec range should we expect in daily benchmarks.
Shall we even care about how the performance is to encode x265 1080p on an 11 years old CPU?
Shall we focus on some more "modern" hardware?

IMHO, even E5v1 and SNB desktop series are considered a bit outdated now.

I have Sandy Bridge based notebook and it feels much slower in browsing or doing stuff in programs (in comparison to R9 3900X). Not to mention it's slow af for heavy encoding or filtering.

[Atak_Snajpera]

I have Sandy Bridge based notebook and it feels much slower in browsing or doing stuff in programs (in comparison to R9 3900X). Not to mention it's slow af for heavy encoding or filtering.

I have Sandy bridge xeon e5-2690 and IT is as good as ryzen 1700. Comparing low clocked CPU in notebook with desktop 105w CPU is just silly.

[DJATOM]

Indeed it's just i7-2670QM with 2.2-3.1 (boost) GHz, but user experience differs even if I will set saving plan on Ryzen. 2.2 GHz at 3900X feels much faster in browser (that's my most common usage for notebook). Since both devices using SSD, I think it differs due to RAM frequency.

[Atak_Snajpera]

Indeed it's just i7-2670QM with 2.2-3.1 (boost) GHz, but user experience differs even if I will set saving plan on Ryzen. 2.2 GHz at 3900X feels much faster in browser (that's my most common usage for notebook). Since both devices using SSD, I think it differs due to RAM frequency.

Im also sure that you disabled those extra cores/threats...

[videoh]

Second test:

DGSource() 2080 Ti + x264 7700K: 4:28
LWLibavVideoSource() + x264 7700K: 4:57
Preset medium

That's about an 11% improvement on GPU versus doing everything on my fairly strong CPU.

I have always pointed out that the gain you can get will depend on how strong your processor is. And I have also pointed out that DG tools bring other things to the table, such as robust random access, GPU resizing, some CUDA filters, DGIndexNV as a useful analysis tool in its own right, etc. With over 15000 paid users, I'm not worried about justifying the existence of DG tools.

I'll do another test with UHD. It will be interesting to see how things scale with frame size.

[Atak_Snajpera]

I have always pointed out that the gain you can get will depend on how strong your processor is.
Not really. On my weak PC delta is ~9% in default medium x264 preset.
https://i.imgsafe.org/28/286ce8b657.png

On your much more powerful CPU (7700k@4.2Ghz) and GPU (RTX 2080TI) delta is ~11%. Your ultra expensive ~$1200 GPU with 4xfaster hardware decoding than ancient GT 710 kepler for $40 gives you only +2 percent points extra in video encoding. That's just pathetic.

[Atak_Snajpera]

710 is garbage so your results are pointless. So sorry you're too poor to buy decent hardware.

Oh finally you said it! That's what I wanted to hear from you! Old good Neuron2 (aka banned doom9 moderator) is back!

PS. HA! got ya! I was faster this time and I managed to quote your deleted comment! Not this time amigo!

[videoh]

I don't care what you quote, and your childish behavior doesn't move me at all. Grow up.

To be fair, I would encode on my snazzy 2080 Ti also. And the 2080 Ti is bringing me other things that are quite useful for me, such as tensor cores, massive number of CUDA cores for my physics simulations, etc. No matter how you blow smoke, I get an 11% improvement for your use case. It would be brain-dead for me not to choose DGSource() over LWLibavVideoSource().

You sound bitter because you can't afford decent hardware, although your post above suggests simple DG derangement syndrome.

[DJATOM]

Actually GT 710 is almost deprecated card. You will lose driver updates soon (from April 2020). Not to mention it's only ok for decoding 8 bit AVC, while RTX cards (or GTX 1660/1660Ti cards) has bleeding edge decoder, which significantly faster and supports more formats (HEVC 8/10/12 bit, VP9 8 and 10 bit).

[Atak_Snajpera]

Actually GT 710 is almost deprecated card. You will lose driver updates soon (from April 2020). Not to mention it's only ok for decoding 8 bit AVC, while RTX cards (or GTX 1660/1660Ti cards) has bleeding edge decoder, which significantly faster and supports more formats (HEVC 8/10/12 bit, VP9 8 and 10 bit).

You do realize that ancient GT 710 is just for showing desktop right? It was not bought for games or 4k HEVC movies. Instead of changing topic we should focus on facts. 4xfaster video engine gives you in real life encoding scenarios only +2 extra percent points versus something what costs $40.

Ps. And yes If you want you can also call me poor like videoh aka Neuron2 did in his post. I'm too old for this childish talking.

[videoh]

That's "neuron2", pal. Get it right!

[poisondeathray]

Thanks for the testing results,

@videoh -
How about LWLibavVideoSource(decoder="h264_cuvid") on the same hardware? I'd expect similar speeds as DGSource

[DJATOM]

You do realize that ancient GT 710 is just for showing desktop right? It was not bought for games or 4k HEVC movies. Instead of changing topic we should focus on facts. 4xfaster video engine gives you in real life encoding scenarios only +2 extra percent points versus something what costs $40.

While your ancient card only good for showing desktop, RTX card (for example, mine RTX 2070) can do OpenCL/CUDA computations, offloading a lot of work (for example, NNEDI3CL or EEDI3CL) from CPU. I've tried GTX750, 760, 1050, 2060 and 2070 cards with those filters: with decent CPU GTX 750, 760 and 1050 was a bottleneck for my filtering chain (thus slowing down encoder).
If you don't have to use heavy filtering, there is not much benefit from better card or GPU decoding at all (with slower presets), but when you have to do a lot of encodes, it definitely wins some time for you. Even your tests shows a benefit from using GPU decoder.

[MeteorRain]

On your much more powerful CPU (7700k@4.2Ghz) and GPU (RTX 2080TI) delta is ~11%. Your ultra expensive ~$1200 GPU with 4xfaster hardware decoding than ancient GT 710 kepler for $40 gives you only +2 percent points extra in video encoding. That's just pathetic.

People buy a house not because they want to have a slightly bigger closet in their room than your condo. People buy a RTX 2080Ti not because they want to show how 1% of its processing power improves 2% of the portion.

Your $1200 GPU argument makes no sense because its just a card he has. I have a $60 worth of GTX 950 and I can get exactly the same decoding speed that he got, and thus the same result. Saying people are pathetic buying a 1 million dollar house by comparing how big the closet is, is IMHO so funny that I literally laughed out load when I saw your words.

If you really want to see how big the difference that graphics card can do, decode and scale down some UHD to 1080P or 720P and check how big of the portion those card can take over. Even worse, I've got a 8K 60fps HEVC 10bit TV broadcasting stream that my freshly bought Ryzen 3600 can barely playback at 5 fps full CPU load. You want to see how $1200 GPU works compared to your $40 card? Try those. It can decode, downscale, process the image and then output to AviSynth at > 60 fps, comparing to, let's say, 3 fps on a 6 core CPU sold this year.

[videoh]

How about LWLibavVideoSource(decoder="h264_cuvid") on the same hardware? I'd expect similar speeds as DGSource Yes, indeed:

4:30

So maybe need to retract my point about being brain-dead not to choose DGSource() here, but the main point still applies, I'd be brain-dead not to choose GPU decoding.

To answer your earlier question...I haven't run into any files that DGSource() cannot open and that I needed to do anything with. Surely, if such files became important for me or my users I would first want to add support in DGDecNV but failing that, of course would revert to an appropriate SW decoder.

[DJATOM]

Thanks for the testing results,

@videoh -
How about LWLibavVideoSource(decoder="h264_cuvid") on the same hardware? I'd expect similar speeds as DGSource

I've measured some fps for certain sources (with vsedit's benchmark).

8bit AVC (.m2ts from BD)
Time elapsed: 1:05.696 - 547.85574001840120672568 FPS # DGSource
Time elapsed: 1:04.261 - 560.09428731059801975789 FPS # LWLibAvSource

10bit HEVC (.hevc ES)
Time elapsed: 1:17.304 - 465.58912373251257577067 FPS # DGNV
Time elapsed: 1:24.014 - 428.40612414457933709855 FPS # LWLibAvSource

[Atak_Snajpera]

Saying people are pathetic buying a 1 million dollar house by comparing how big the closet is, is IMHO so funny that I literally laughed out load when I saw your words.
Where did I write that?! Show me! You are now just spreading fake news. Not cool bro!

[MeteorRain]

Where did I write that?! Show me! You are now just spreading fake news. Not cool bro!

You are so funny.

[videoh]

I've got a 8K 60fps HEVC 10bit TV broadcasting stream that my freshly bought Ryzen 3600 can barely playback at 5 fps full CPU load. You want to see how $1200 GPU works compared to your $40 card? Try those. It can decode, downscale, process the image and then output to AviSynth at > 60 fps, comparing to, let's say, 3 fps on a 6 core CPU sold this year. Amen, bro!

[Atak_Snajpera]

You are so funny.

Unfortunately I can't say the same about your lies. They are not funny at all.

[videoh]

Cool down Atak. You did use the epithet "pathetic". MeteorRain was merely analogizing: obsessing over a video decoder when the card brings so much more to the table is like obsessing over a closet in a house. I suppose you did understand that but calling someone a liar is so much cooler, right? From the guy that is too old to be childish!

To be honest, I'm having trouble understanding what your basic point is here. Is it that using GPU power is useless? Is it that 2080 Ti etc. are poor value? DG tools suck? DG sucks? What is your overall point?

[DJATOM]

People buy a house not because they want to have a slightly bigger closet in their room than your condo. People buy a RTX 2080Ti not because they want to show how 1% of its processing power improves 2% of the portion.

Your $1200 GPU argument makes no sense because its just a card he has. I have a $60 worth of GTX 950 and I can get exactly the same decoding speed that he got, and thus the same result. Saying people are pathetic buying a 1 million dollar house by comparing how big the closet is, is IMHO so funny that I literally laughed out load when I saw your words.

If you really want to see how big the difference that graphics card can do, decode and scale down some UHD to 1080P or 720P and check how big of the portion those card can take over. Even worse, I've got a 8K 60fps HEVC 10bit TV broadcasting stream that my freshly bought Ryzen 3600 can barely playback at 5 fps full CPU load. You want to see how $1200 GPU works compared to your $40 card? Try those. It can decode, downscale, process the image and then output to AviSynth at > 60 fps, comparing to, let's say, 3 fps on a 6 core CPU sold this year.

Yeah, good real word scenario. I've tried to decode such stream on my card and it's playing smoothly without any stutters while stuttering a lot with SW decoder and 3900X (40-60% utilization, so a believe it hits PCIe Gen3 x16 max throughput capacity).

MI from that video: https://pastebin.com/xB8CHFiS.

[videoh]

so a believe it hits PCIe Gen3 x16 max throughput capacity That's a great point. If GPU processing has an achilles heel, that is it. We can look forward to greater bandwidth with future generations. Also, to mitigate this I have been experimenting with my CUDASynth framework, which allows many full frame transfers over PCIe to be eliminated for a script with multiple filters. You can read about it at the DG forum.

[MeteorRain]

SW decoder and 3900X (40-60% utilization, so a believe it hits PCIe Gen3 x16 max throughput capacity).

That means the video renderer can't keep up because of the limited PCIe bandwidth? Very interesting.

Maybe try reducing the frame rate down to 30 on MKV, and pin the video player process to half of the cores, and see how that works? That should tell us whether it's due to the bandwidth or due to, like, CPU scheduler.