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/3i81ttxf02...VhYLasmwa?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.ph...34#post1567834

[radigast]

Are there any advantages to using LWLibavVideoSource over FFVideoSource?

[Selur]

No, clue.
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]

Originally Posted by Selur

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]

Originally Posted by the_weirdo

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]

Originally Posted by the_weirdo

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]

Originally Posted by TheFluff

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

Ah, that explains a lot.

Originally Posted by VFR maniac

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]

Originally Posted by 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?

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]

Originally Posted by 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.

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!!

Originally Posted by 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'.

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]

Originally Posted by 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.

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]

Originally Posted by sl1pkn07

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.