Does anyone know avss.dll (ala DSS) from Haali?

[mariner]

I don't know, but I'm sure DSS2 must be better than DSS. Also, you can try with preroll=15 or bigger values. And yes, if DSS\DSS2 for some reasons used different filters in filter graph,
the results may also be different, regardless of frameaccuracy of the DSS\DSS2 on its own.


Call it like this (... - means your source file and\or other settings)

DSS2(..., lavs="L3", lavd="L3")
- to load LAV splitter and decoder from the \LAVFilters subfolder (relative to avss.dll path) using default settings. In this mode you dont need to install\register LAV Filters, you only need to put their files into \LAVFilters subfolder.
Then DSS2mod will be able to load it in portable mode without any interference with already installed version, if such exist.

DSS2(..., lavs="L0", lavd="L0")
- to load your installed LAV Filters (regardless of merit) with its settings.

I want to note about the statement "DSS2mod does not require Haali". DSS2mod, in opposite to DSS2, really doesn't require "Haali Video Sink" to be installed - a video capturing filter, that distributed with Haali package. DSS2mod have it built in. But when you not use lavs="something" and lavd="something" (i.e. by default), it will works almost like the original DSS2 does, using whatever you have installed\registered, according to its merits and all other DirectShow "magic". So, if according to those "magic" Haali Splitter must be used - it will be used.

Thanks for the detail instructions, forclip.

Placing the avss.dll and LAVfilters subfolder in the AviSynth plugins folder does the trick. Merci.

Pls see the next post for frame accuracy tests.

Many thanks and best regards.

[mariner]

You may want to reproduce which frame is missing by using ShowFrameNumber.
In my case testing anything DirectShow some years ago there was the first frame missing when running in Win7U64SP1,
but first frame delivered when running WinXP32ProSP3.
So the culprit may well be the DirectShow filter alone, not necessarily the splitter.

Splendid idea, Emulgator. Here's some preliminary test results comparing DSS2 (with LAV) and FFVS:

1. Testing without the Tdecimate filter showed that:
(a) DSS2 would process one less frame than FFVS, and
(b) in some cases, FFVS processed one less frame than the frame count reported by mediainfo.

2. ShowFrameNumber indicated DSS2 would drop the last frame.

3. Using Haali did not affect the outcome.

What do you make of these?

[forclip]

Pls see the next post for frame accuracy tests.


Total frames reported by DSS2 - less by one frame too? TotalFrames=Duration/average_frame_time, where Duration is IMediaSeeking::GetDuration (https://msdn.microsoft.com/en-us/library/windows/desktop/dd407029(v=vs.85).aspx) and average_frame_time is VIDEOINFOHEADER's AvgTimePerFrame (https://msdn.microsoft.com/en-us/library/windows/desktop/dd407325(v=vs.85).aspx) of the first frame when "fps=" is not set, or recalculated value of "fps=" key when it is set. So probably media duration or fps detection is wrong, fps isn't precise enough or rounding error somewhere.

Can you send me a sample file to test?

[AGKnotUser]

Hi,

I'm new to Dss2mod, forgive me if this has an obvious solution:

If I run DSS2("C:\Blu-ray Streams\Input_Video_File.vc1",lavd="l3 hm1") all is well. If instead I run DSS2("C:\Blu-ray Streams\Input_Video_File.vc1",lavd="l3") it just runs forever. Only vc1 files are affected. Task manager shows plenty of disk activity. I'm trying to make the code hardware independent. Any help would be appreciated.

Edit: Answered my own question. I just let it run and it indexed the file in 25 min.

[mariner]

Total frames reported by DSS2 - less by one frame too? TotalFrames=Duration/average_frame_time, where Duration is IMediaSeeking::GetDuration (https://msdn.microsoft.com/en-us/library/windows/desktop/dd407029(v=vs.85).aspx) and average_frame_time is VIDEOINFOHEADER's AvgTimePerFrame (https://msdn.microsoft.com/en-us/library/windows/desktop/dd407325(v=vs.85).aspx) of the first frame when "fps=" is not set, or recalculated value of "fps=" key when it is set. So probably media duration or fps detection is wrong, fps isn't precise enough or rounding error somewhere.

Can you send me a sample file to test?

Thanks for the kind reply, forclip.

1. The original DSS2 apparently had a similar issue.

http://forum.doom9.org/showthread.php?p=1599416#post1599416

2. An explanation was given below, but didn't seem to addres the dropped frame issue. Any idea?

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

3. Is DSS2mod now issue free with interlaced sources if preroll is set to at least twice the framerate?

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

4. Any lingering issue with ts sources?

5. Attached for your testing pleasure is a 1000 frame clip that was causing DSS2 and DSS2mod to drop the last frame.

Many thanks and best regards.

[forclip]

2. AssumeFPS can't help in this case, it can only make fps look better, but it can't bring back dropped frames or remove duplicated frames.
3. and 4. - the things still depends on used splitter\decoder. About preroll - see here (http://forum.doom9.org/showthread.php?p=1699381#post1699381).
5. Thanks. The problem is in this calculation (duration and m_avgframe - both int64):

num_frames = (int)(duration / m_avgframe); //Truncate

In DSS the same thing looks like this:

num_frames = (int)((duration + (m_avgframe - 1)) / m_avgframe); //Ceil

But I think that Rounding is better choice

num_frames = (int)((duration / (double) m_avgframe) + 0.5); //Round

Sometimes it is better to Ceil, sometimes to Round (sometimes to Truncate :) ), but still there is a chance that calculated value will not equal the real frame count of the video.
That's by design, inaccuracy here and there (incorrect Duration returned by DS, fps=23.976 vs fps=23.9760239760,..), and DSS also affected.

Here (http://ge.tt/47I46UG2/v/0)is two versions for testing: avss_ceil and avss_round.

[mariner]

2. AssumeFPS can't help in this case, it can only make fps look better, but it can't bring back dropped frames or remove duplicated frames.
3. and 4. - the things still depends on used splitter\decoder. About preroll - see here (http://forum.doom9.org/showthread.php?p=1699381#post1699381).
5. Thanks. The problem is in this calculation (duration and m_avgframe - both int64):

num_frames = (int)(duration / m_avgframe); //Truncate

In DSS the same thing looks like this:

num_frames = (int)((duration + (m_avgframe - 1)) / m_avgframe); //Ceil

But I think that Rounding is better choice

num_frames = (int)((duration / (double) m_avgframe) + 0.5); //Round

Sometimes it is better to Ceil, sometimes to Round (sometimes to Truncate :) ), but still there is a chance that calculated value will not equal the real frame count of the video.
That's by design, inaccuracy here and there (incorrect Duration returned by DS, fps=23.976 vs fps=23.9760239760,..), and DSS also affected.

Here (http://ge.tt/47I46UG2/v/0)is two versions for testing: avss_ceil and avss_round.

Thanks forclip. Looks promising so far.

1. Would it be Ok to just place avss_round.dll (without renaming it) in the plugin folder after removing the original avss.dll? Is it necessary to also rename avss.avsi to avss_round.avsi?

2. One ts file is still reporting dropped frame. Would the first few bytes of the file be helpful to you?

Many thanks and best regards.

[mariner]

...

And when some software states that it requires Haali, I found that this is not true most of the time. LAV Splitter does everything Haali does and then some...


Greetings manolito.

Further testings with multiAVCHD suggests you may be right after all. Haali is indeed not indispensible.

Many thanks and best regards.

[forclip]

1. Would it be Ok to just place avss_round.dll (without renaming it) in the plugin folder after removing the original avss.dll? Is it necessary to also rename avss.avsi to avss_round.avsi?

Yes. You don't need avss.avsi at all if you call DSS2 like DSS2(...) and not like DirectShowSource2(...). You don't need to rename it anyway.

2. One ts file is still reporting dropped frame. Would the first few bytes of the file be helpful to you?

Are you sure it is really dropped? Does avss_ceil.dll make it available? How did you determine the real frame count of your file? Try with something that really browse thru your file via indexing, like FFMS2, LWLibavVideoSource, DGIndex(NV).

The first few bytes doesn't make any sense to me :)

[mariner]

Yes. You don't need avss.avsi at all if you call DSS2 like DSS2(...) and not like DirectShowSource2(...). You don't need to rename it anyway.


Thanks.

Are you sure it is really dropped? Does avss_ceil.dll make it available? How did you determine the real frame count of your file? Try with something that really browse thru your file via indexing, like FFMS2, LWLibavVideoSource, DGIndex(NV).

The first few bytes doesn't make any sense to me :)

I meant DSS2mod reporting one less frame than FFVS when running x264, both round and ceil.

Would first 100k bytes be sufficient for testing?

In another clip, the fps was mis-identified by DSS2mod (Haali too) as 30.303, hence reporting 1000+ more frames. Would these additional frames be created by x264?

Many thanks and best regards.

[forclip]

I meant DSS2mod reporting one less frame than FFVS when running x264, both round and ceil.


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.


In another clip, the fps was mis-identified by DSS2mod (Haali too) as 30.303, hence reporting 1000+ more frames. Would these additional frames be created by x264?

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.

A first few kb of a video file most probably will be useless to me, because I don't know how to parse one or another container\format, headers, and DSS2 doesn't do such work.. Only if a problem can be reproduced with such a sample - then it can be useful to me.

[mariner]

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.


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.

[forclip]

Here is my findings about higher total frames count, even when fps is set exactly. All those files have the first frame's timecode not starting from zero, this extra-time results in some extra-frames added by DSS2 at the beginning, which are actually a dub of the first "real" frame. Something like this: 1-1-1-1-2-3-4-5 - the first three number one is what I'm talking about. Discarding them may results in out-of-sync, or opposite - I don't know, most probably it depends on how audio part is handled. So I decided to make it optional by adding a new key "tc_offset" (int), negative values will use the first frame's time code as the offset (aka Auto mode). Zero - means no offset, currently it is default value, everything works like before. And positive values - user-specified offset in DS-time format, for example 400000 means 40ms.

And as said before, fps handling has changed. To set fps there is now two keys: "fps" (float) and new "fps_den" (int). If "fps_den"(ominator), not set or equal 0, "fps" is treated as float and passed as an argument to AssumeFPS. AssumeFPS makes nice numerator/denominator values from it, and then DSS2 uses it. But when both "fps" and "fps_den" is set and >0, "fps" treated as fps_numerator, decimal part is truncated. AssumeFPS not involved in this case, because both numerator/denominator are known.


Test (http://ge.tt/8sVdH0H2) build, src diff also included if any interested in it. If there is something weird or wrong as you think - please let me know, I'm not a big expert in DS and C++ programming :) .


About 30.303fps detection in one of the samples - AvgTimePerFrame is 330000 (33ms) and the first frame's start-end timecodes also == 330000. Isn't it 30.303fps? FFmpeg also report for this file:
Stream #0:0: Video: h264 (High), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 30.30 fps, 30.30 tbr, 1k tbn, 59.94 tbc (default)

Even if there is 29.970 value somewhere in this file - I don't know how to obtain it from what we have from DS..

[mariner]

Here is my findings about higher total frames count, even when fps is set exactly. All those files have the first frame's timecode not starting from zero, this extra-time results in some extra-frames added by DSS2 at the beginning, which are actually a dub of the first "real" frame. Something like this: 1-1-1-1-2-3-4-5 - the first three number one is what I'm talking about. Discarding them may results in out-of-sync, or opposite - I don't know, most probably it depends on how audio part is handled. So I decided to make it optional by adding a new key "tc_offset" (int), negative values will use the first frame's time code as the offset (aka Auto mode). Zero - means no offset, currently it is default value, everything works like before. And positive values - user-specified offset in DS-time format, for example 400000 means 40ms.

And as said before, fps handling has changed. To set fps there is now two keys: "fps" (float) and new "fps_den" (int). If "fps_den"(ominator), not set or equal 0, "fps" is treated as float and passed as an argument to AssumeFPS. AssumeFPS makes nice numerator/denominator values from it, and then DSS2 uses it. But when both "fps" and "fps_den" is set and >0, "fps" treated as fps_numerator, decimal part is truncated. AssumeFPS not involved in this case, because both numerator/denominator are known.


Test (http://ge.tt/8sVdH0H2) build, src diff also included if any interested in it. If there is something weird or wrong as you think - please let me know, I'm not a big expert in DS and C++ programming :) .


Some additional results to report before testing the new build:

A demuxed/remuxed clip (without audio) created from the sample sent showed FFVS dropping 4 frames at the end. 4 new frames were added at the beginning to maintain 1000 frame count. Old DSS2mod has no issue.

Apparently demuxong/remuxing didn't help with the issue.


About 30.303fps detection in one of the samples - AvgTimePerFrame is 330000 (33ms) and the first frame's start-end timecodes also == 330000. Isn't it 30.303fps? FFmpeg also report for this file:

Even if there is 29.970 value somewhere in this file - I don't know how to obtain it from what we have from DS..

Both mediainfo and FFVS reported 29.97, while eac3to reported 29.97 for the h264 video track, but 30.303 for the mkv container.

This is the original ffmpeg report:

Metadata:
duration 4882.51
moovPosition 48.00
width 1920.00
height 1080.00
videocodecid avc1
audiocodecid mp4a
avcprofile 100.00
avclevel 40.00
aacaot 2.00
videoframerate 29.97
audiosamplerate 44100.00
audiochannels 2.00
tags:
©too Lavf53.24.2
trackinfo:
length 14632800.00
timescale 2997.00
language und
sampledescription:
sampletype avc1
length 215318528.00
timescale 44100.00
language und

Metadata:
moovPosition : 48
avcprofile : 100
avclevel : 40
aacaot : 2
videoframerate : 30
audiochannels : 2
©too : Lavf53.24.2
length : 215318528
timescale : 44100
sampletype : mp4a
Duration: 01:21:22.51, start: 0.000000, bitrate: N/A
Stream #0:0, 41, 1/1000: Video: h264 (High), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 30.30 fps, 29.97 tbr, 1k tbn, 59.94 tbc
Stream #0:1, 58, 1/1000: Audio: aac (LC), 44100 Hz, stereo, fltp

Many thanks and best regards.

[mariner]

Greetings forclip.

1. What is the convention followed when dealing with video delay?
It would appear delay is ignored when demuxing, and by FFVS2.20 as well, is it not?

2. Is frame insertion the default now? How to disable it?

3. Frame insertion doesn't seems to work for mkv when no audio track present.

4. Dropped frames at the end for ts, the number equal to the number of inserted frames.
No such problem for mkv.

5. Adding AssumeFPS(30000,1001) does not rectify wrong fps issue. Beethoven clip still reporting 1000/33 fps.

Many thanks and best regards.

[forclip]

1.1 The splitter\decoder decides.

2. When tc_offset=0 everything works like before, and it is set to 0 by default. That means if the first actual frame's timestamp > 0, DSS2 will add as much repeated frames before it as much can fit in this gap (between 0 and actual timestamp) - this is from the original DSS2. When "tc_offset=-1" the gap handled in another way, no duplicated frames will be added - this is new feature.

3., 1.2 That means the first frame's time code == 0, or the gap is less than one frame duration. Really, there is no point to apply a delay in case there is only one track. Delay - relative to what in this case? At least MKVMerge (7.6.0 at hands) ignores the Delay field, it adds "--sync" "0:10000" (10 seconds delay) to CLI, but I can't see any delay in resulting file and the playback starts right after opening this file in a player.

4. For now I only have tested with this (http://forum.doom9.org/showthread.php?p=1723364#post1723364) (broken?) sample, and it seems Duration reported by LAV less than actual duration, so few frames at the end can't be accessed with DSS1\2. Reported duration is 4503600000, but even after a frame with timecode 4503649222 there is ~44 frames available, up to 4513449222 (with some drops at the end).

Now your new samples (thanks!).
40.ts - reported duration is 11980000000 and there is no frames available after 11980003333, so duration is fine and total frames count (29950) for this duration is correct. The first frame arrives with 403333 timestamp, meaning one extra frame added by DSS2 with tc_offset=0 (default), or not added with tc_offset=-1 - in this case total frames count = 29949. This is correct.
m1.ts - reported duration is 100000000, but there is two frames available up to 100800000 - they are unaccessible for us, total frames count (250) is wrong. And the same thing with tc_offset: if we removed extra frames (tc_offset=-1), total frames count also becomes less by its number.

So incorrect Duration reported for some files - probably the only problem. I don't think I can do anything.. Only by introducing some kind of indexing to see the real frames count\duration?! But there is FFMS2\L-SMASH\DGIndex already exist, the point of DSS2 existing (at least for me) - is to avoid indexing step. But without it we are limited to what DS reported to us.

5. You don't need to add AssumeFPS to DSS2, it will not change how DSS2 handle fps. You need to set actual fps by using "fps" (or "fps" and "fps_den") key - only this way you can tell DSS2 how to handle your file. If fps auto detection doesn't work for your file and results in incorrect fps - you need to set correct value by yourself! When previously I said that AssumeFPS is now internally used, I doesn't meant
that it is used like this:

DSS2(...)
AssumeFPS(fps)

It is used in another way, something like this:

BlankClip().AssumeFPS(fps)
numerator = FrameRateNumerator()
denominator = FrameRateDenominator()
DSS2(..., fps=numerator, fps_den=denominator)

[mariner]

Greetings ofrclip. Many thanks for the detail explanation.

1.1 The splitter\decoder decides.


1. Does FFVS behave like DSS2mod in a system with just LAV and FFdshow(low merit)?



5. You don't need to add AssumeFPS to DSS2, it will not change how DSS2 handle fps. You need to set actual fps by using "fps" (or "fps" and "fps_den") key - only this way you can tell DSS2 how to handle your file. If fps auto detection doesn't work for your file and results in incorrect fps - you need to set correct value by yourself! When previously I said that AssumeFPS is now internally used, I doesn't meant
that it is used like this:

DSS2(...)
AssumeFPS(fps)

It is used in another way, something like this:

BlankClip().AssumeFPS(fps)
numerator = FrameRateNumerator()
denominator = FrameRateDenominator()
DSS2(..., fps=numerator, fps_den=denominator)

2. So this would work for NTSC video with uncommon fps?

DSS2(..., fps=30000, fps_den=1001)


3. FFVS vs DSS2:

Well, either DSS2 got it wrong, or FFVS had trouble with both the ts clips, dropping frames at the start and repeating frames at the end. Couldn't get the 2.22 beta built to work here, suggestions appreciated.

Many thanks and best regards.

[foxyshadis]

Myrsloik just fixed some first-frame bugs in the latest test build (https://forum.doom9.org/showthread.php?p=1724748#post1724748), check it out or wait a couple days for the final release. That might change the behavior you're seeing with FFVS.

[forclip]

1. Does FFVS behave like DSS2mod in a system with just LAV and FFdshow(low merit)?

I have no idea how FFMS2 internally work in regards of various things. I can say the same about LAV Filters too. That's why I can't compare them.



2. So this would work for NTSC video with uncommon fps?
DSS2(..., fps=30000, fps_den=1001)

If you need to re-encode your file from one fps to another - then yes. I don't know why you may need to have another fps, but you must understand that fps conversion in this case will produce dropped\duplicated frames here and there on whole video (it's not about first\last frames) - that's how it works, similar to ChangeFPS(). Do you really need it? If not, just set fps to its actual value. With VFR video, you probably need to set it equal to the most higher fps, or even higher, something like 120 if I remember correct, and then deal with it in a special way - I'm a noob in VFR videos, can't say anything else about it :)




3. FFVS vs DSS2:

Well, either DSS2 got it wrong, or FFVS had trouble with both the ts clips, dropping frames at the start and repeating frames at the end. Couldn't get the 2.22 beta built to work here, suggestions appreciated.
Or both. Try with other source-filters: LWLibavVideoSource, DGDecNV (requires an Nvidia video card), DGDecIM (beta, requires QuickSync, but also works in software decoding mode; I have no idea if SW-mode is limited to Intel-only CPU, probably not, but I'm on Intel and for me it works anyway)..