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.