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

[Wilbert]

According to http://forums.animesuki.com/showthread.php?t=48608, there is an AviSynth plugin called avss.dll created by Haali (which can be obtained from the Haali Media Splitter).

DSS2 is Haali's implementation of Directshowsource. It has the advantage of being frame-accurate, but only supports VFR by converting it to CFR; at least that was the case when I tried it last time, it might have changed.

The point being is whether it is based on DSS, since DSS2 is closed source. I will ask him about it.

[Myrsloik]

As someone who happens to be in possession of the full source for dss2 I can tell you that it uses directshow and that's where the similarities end. There are no violations and in my opinion the only thing you'll develop with this line of questioning is a bad reputation...

[TheFluff]

You didn't notice this plugin until now? It's been around for years.

Also I wonder how your logic behind posting this thread went, was it something like "hey it has 'directshow' in the name so it must be a derivative, I better post a thread on doom9 about it to stir up some drama while I wait for Haali to answer" or what?

[Wilbert]

Oh c'mon, that was never my intension. I was just curious about the plugin since i hadn't seen it before. My apologies if anyone is offended and sorry that i took your words too literally.

[TheFluff]

Well if this is going to be turned into a general DSS2 thread... the syntax is:
dss2(string infile, float fps)
i.e.
loadplugin("avss.dll")
dss2("X:/test.mkv",fps=23.976)

Unlike the original DSS, it does not support loading audio. It also always converts VFR to CFR; i.e. it acts like the original DSS with convertfps=true does.

[cooolway]

how do I load audio from my video as it doesn't with DSS2?

[Myrsloik]

You don't, it's not supported in DSS2. Use another method and audiodub.

[halsboss]

For posterity and completeness of this thread, there were some reported "challenges" with it. See near the end of this post http://forum.doom9.org/showthread.php?p=1285639#post1285639

[Dogway]

Do I need to have Haali installed/registered in order to use dss2? because I just took avss.dll and uninstalled haali and now it doesn't work. I'd like to use it while keeping the system as clean of Haali as possible.

[LoRd_MuldeR]

Do I need to have Haali installed/registered in order to use dss2? because I just took avss.dll and uninstalled haali and now it doesn't work. I'd like to use it while keeping the system as clean of Haali as possible.

Well, DSS2 uses DirectShow, obviously. So you will need the suitable DirectShow filters (splitters and decoders) installed/registered on your system. Consequently for MKV or MP4 or TS files you'll need the Haali Media Splitter or something that can do the same job.

[IanB]

Dss2 uses the frame grab feature of Haali's directshow renderer.

So you need that as a minimum.

It is does not normally include itself in default graphs.

[Dogway]

It's for a wmv source.
I use lavfilters+ffdshow(wmv9)+madvr.

Can I then take the Haali's renderer files and copy them somewhere where it is requested?

[LoRd_MuldeR]

It's for a wmv source.
I use lavfilters+ffdshow(wmv9)+madvr.

Can I then take the Haali's renderer files and copy them somewhere where it is requested?

You will have to register the COM interface, I think.

C:\Program Files (x86)\Haali\MatroskaSplitter>regsvr32 splitter.ax
C:\Program Files (x86)\Haali\MatroskaSplitter>regsvr32 dxr.dll

[Dogway]

Looks like it turns practically into a manual install, I will check. Is ffms2 a worse option than dss2 for VC-1 sources?

[TheFluff]

Looks like it turns practically into a manual install, I will check. Is ffms2 a worse option than dss2 for VC-1 sources?

What container? TS will probably work very badly, other containers I don't know since I haven't tried it.

[Dogway]

wmv, I get eventual artifacts when frameskipping with ffms2. Not sure if its so at encoding...

[forclip]

Does anyone know how to contact the author of this plugin? Of course, assuming that he willing to fix (or at least take a look at) some bugs..

[IanB]

Does anyone know how to contact the author of this plugin?These may be a little stale but may get you started :-

Mike Matsnev (mailto:mike@haali.net), aka Haali (http://forum.doom9.org/member.php?u=38175) (Last Activity: 13th Oct 2009)

Haali Media Splitter Home (http://haali.su/mkv/) (Last updated 03/03/2011)


Report your bug, others may know the answer ....

[forclip]

Thanks.

The bugs:
1. This plugin can't handle a files that contains a symbols from my local CodePage. So it can't be used with (for example) C:\файл.mkv.

2. It may hangs when processing the last frames. Sure, this behavior may be related to splitters\decoders that's being used, but the same files works fine with DirectShowSource.

P.S. I don't looking for a workarounds, no need to point me to FFMS2, DGDecNV and so on.

[IanB]

1. Avss.cppHRESULT hr = dss2->OpenFile(CA2WEX<128>(filename, CP_OEMCP), avgframe);
DirectShowSource.cppMultiByteToWideChar(CP_ACP, 0, filename, -1, filenameW, MAX_PATH);
There is a whole thread dedicated to non-ascii characters in scripts.

2. The avss code seems predictable, I suspect the frame grab code in the renderer is getting caught. (I don't have the renderer code :( ) Sorry I can't help.

[forclip]

1. Avss.cpp
So you have the sources for this plugin? :)

[mandarinka]

Dss2 uses the frame grab feature of Haali's directshow renderer.

So you need that as a minimum.

It is does not normally include itself in default graphs.

Sorry for being paranoid, but I have to ask, since Haali's renderer only supports yuy2 and rgb32 input.

Does dss2 keep the decoded video data in yv12 colorspace, or does it in fact force a colorspace conversion? I don't think the latter is likely to be the case, but I'd like to get a confirmation, if someone can give one!

[IanB]

So you have the sources for this plugin? :)No, I only have some of the source.

[TheRyuu]

It seems the avss source package that I have contains the fix mentioned by IanB so perhaps it was updated at somepoint.

Build: avss.7z (http://warpsharp.info/avisynth/avss.7z)
Source: avss-src.7z (http://warpsharp.info/avisynth/avss-src.7z)

[forclip]

Build: avss.7z (http://warpsharp.info/avisynth/avss.7z)
Source: avss-src.7z (http://warpsharp.info/avisynth/avss-src.7z)
Thanks! Unfortunately, I still can`t open my "C:\файл.mkv", so I think that avss.dll that I had before was already "fixed". May be this issue is similar to this one (http://doom10.org/index.php?topic=25.msg4659#msg4659):

DirectShow probably expects Unicode strings only and FFMS2 isn't converting them before passing them to the splitter or something.

[IanB]

It seems the avss source package that I have contains the fix mentioned by IanB so perhaps it was updated at somepoint.

Build: avss.7z (http://warpsharp.info/avisynth/avss.7z)
Source: avss-src.7z (http://warpsharp.info/avisynth/avss-src.7z)
Huh! :confused: This source still uses CP_OEMCP (Dosbox code page) instead of CP_ACP (Windows code page).

To test this theory, create the .AVS in something using the OEM code page like Edit under Cmd.exe.



Also thanks TheRyuu for the full source code :D

[forclip]

This source still uses CP_OEMCP (Dosbox code page) instead of CP_ACP (Windows code page).

Replaced, and it did the trick! :)

[TheRyuu]

Huh! :confused: This source still uses CP_OEMCP (Dosbox code page) instead of CP_ACP (Windows code page).

To test this theory, create the .AVS in something using the OEM code page like Edit under Cmd.exe.



Also thanks TheRyuu for the full source code :D

For some reason I thought you hilighted it because it was what changed in your original post. I didn't see the correlation between 1 and 2, brainfart.

[qwerty1983]

Does this source filter convert my YV12 videos to YUY2? Can i avoid that?

Ok, i found the solution (http://forum.doom9.org/showthread.php?p=1699299#post1699299)

[TheFluff]

Does this source filter convert my YV12 videos to YUY2?

not in and of itself, no

Can i avoid that?

depends on your dshow environment

[LoRd_MuldeR]

It's a DirectShow-based source filter, so it probably returns whatever color format is returned from DirectShow Filter-Graph.

What DirectShow Decoder-Filter do you use? If it's something like FFdshow or LAVFilters, you should have a look at the "Output Formats" box in the decoder configuration...

https://azurehakua.files.wordpress.com/2012/02/options-lav-video-decoder1.png

[qwerty1983]

On the video decoder configuration (ffdshow) 'primary output color space' is set to auto. Even if i change it to YV12 the problem persists. I don't have LAVfilters. I'm not familiar with this stuff (directshow, vfw etc).

EDIT
I found the solution.
I went to Haali media splitter settings and changed the 'used custom media type for H264' from no to yes.

[forclip]

I think it is never too late, so here is my modded version of DSS2. README.txt (https://xvid4psp.googlecode.com/svn-history/r331/trunk/DSS2/README.txt) - please read this first to avoid unnecessary questions.

Main changes:

1. Fixed codepage issue (see previous messages in this thread).
2. Doesn't hangs at the end of the stream (see previous messages in this thread).
3. Doesn't requires Haali Media Splitter.
4. Can load and use LAVFilters in "portable" mode with ConnectDirect-way of building the Graph.
5. Added "preroll" for more precise seeking (very nice thing for badly-seeking sources). By default preroll=0 (disabled), but I recommend you to set it to something meaningfull.
6. Added "pixel_type" (string) - allowed colorspace (YV12, YUY2, RGB24, RGB32 or RGB - only one of them; or "" for all), it seems I forgot to mention this key in README :)
7. Some other things.

Examples:

DSS2("D:\file.mkv", fps=23.976)
- works almost the same way as the original DSS2 does.

DSS2("D:\file.mkv", fps=23.976, preroll=15, lavs="L3", lavd="L3")
- uses preroll and LAVFilters with ConnectDirect. You can write whatever you want instead of "L3" (which is "l3", which is default loading mode), but not leave it empty, because only non-empty string is a "ON"-switcher for this mode.

DSS2("D:\file.mkv", fps=23.976, preroll=15, lavs="L3", lavd="L3 hm1 hc5")
- the same as above, but LAVVideo is configured to use CUDA (hm1) for H264 and MPEG2 (hc5, 5=1+4).


DSS2 mod (2.0.0.13) + LAVFilters (0.63.0) (http://ge.tt/2QzHlt02/v/0)
SVN-src (https://code.google.com/p/xvid4psp/source/browse/trunk/DSS2/?r=331)


P.S. avss_26.dll (for AviSynth 2.6) does NOT support any additional colorspaces of AviSynth 2.6! And I don't have enough skills to implement it by myself, so patches are welcome. The same for audio support :)

[LoRd_MuldeR]

I don't have LAVfilters. I'm not familiar with this stuff (directshow, vfw etc).

Why not simply use FFmpegSource (https://github.com/FFMS/ffms2/releases) then?

Handles pretty much everything "out of the box" and doesn't need any external decoders/splitters (i.e. no DirectShow-dependencies, no VFW-dependencies).

[qwerty1983]

@forclip Than you, i'll try this.

@LoRd_MuldeR Because i have some clips (like the one i posted here (http://forum.doom9.org/showthread.php?t=171351)) that only load flawlessly (with no blocks and back-and-forth movement) with dss2 (i have tried AVCsource, LWLibavVideoSource, FFVideoSource)

[buchanan]

@forclip : I use your modded DSS2 very often and find it very convinient, especially the preroll, thank you for that.
Could you please provide a 64 bit version of your plugin ? I intend to use it with 64bit Avisynth+

[forclip]

Firstly I must set up DirectShow-related build environment on my new PC, because currently I can build DSS2 only on my old PC and only as 32-bit. After that at least I can try :) And of course I don't mind if someone else will make his own build meantime.

-----

Meantime, here it is (http://ge.tt/9lZndP42/v/0) (AviSynth+ x64), for testing purposes..

[manolito]

I want to take the opportunity to say thank you to forclip... :thanks:

I have been using DSS2Mod for quite some time now (together with LAV Filters), and I find it very reliable - more than ffms2.

5. Added "preroll" for more precise seeking (very nice thing for badly-seeking sources). By default preroll=0 (disabled), but I recommend you to set it to something meaningfull.

What would be a "meaningful" value in your opinion? I remember reading somewhere that the value should be at least twice the frame rate of the source. I tried that, but this setting really slows down the HCenc 1-pass mode (not the actual encoding run, but the first sample run where a lot of seeking is involved).



Cheers
manolito

[forclip]

What would be a "meaningful" value in your opinion? I remember reading somewhere that the value should be at least twice the frame rate of the source.

I don't know how it can be related to fps, I would say it is more related to key frames interval. As long as your file+splitter+decoder can be seeked fine (without frozen frames or artifacts) you don't need to raise this value too much. In other case you must find your own "meaningful" value. Just perform some random seeks (in AvsP, for example) and see frame-by-frame what's going on after each one. Increase this value if the result is incorrect. And keep trying..

[GMJCZP]

Thanks for the plugin forclip, I will try it.

[stax76]

Audio track selection would be very useful.

[manolito]

DSS2 and DSS2Mod does not do audio at all...


Cheers
manolito

[mariner]

I think it is never too late, so here is my modded version of DSS2. README.txt (https://xvid4psp.googlecode.com/svn-history/r331/trunk/DSS2/README.txt) - please read this first to avoid unnecessary questions.

.....

Greetings forclip. Many thanks for sharing the DSS2mod.

Two questions:

1. How frame accurate is it? When using the following script to convert a mkv source with 34460 frames from 30 to 25fps,
DSS2 reported processing 27815 frames, while DS and FFVS reported 27816.

Which is correct?

TDecimate(mode=1, cycle=6)

2. Need some guidance using the filter without Haali. I registered the LAV's with a higher merit, but still could not prevent Haali from loading.

Many thanks and best regards.

[filler56789]

2. Need some guidance using the filter without Haali. I registered the LAV's with a higher merit, but still could not prevent Haali from loading.

Open regedit.exe, goto

HKEY_CLASSES_ROOT\Media Type\Extensions ,

and erase the entries that associate .mkv, .mka, etc. with Haali's Source Filter.

Or even better, just get rid of Haali :devil: once and for all :)

[Emulgator]

1. How frame accurate is it? When using the following script to convert a mkv source with 34460 frames from 30 to 25fps,
DSS2 reported processing 27815 frames, while DS and FFVS reported 27816.

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.

[mariner]

Open regedit.exe, goto

HKEY_CLASSES_ROOT\Media Type\Extensions ,

and erase the entries that associate .mkv, .mka, etc. with Haali's Source Filter.

Or even better, just get rid of Haali :devil: once and for all :)

Thanks for the kind reply, filler56789.

1. Deleting these keys did not prevent Haali from loading. What about the other keys? Should they be removed as well without compromising the its functionality? The OS is W7x86.

2. DSS2 would worked if Haali is uninstalled (couldn't tell which source filter was used though), but DirectShowSource stopped working. The LAV Splitter Source was registered with a merit of 60001, but it wasn't loading. Any idea?

3. Haali is required by multiAVCHD, so uninstalling it is perhaps not an option here. Is there a way to modify the registry entries to prevent it from interfering with other software?

Many thanks and best regards.

[manolito]

In my experience having LAV Splitter and Haali installed in parallel is not a good idea, because Haali has the nasty habit to push itself into the foreground. Changing the merit value does not help.

So I agree with filler56789: If you have LAV Splitter installed, get rid of Haali once and for all... :devil:

BTW on my machine LAV Splitter installed itself with a merit of 00800004, maybe you should change the value on your machine.

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, and at least for BD Rebuilder and FFMpegSource who also say that Haali is required, I found that they work just fine with LAV Splitter instead of Haali. (Right now Jdobbs also endorses LAV over Haali).


Cheers
manolito

[mariner]

In my experience having LAV Splitter and Haali installed in parallel is not a good idea, because Haali has the nasty habit to push itself into the foreground. Changing the merit value does not help.

So I agree with filler56789: If you have LAV Splitter installed, get rid of Haali once and for all... :devil:

BTW on my machine LAV Splitter installed itself with a merit of 00800004, maybe you should change the value on your machine.

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, and at least for BD Rebuilder and FFMpegSource who also say that Haali is required, I found that they work just fine with LAV Splitter instead of Haali. (Right now Jdobbs also endorses LAV over Haali).


Cheers
manolito

Thanks for the kind reply, manolito.

1. Bumping up the merit didn't do the trick. Missing some registry entries, perhaps?

FYI, graphedit would load file source async and LAV splitter, but not LAV splitter source.

2. multiAVCHD appears to rely on Haali to display the video in the clip properties page and the chapters menu.

Many thanks and best regards.

[filler56789]

@mariner:
have you rebooted the machine after altering the registry?

[forclip]

1. How frame accurate is it? When using the following script to convert a mkv source with 34460 frames from 30 to 25fps,
DSS2 reported processing 27815 frames, while DS and FFVS reported 27816.

Which is correct?

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.


2. Need some guidance using the filter without Haali. I registered the LAV's with a higher merit, but still could not prevent Haali from loading.

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.

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