AForge.NET

  :: AForge.NET Framework :: Articles :: Forums ::

Video capture, CPU usage and the SYSTEM process [SOLVED]

Forum to discuss AForge.NET Framework, its features, API, how-tos, etc.

Video capture, CPU usage and the SYSTEM process [SOLVED]

Postby Xan-Kun » Fri May 12, 2017 5:34 pm

Hello dear AForge Team and a BIG thanks to everybody making this project possible. I already had tons of fun with this framework and even learned a lot from it's bugs ;-)

I would love to hear some ideas concerning an oservation of mine. Don't get me wrong, I love the performance, it's usually great and have no problems whatsoever at the moment with AForge. Like: at all! :P

Along the road (yes, I came from Bitmap.getPixel... stupid me :roll:) I did a lot of performance testing and discovered the following:

This is about the SYSTEM process, aka
NT AUTHORITY\SYSTEM

which usually shows up as the second process in process explorer.

As a baseline I used the classic AMCap by M$ which produces a load of around 5% in the SYSTEM process.
A simple AForge VideoSource/VideoSourcePlayer combination produces a load of around 16% in the SYSTEM process.

I can totally understand that as the whole managed/unmanaged shebang just takes time and I doubt there's a lot that can be done without directly using a DirectShow graph via Interop.
But 3 times as much seems a lot to me and I started wondering, what the big difference exactly is.

Some discoveries/concjectures I made:
* The load seems to be independent from the selected resolution (which means it's done accelerated in some way, I juess?)
* It goes down a little when the image is not actually drawn to the screen (like minimized window and such)
* I get the same results with a self-made PicturePainter (instead of VideoSourcePlayer) that only uses graphics.DrawImageUnscaled

One thing that is really strange:
The VideoCapabilites I get from the VideoSource says it's 1280x720@30(30) 24bpp but AMCap only whos a maximum capability of 1280x720@10 24bpp.
And 30 is about 3 times 10 ;-)

Do you think this is a coincidence or am I thinking in a completely wrong direction here? Why would the framerate is AForge show 30, when the hardware only supports 10?

I will do some testing with the now finished software (as I said, 15% is by far good enough!) on different hardware and am really curious about what's going to happen. :ugeek:

Any help/hint would make me really happy :-)

Thank you for your time.
Last edited by Xan-Kun on Wed May 17, 2017 2:46 am, edited 2 times in total.
Xan-Kun
 
Posts: 9
Joined: Sun May 07, 2017 12:25 pm

Re: Video capture, CPU usage and the SYSTEM process

Postby andrew.kirillov » Sat May 13, 2017 7:33 am

Hello,

Xan-Kun wrote:Why would the framerate is AForge show 30, when the hardware only supports 10?

AForge.NET reports you whatever was reported by DirectShow API. And this comes from camera driver in the end.
With best regards,
Andrew


Interested in supporting AForge.NET Framework?
User avatar
andrew.kirillov
Site Admin, AForge.NET Developer
 
Posts: 3453
Joined: Fri Jan 23, 2009 9:12 am
Location: UK

Re: Video capture, CPU usage and the SYSTEM process

Postby Xan-Kun » Sat May 13, 2017 2:13 pm

I am sorry, but no, it doesn't.

AMCap, VLC, MPC-HC, GraphEdit and my C source code all say 10Hz max @1280x720. Only AForge insists, that all resolutions support 30Hz (which obviously is not the case and makes computationally no sense). I tested on two other machines and got the same behaviour, only one Framerate shows up although the driver clearly specifies a differnt Framerate. To me, it looks like AForge uses the Framerate value globally.


P.S.: I would love to support the framework but I first need to understand what's going on.
Xan-Kun
 
Posts: 9
Joined: Sun May 07, 2017 12:25 pm

Re: Video capture, CPU usage and the SYSTEM process

Postby andrew.kirillov » Mon May 15, 2017 7:51 am

Here is a starting point for your further research. The rate reported by AForge.NET comes from VideoCapabilities.cs. It may not be the right way to calculate it all. Specially if you see all other applications report different things. But you can dig around there and see if something can be improved.
With best regards,
Andrew


Interested in supporting AForge.NET Framework?
User avatar
andrew.kirillov
Site Admin, AForge.NET Developer
 
Posts: 3453
Joined: Fri Jan 23, 2009 9:12 am
Location: UK

Re: Video capture, CPU usage and the SYSTEM process

Postby Xan-Kun » Mon May 15, 2017 11:19 am

Hi Andrew and thanks for the reply.
I did some ruther raeding now and,... yeah. The whole Framerate thing seems to be a huge mess from the driver perspective and most DS-filters report the average time between frames :roll:
I get it now why it is impossible to support every all diferent drivers as no consensus seems to be developed about how to handle different stream sizes.
Someone already did some coding and uses timers to calculate the frame-timing in order to avoid the temporal oversampling. Unfortunately it read this article some weeks ago and can't find it anymore :?
Xan-Kun
 
Posts: 9
Joined: Sun May 07, 2017 12:25 pm

Re: Video capture, CPU usage and the SYSTEM process

Postby Xan-Kun » Mon May 15, 2017 7:18 pm

Is there a way to show the driver properties page in AForge?
Xan-Kun
 
Posts: 9
Joined: Sun May 07, 2017 12:25 pm

Re: Video capture, CPU usage and the SYSTEM process

Postby Xan-Kun » Mon May 15, 2017 8:02 pm

I did a lot of reading and some tests now and it seems to me that the situation is even more complicated than I thought.
I tested on two machines.

The framerate capabilites which a camera reports seem to be depended on the settings of the video caputre filter.
If I enable "automatic brightness" for example, I get only 10Hz even at low resolutions. With it disabled, only the highest resolution uses 10Hz, all others work with 30Hz now.

I tried these things with AMCap and GraphEdit.

I think the only "solution" (at least for me now) is to show the native property page and let the user pick the settings from there.
@andrew.kirillov Only question now is, should I switch to DirectShow.NET or would it make sense to implement this in AForge?
Xan-Kun
 
Posts: 9
Joined: Sun May 07, 2017 12:25 pm

Re: Video capture, CPU usage and the SYSTEM process

Postby andrew.kirillov » Tue May 16, 2017 7:21 am

Xan-Kun wrote:should I switch to DirectShow.NET or would it make sense to implement this in AForge?

I don't spend time implementing new features in the framework any more. So it is up to you.
With best regards,
Andrew


Interested in supporting AForge.NET Framework?
User avatar
andrew.kirillov
Site Admin, AForge.NET Developer
 
Posts: 3453
Joined: Fri Jan 23, 2009 9:12 am
Location: UK

Re: Video capture, CPU usage and the SYSTEM process

Postby Xan-Kun » Tue May 16, 2017 3:30 pm

Hello Andrew. I am aware that you are not an active maintiner at the moment, so obviously, it would be up to me :|
But I am really unsure about the status of AForge.
From stackoverflow and other places I get the impression, that a couple of people on this planet are still using it quite actively (me included :mrgreen: ) ). On the other hand noone really seems to maintain the project at the moment and there doesn't seem to be active development.
Please correct me if I am wrong.
So my question was more about what you think about the current status of the project and I am pretty sure you heard of DirectShow.NET (which kinda is in the same situation) that's why I mentioned it.

And finally: Thank you so much again for all the work that went into AForge. I am having tons of fun with it and learned quite a lot :idea:
Xan-Kun
 
Posts: 9
Joined: Sun May 07, 2017 12:25 pm

Re: Video capture, CPU usage and the SYSTEM process

Postby Xan-Kun » Wed May 17, 2017 2:44 am

Just to let you guys know, I am using the native pin/stream properties dialog and when I select the higher resolution from here, the framerate automatically changes to 10Hz in the dialog. If I click OK now, the graph is build with the correct settings and only fires the NewFrame event 10 times a second (and not 30, as before). This quite exactly halves the system load (even a little more than that, which I can't really explain), so the CPU load of the SYSTEM process (including interrupts) is exactly the same as when I use AMCap with the same settings.
My application itself lingers at a constant 1% CPU (for motion detection) and everything works really smooth now.

I needed to make some changes to some framework classes and would love to propse them as a change, except I have no clue how to do that (I checked out the source code via SVN from github).
Last edited by Xan-Kun on Thu May 18, 2017 9:57 pm, edited 1 time in total.
Xan-Kun
 
Posts: 9
Joined: Sun May 07, 2017 12:25 pm



Next

Return to AForge.NET Framework