Hi @bastio84,

Thanks a lot for your contribution! I am still going through the implications of this change, but please, do you think you could elaborate a little bit more about which property could be added, and where?

Thanks again!
Cesar

Hi @cesarsouza,
I had to be more precise in my comment, you are right!
I was thinking to add a property to the class Accord.Video.DirectShow/VideoCaptureDevice.cs, we could call it DesiredFrameRate, and use it to set the VideoInfoHeader.AverageTimePerFrame field (which is in 100 nsec units) accordingly.

As far as I know, there is no guarantee that the final video stream obtained will have exactly this framerate, but - at least in my setup - I cannot achieve more than 1 fps (even with other implementations of DirectShow for .NET) without doing this. I suspect that this is happened after the installation of some updates (before I've never had this problem). I had to do it also because I encountered the same problem with an industrial USB3 Vision camera on a machine running Windows Embedded Standard: no chance to see a video stream without setting the AverageTimePerFrame of VideoInfoHeader structure (I have to say that this could be dependent also on the particular implementation of the DirectShow driver for this camera).

Thanks again,
best regards.

Federico

Hi @bastio84,

Thanks a lot for the response, now I understand what you meant!

I had to do it also because I encountered the same problem with an industrial USB3 Vision camera on a machine running Windows Embedded Standard: no chance to see a video stream without setting the AverageTimePerFrame of VideoInfoHeader structure

Actually, this is quite interesting. Do you mean the video stream didn't start unless this property was set? I am now wondering if this isn't related to issue #881.

Regarding the new DesiredFrameRateproperty, I completely agree with this change. However, would you mind if I actually asked whether you could also add it to this same pull request? The point is that I didn't want to risk breaking the code since it is already working for you and I cannot test the issue myself.

In fact, I actually wanted to make a slight change to your proposal, that is, to allow this property to also be null, such that whenever DesiredFrameRate is set to null, then vih->AverageTimePerFrame should not be set to anything, not even 0. The reason for this is to be able to recover the original behavior of the framework just in case the manual setting of AverageTimePerFrame ends up causing problems for other users.

If not I can also do it myself, I just don't want to end up breaking the fix for your application in the process.

Again many thanks for the pull request!

Best,
Cesar

It is fine, I will try to do those changes myself! Thanks a lot!

Hi!
Thanks for merging. I invested a bit more time on this, and I was astonished when I saw that there was already a property named DesiredFrameRate in the class Accord.Video.DirectShow/VideoCaptureDevice.cs. This is probably an heritage from AForge, and the property was marked as obsolete, and body of property is doing nothing.

In addition, i tried to set the VideoInfoHeader.AverageTimePerFrame to a meaningful number (say, for example, to have 15 fps), but the response of the DirectShow driver is always with the highest framerate possible. It seems it has a problem only with the default value, which is 10000000.

Therefore, I fully agree with you in adding a nullable property, to keep the framework always working in the "regular" way if not changing the default (null) value.

Thanks!

Hi @bastio84,

Thanks for merging. I invested a bit more time on this, and I was astonished when I saw that there was already a property named DesiredFrameRate in the class Accord.Video.DirectShow/VideoCaptureDevice.cs. This is probably an heritage from AForge, and the property was marked as obsolete, and body of property is doing nothing.

Yeah, me too. It was indeed inherited from AForge.

I've added the new property at

Please let me know if you have any remarks, specially regarding the documentation!

Regards,
Cesar