I have a problem understanding if DirectShow filter (as well as CLEyeCameraGetFrame) work as expected and published FPS is really FPS of obtaining samples.

While camera connected:
—Just start GraphEdit and insert PS3Eye Camera capture filter;
—Render output pin;
—Start the graph;
—Goto properties of Video Renderer and see in Quailties tab FPS achieved.
Everything should be OK at this point.

Now Stop the graph.
Disconnect camera:
—start the graph again;
—message will popup stating “No PS3Eye camera device found…”.  Press OK;
—However, graph is running;
—Goto properties of Video Renderer and see in Quailties tab FPS shows the same as if camera was connected.

So, my question is:

Alex, are you firing next Frame on:
—really Frame arrival from USB;
—or you are just generating next frame on timer message from the current image buffer?

You obviously understand that above test shows that the stuff is just timer based, which is not really what I (and others) want…
However, maybe it’s just a problem of DirectShow filter and has nothing to do with your driver.
Please, explain.

igor1960 - 16 January 2010 11:36 AM

I have a problem understanding if DirectShow filter (as well as CLEyeCameraGetFrame) work as expected and published FPS is really FPS of obtaining samples.

While camera connected:
—Just start GraphEdit and insert PS3Eye Camera capture filter;
—Render output pin;
—Start the graph;
—Goto properties of Video Renderer and see in Quailties tab FPS achieved.
Everything should be OK at this point.

Now Stop the graph.
Disconnect camera:
—start the graph again;
—message will popup stating “No PS3Eye camera device found…”.  Press OK;
—However, graph is running;
—Goto properties of Video Renderer and see in Quailties tab FPS shows the same as if camera was connected.

So, my question is:

Alex, are you firing next Frame on:
—really Frame arrival from USB;
—or you are just generating next frame on timer message from the current image buffer?

You obviously understand that above test shows that the stuff is just timer based, which is not really what I (and others) want…
However, maybe it’s just a problem of DirectShow filter and has nothing to do with your driver.
Please, explain.

Do you see the image with camera disconnected, lol? Just kidding.
Lets look at the scenario. The camera filter is loaded, but physical camera is disconnected, the filter is run. What would you do? Crash the program? You can’t unload the capture filter at this point since it used. Besides many browsers including flash try to access the camera every time they are run.
One solution to this is to prompt the user saying that the physical camera is not connected but still make it run and return black frames. This is what I have done here. In this case, the frame rate you are seeing is completely meaningless.
The two modes of operation you are describing are completely different and should not be confused for one another.

AlexP

Alex,

The problem is: you are not returning black frame ==> instead last captured frame is returned.
So, result is just still last frame updating with proper speed. I doubt this proper.
As well as I dissagree: you should return some error code and stop the graph from running.
If you don’t do that: other filters in graph will never know that bad stuff happens, program will continue running, but what it is usefull for?

On the other hand, I specified different scenario: we are starting graph second time when camera is already dissconnected.
Not when already graph is running… It’s obvious that instead of displaying your custom message box (which you might continue to do) you should just return some error code, so the graph will report error through DirectShow mechanism.

igor1960 - 16 January 2010 03:45 PM

Alex,

The problem is: you are not returning black frame ==> instead last captured frame is returned.
So, result is just still last frame updating with proper speed. I doubt this proper.
As well as I dissagree: you should return some error code and stop the graph from running.
If you don’t do that: other filters in graph will never know that bad stuff happens, program will continue running, but what it is usefull for?

On the other hand, I specified different scenario: we are starting graph second time when camera is already dissconnected.
Not when already graph is running… It’s obvious that instead of displaying your custom message box (which you might continue to do) you should just return some error code, so the graph will report error through DirectShow mechanism.

Good suggestion, thanks. I tried this before. The error code caused crashes in various DirectShow clients, so there was no perfect way to handle this since many of them implement only subset of DS functionality and some of them don’t even check for errors. If I get time, will try and revisit this in the next version of the driver.

AlexP

Alex,

Then maybe gracefull way would be for capture filter to show text message and/or even fancy graphics instead of captured frames.
Just simple bitmap placed in resources of your filter could be easily loaded and pushed to downstream, Right?
So, bitmap might contain image that states to connect PS3Eye camera, maybe show USB plug and even animation on how to do this…

igor1960 - 16 January 2010 04:51 PM

Alex,

Then maybe gracefull way would be for capture filter to show text message and/or even fancy graphics instead of captured frames.
Just simple bitmap placed in resources of your filter could be easily loaded and pushed to downstream, Right?
So, bitmap might contain image that states to connect PS3Eye camera, maybe show USB plug and even animation on how to do this…

Ya, I though of this some time ago but haven’t had a time to design any graphics or animation for it. But that’s something I might do in the future release of the driver.

AlexP