VideoHelp Forum
+ Reply to Thread
Results 1 to 8 of 8
Thread
  1. 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.
    Quote Quote  
  2. 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

    eg.
    LWLibavVideoSource("video.ts", threads=1)
    Quote Quote  
  3. 4:2:2 sat fees ?? that's news to me
    *** DIGITIZING VHS / ANALOG VIDEOS SINCE 2001**** GEAR: JVC HR-S7700MS, TOSHIBA V733EF AND MORE
    Quote Quote  
  4. Originally Posted by poisondeathray View Post
    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

    eg.
    LWLibavVideoSource("video.ts", threads=1)
    Thanks. I can save to either MKV or TS. A script for both would be useful.

    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:
    Code:
    <input>
    That tells MeGUI to use the correct indexer.
    How would I add threads=1 to that line?
    Quote Quote  
  5. 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)
    Quote Quote  
  6. 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?
    Quote Quote  
  7. 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.
    Quote Quote  
  8. I tried LSmash today in MeGUI. MeGUI edits the script as follows:

    LoadPlugin("X:\Portable Installations\MeGUI 2525\tools\lsmash\LSMASHSource.dll")
    LWLibavVideoSource("J:\Editing\plu0ngfj.2m3\Video. mkv")
    It takes a few minutes for MEGUI to process the .ts file including the index file that gets created before it starts encoding. This was only a 30 minute video so that's strange. I also noticed that it converted the .ts to an mkv in order to index it. Why would it do that when I thought LSmash supports .ts?

    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.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!