I've got some sat feeds that are 1080i High 4:2:2 @L4.1. DGIndexNV doesn't support 4:2:2 Chroma. Is there any other frame accurate indexer that does? Is DSS2 frame accurate? As far as I know that's based on DirectShow which isn't frame accurate.
+ Reply to Thread
Results 1 to 8 of 8
l-smash and ffms2
l-smash is more reliable for transport streams which I assume your sat feed are. Use threads=1 for highest reliability
I noticed this FFMS2 page: http://avisynth.nl/index.php/FFmpegSource#Compatibility
It says FFMS2 is frame accurate when encoding from a MKV source. Is that true?
Is there anything I need to add to the FFM2 line like your threads=1 line?
Regarding LSmash, I noticed this page: http://avisynth.nl/index.php/LSMASHSource/LSMASHVideoSource
It doesn't mention anything about threads=1 being more reliable. I was wondering where you heard that?
Also I'm encoding with MeGUI. You need to leave this line in your script for the video to encode correctly:
How would I add threads=1 to that line?
threads=1 is always more reliable for both of them, as is seekmode=0 for ffms2. I think megui automatically adds threads=1 if you use that. Both options slow decoding down decoding considerably when you use for ffms2. You usually don't need seekmode=0, unless you need non linear access (e.g. editing on a timeline, some types of temporal filtering)
Thanks. Is there documentation which explains what the different settings do such as threads as I can't find instructions that mention threads=1 being more reliable? Also what do you mean by it being more reliable? Do you mean it prevents crashing, dropped frames, etc?
threads=1 just means the source filter is using 1 thread for decoding the source - not multiple threads - so it's going to be much slower.
More reliable in this context means the frames are correct and in the correct order, not misordered or black or green
Occasionally you can have misordered frames or green frames or black - especially with certain containers like AVI + long GOP formats - but it can affect other contains as well when you seek . The probability is even higher when you use MT + threads > 1
If it's not documented - it should be. This is a known "feature" for people that use it often. It's discussed at doom9 within numerous posts. It's probably the reason why megui adds threads=1 automatically when ffms2 is used to index
Same with the lsmash preference over ffms2 especially for transport streams - it's well known, and you can reproduce issues with ffms2. The most common issue there is it reads the frame rate as the field rate and you can have frame repeats (doubled frames), and/or it reads the framerate slightly "off" - probably why megui adds the fpsnum, fpsden to correct for it
Last edited by poisondeathray; 23rd Sep 2015 at 17:26.
I tried LSmash today in MeGUI. MeGUI edits the script as follows:
LoadPlugin("X:\Portable Installations\MeGUI 2525\tools\lsmash\LSMASHSource.dll")
Instead if I use an MKV as the source then it processes the file instantly before quickly indexing it. Regardless of .ts or .mkv input the script remains the same. The output seems to be frame accurate and the video encodes just as fast as when using DGIndexNV to index the video.
I noticed that in the LSmash documention it says LSmash doesn't need to create an index yet it is for both .ts and .mkv. Why?
Is LWLibavVideoSource frame accurate how MeGUI is using it and will the resulting video be glitch free?
I notice that MeGUI is using LWLibavVideoSource intead of LSMASHVideoSource. Is that correct and what's the difference?
Last edited by VideoFanatic; 30th Nov 2015 at 03:50.