Confused about DirectshowSource and use LAV for AviSynth

[huokok]

I am new to encoding, currently using MeGUI to do most of the jobs.

I'm guessing novice people like me will firstly stuck in the source choice, seeking for a one solution for all videos.
For vob files, DGIndex does everything well, and then, I ran into some ts files. Following Megui's priority choice, it comes DGAVCIndex. However, the decoded frames are not accurate, don't know exactly what's wrong here, but at least the total frames count is not correct.:o

I'm now using DSS, specifically, I think it is LAV splliter source and LAV video decoder (after fighting against Haali splitter:rolleyes:)
If I did not make it wrong, Graphstudionext will show me the windows system filters used identically?
http://i.imgur.com/gD8VJfZ.jpg

I have read a post (two years ago?) saying that LAV is not designed for frame server. Also, AviSynth DSS WIKI entry says that 'DirectShow video decoders are not required to support frame-accurate seeking, not even required to tell you the frame rate.'

But, at this point of time, will LAV be a good choice to be the source? In LAV change log, I can see that avs support seems to be a recent feature.
In AvsPmod, I can check frames one by one, wouldn't it be sufficient:confused:
I ask those since in my sense, as long as LAV filters can give me correct playback, all the decoded frames should have accurate frame attribute.
Could anyone help me out of the mystery?
:helpful:

In terms of audio, I think LAV as directshow source is the right choice for me, especially for certain kind fancy DTS tracks:rolleyes:


EDIT: My supid misunderstanding. GraphStudio possibly may show me systerm filters used, but avs file is decoded but just acting like a video. So attached picture can not demonstrate what I thought.

[Asmodian]

FFMS2 (https://github.com/FFMS/ffms2/releases) is usually used for these operations. If you are doing something simple and linear DSS2() would probably work but I haven't used DirectShowSource for years now.

I believe the entry in LAV's change log was for playing Avisynth files not being used as a source filter in Avisynth.

[turbojet]

You are much better off using DSS2 mod with it's internal lav filters but don't forget to move latest lav files to the directory. If you are working with 23.976, 29.97, 59.94, etc. sources directshowsource/dss2 gives wrong frame count due to a rounding error. To fix it you can use assumefps(##000,1001) where ## = 24, 30, 60.

If you are working with interlaced ts sources you should set preroll to at least twice the framerate in dss2mod. There will be glitches with directshowsource and haali's dss2 with interlaced ts sources, ffms2 doesn't work well at all in such cases. LWLibavVideoSource() from lsmash works is worth checking out if you don't mind indexing, it has the advantage of being frame accurate without the ffms2 issues.

[huokok]

If you are working with 23.976, 29.97, 59.94, etc. sources directshowsource/dss2 gives wrong frame count due to a rounding error. To fix it you can use assumefps(##000,1001) where ## = 24, 30, 60.

If you are working with interlaced ts sources you should set preroll to at least twice the framerate in dss2mod. There will be glitches with directshowsource and haali's dss2 with interlaced ts sources, ffms2 doesn't work well at all in such cases. LWLibavVideoSource() from lsmash works is worth checking out if you don't mind indexing, it has the advantage of being frame accurate without the ffms2 issues.

Thank you for your guidance. Since I am using MeGUI, I can see it adds AssumeFPS(30000,1001) to 29.97fps materials which apparently relieves novice guys like me;) Here by your explaination, I now ackownleage the rationale behind this.

Speak of interlaced NTSC videos, it is another issue confuses me a lot. From my experiance, using lav as DSS appears to give me ideal outcome, at least in terms of my ripped outcomes, which I simply did resize, ivtc and add subtitles. Maybe I am plainly wrong:o

About frames count, first of all, will container matter? Won't it be video stream contained actually matters?:confused: Since you specifically mentioned this term, ts source.
So, I tried to simply put ts file into MKV through MKVMergeGUI and, WOW, for mystery reasons, the filesize becomes noticeable smaller. Well, this is another issue.
I observed that frames count is slightly different between ts and mkv, either by DSS or FFMS (I can see no glitches;)). By contrast, L-smash (LWLibavVideoSource) seems to give me approximately double total frames (like EVR HW/MadVR video deinterlacing?), haven't tried but I'm guessing I have to adopt another deinterlacing method?:rolleyes:

Maybe I should read through this article again with hard effort http://www.doom9.org/ivtc-tut.htm#Glossary
Would you please tell me, basically, what should be the proper frames count, which is accurate?

:thanks:

[turbojet]

The only time container should matter in your case is if it's ts with ffms2.

Double frame rate from lsmash and smaller file size after muxing doesn't sound right.

I'm not sure what your source is so don't know what your frame count should be. IVTC is generally 29.97 -> 23.976 but that's not always the case.

[detmek]

Well, if you remux ts to mkv file will be a bit smaller due to less overhead.

[huokok]

After a few searching, I found ffprobe -show_streams can give some information about media files, but there are more issues cofusing me. It seems that as long as a video is not decoded, it is impossible to get exactly accurate frames count.
So, in what method is the frames number determined? No matter what I use, there must be something on the left-hand side of an equation to get the answer.
My guess is from stream size and bitrate, the stream duration is claculated, then multiply by fps, we finally have an estimated total frames? Perhaps much more comlicated, I barely know anything about what constitudes a frame:devil:

So far, I think probably the best anwser is, just leave it as is, and feel "wooo, it somehow works!":p

[turbojet]

(seconds*1000) / (1000 / fps) = total frames

[raffriff42]

https://www.dropbox.com/s/colvuz65qg1qoxg/frames%2Cdur%2Cfps%20triangle3.png?raw=1
to find fps: tot_frames / dur_in_seconds
to find tot_frames: dur_in_seconds * fps
to find dur_in_seconds: tot_frames / fps

(adapted from the classic Ohm's law triangle (https://www.google.com/search?q=ohm's+law+triangle))

EDIT @turbojet - your answer is not wrong, it's just more complicated than it needs to be.

[huokok]

Thank you all, makes sense.
So fps&duration is the chicken, and total frames is the egg.:rolleyes:

[turbojet]

Actually my calculation is way off. What I was meaning to get was microseconds but all I did was complicate things. Microseconds needs to be defined to be accurate. A 10 second clip at 24 fps, can be 240-263 frames.

[Asmodian]

milliseconds, microseconds are more accurate than needed. :)

[huokok]

During recent using of FFmpeg, sometimes I will have this message
[aac @ 044440e0] Estimating duration from bitrate, this may be inaccurate
Guess it doen't tell me the video duration is calculated based on biterate as well:rolleyes: