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

[forclip]

Originally Posted by mariner

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.

Originally Posted by mariner

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]

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.

[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 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]

Originally Posted by 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 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.

Originally Posted by forclip

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

Originally Posted by forclip

1.1 The splitter\decoder decides.

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

Originally Posted by forclip

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, check it out or wait a couple days for the final release. That might change the behavior you're seeing with FFVS.

[forclip]

Originally Posted by mariner

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.

Originally Posted by mariner

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

Originally Posted by mariner

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