[mariner]

Originally Posted by forclip

That probably means DirectShow reporting slightly incorrect duration, or fps isn't set precise enough (23.976 instead of 23.9760239760), or your video is so huge, so DSS2's internal representation of one frame duration becomes not sufficient enough. For example of the last case (I doubt it is your case): lets assume we have a really huge and probably absolutely unreal video of 21474000 frames at 24000/1001 (23.9760239760) frame rate, like this:

BlankClip(length=21474000, width=320, height=240, pixel_type="yv12", fps=24000, fps_denominator=1001, audio_rate=0)

After opening it with DSS1\DSS2 you will see that frames count is (+\- 1 frame, see ceil\round\truncate thing above):

21473965 when fps=23.976
21474017 when fps=23.97602
21474017 when fps=23.9760239760


frame duration is calculated like this and stored as integer (fractional part is rounded, we lose it):

__int64 m_avgframe = (__int64)(10000000ll / fps + 0.5)

10000000/23.976         = 417083.75  -> 417084
10000000/23.97602       = 417083.402 -> 417083
10000000/23.9760239760  = 417083.333 -> 417083

23.97602 and 23.9760239760 - both produce the same value 417083, means 41.7083ms per frame. 417083/0.333 = 1252501.5, so each 1252501.5 frames (~14 hours) of such video will produce one extra frame due to accumulation of 0.333 part that we loose, resulting in 17 extra frames on whole video. Is it something to worry about when we have a video with such huge unreal duration? I don't know. But making m_avgframe of type "double" and applying some other related changes here and there seems fixes it. Also I added "fps_den" key, so fps can be set like this DSS2(..., fps=24000, fps_den=1001). But old style DSS2(..., fps=23.9760239760) is also supported - for this case DSS2 now internally call AssumeFPS(fps) to get nice num\den values, and then uses it

Not pretty much tested, I need to test it a little more before sharing, and I'm not sure I didn't broke something somewhere, overflowing due to different data types and so one. But at least it seems to work fine with this huge video, adding Info() to the first (source) script and ShowFrameNumber() to another script, that uses DSS2 to open the first script, showing that both total frames count and current frame number is the same.

The original hls recording showed ffmpeg creating 103026 frames, but mediainfo only reported 103025. FFVS reported 103026, but one less for DSS2mod.

I tried to replicate the result using the 1003 frame extract, but had the opposite:
DSS2mod reported 1003 frames but 3 less for FFVS.

Originally Posted by forclip

Yes, DSS2 will output 1000+ frames. Some frames here and there will be repeated - that's how frame rate conversion algorithm works. In my previous example 17 extra frames also means that some frames here and there will be repeated twice. If you have audio part, there will be no out-of-sync.

You're right about the repeted frames throughout.

DSS2 appears to have read the wrong fps from the mkv container, while FFVS was somehow smart enough to avoid it.

Many thanks and best regards.