I am not sure that this is universally prudent to limit FPS rate of DirectShow capture filter.

I’ve tried one of previous versions of distribution and discovered the following:
—setting higher then default 30FPS of latest driver works perfectly in my custom system where I wrote my own renderer.
However, using default windows renderers introduces jittery playback with higher framerate, especially when default DirectShow renderer window is stretched.

To reproduce, use older PS3Eye DiectShow capture filter, that allow 60FPS for exqample.
Build the graph in graphedit by just default rendering output pin.
Run the graph.
While output window of default renderer is not stretched everything works very smooth.
However, try maximizing output window. On my fast machine I do see around 20fps drop.

So, what I’m saying: just because default DirectShow renderers are optimized for not more then 30fps rendering => PS3Eye capturing shouldn’t be limited to the restrictions of other defualt windows component.

So, Alex, please, reconsider and include all possible framerates. I understand that from standpoint of support it’s easy to limit FPS to something reasonable that is used by most custom programs. However, in some situations high FPS is a huge advantage and shouldn’t be hidden and should be easily accessible.
Maybe, you will consider some registry entry setting which will allow higher choice of framerates and/or maybe even output formats then available by default.

igor1960 - 26 January 2010 12:19 PM

I am not sure that this is universally prudent to limit FPS rate of DirectShow capture filter.

I’ve tried one of previous versions of distribution and discovered the following:
—setting higher then default 30FPS of latest driver works perfectly in my custom system where I wrote my own renderer.
However, using default windows renderers introduces jittery playback with higher framerate, especially when default DirectShow renderer window is stretched.

To reproduce, use older PS3Eye DiectShow capture filter, that allow 60FPS for exqample.
Build the graph in graphedit by just default rendering output pin.
Run the graph.
While output window of default renderer is not stretched everything works very smooth.
However, try maximizing output window. On my fast machine I do see around 20fps drop.

So, what I’m saying: just because default DirectShow renderers are optimized for not more then 30fps rendering => PS3Eye capturing shouldn’t be limited to the restrictions of other defualt windows component.

So, Alex, please, reconsider and include all possible framerates. I understand that from standpoint of support it’s easy to limit FPS to something reasonable that is used by most custom programs. However, in some situations high FPS is a huge advantage and shouldn’t be hidden and should be easily accessible.
Maybe, you will consider some registry entry setting which will allow higher choice of framerates and/or maybe even output formats then available by default.

Please download the latest driver (just released few minutes ago). It exposes all of the available frame rates offered by PS3Eye camera. Also there are many fixes including a fix for unregistering under XP, ‘No camera found’ image when the camera is not plugged in, allocation of more buffers, fix for ‘winusb.dll not found’ issue and more.

AlexP

Alex,

I just tried and it looks to me important feature dissapeared from DirerctShow filter:
Property Page to set FPS/Frame Size is missing.
So, there is no way to set/test your stuff inside Graphedit.
THis should be fixed.

ALex,

Actually it’s even worse. Somehow, if I return back to previous driver (even by restoring system), my previous driver (v.3.0.0….) doesn’t show selection of capture properties either. It was working perfectly right before I’ve installed this latest driver.

Are you properly unregistering/registering property pages during capture filter unregistration/registration?
Just a guess, but looks like something wrong with property pages unregistration/registration. You might think that system invokes proper property page, while in fact it might be missing and/or different one.

Strange, but even restoring system to an earlier state using system restore doesn’t restore that property page with frames selection.
So, probably something changed in a driver?

igor1960 - 27 January 2010 11:27 AM

ALex,

Actually it’s even worse. Somehow, if I return back to previous driver (even by restoring system), my previous driver (v.3.0.0….) doesn’t show selection of capture properties either. It was working perfectly right before I’ve installed this latest driver.

Are you properly unregistering/registering property pages during capture filter unregistration/registration?
Just a guess, but looks like something wrong with property pages unregistration/registration. You might think that system invokes proper property page, while in fact it might be missing and/or different one.

Strange, but even restoring system to an earlier state using system restore doesn’t restore that property page with frames selection.
So, probably something changed in a driver?

The frame rate/size selection is not there anymore, since you can do this programmatically.
The property pages are registered/unregistered just fine. What are you trying to do by rolling back to previous version?

@Alex:

what do you mean by setting the framerate programmatically?

When I try to use the cam in Live Messenger for example, it seems as if it automatically runs on 640x480@60fps, so I get quite a lot of noise. I’d like to scale down to 320 and maybe 15 fps, so i don’t have that color noise going on which is better for compression through video chat.

Alex,

Not providing interactive format/fps selection I feel is a bad idea.
Alot of applications rely and are using OleCreatePropertyFrame and yours implementation of ISpecifyPropertyPages to set capturing properties.
Not implemented, this might make selection of format/fps impossible.

Even your own CL-Eye Test doesn’t have now ways of selecting Video Formats.
That’s for sure is not right.

chuck - 27 January 2010 03:18 PM

@Alex:

what do you mean by setting the framerate programmatically?

When I try to use the cam in Live Messenger for example, it seems as if it automatically runs on 640x480@60fps, so I get quite a lot of noise. I’d like to scale down to 320 and maybe 15 fps, so i don’t have that color noise going on which is better for compression through video chat.

Are you sure you are talking about the latest version of the driver? Because frame rate is set by client programs.
Also instead of auto setting, try adjusting exposure and gain manually.

igor1960 - 27 January 2010 03:22 PM

Alex,

Not providing interactive format/fps selection I feel is a bad idea.
Alot of applications rely and are using OleCreatePropertyFrame and yours implementation of ISpecifyPropertyPages to set capturing properties.
Not implemented, this might make selection of format/fps impossible.

Even your own CL-Eye Test doesn’t have now ways of selecting Video Formats.
That’s for sure is not right.

The filter actually implements ISpecifyPropertyPages. It is the output pin that currently does not implement this interface. Btw, the CL-Eye Test allows you to change video capture rate just fine.
Just be patient, the page will come back.

yup, i’ve downloaded it earlier today…i’ve tried it with the flash example and could set the framerate no problem.
when I compare the flash video and the video preview in Messenger i get a lot less noise in flash, when i lower the framerate.
I guess it’s just some messenger default to set it higher…bummer.

anyways, I have another question. I want to record a 320x240@ 120fps vid. Can anyone of you recommend any tool for this?

Alex,

You are technically right and Format selection is the property of output pin.
However, as this is capturing filter, I would say that you should include Format selection in both implementations of ISpecifyPropertyPage—pin and filter.
At least, other video capturing filters, including composite once, usually implement video capturing format selection in there first filter page.
Just my 2 cents.