I am working on a driver for a USB2 camera with the following hardware
characteristics:
1) The field size is 774x245
2) The camera can be programmed to output either interlaced (frame is
774x490) or progressive (frame is 774x245).
3) Also, the field height is programmable 1->245, the x start and xsize
are also programmable. Most importantly, the image is always vertically
centered at the bottom of the field (note there is no ystart parameter).
4) The frame period and integration period are also completely
programmable with only the following constraint: the pixel rate must be
less than 25Mhz, and the bit rate must be less than the USB2 ISO maximum
(192Mb/s). Notice that the frame rate is completely dependent on the
current format size.
The driver characteristics thus far:
1) Based on USBCAMD
2) Has custom property set to permit setting all the above parameters.
3) Has a ksproxy plugin to permit setting all the above parameters in a
COM compatible fashion.
4) Has a custom property page to permit setting all the above parameters
from graphedit/amcap.
5) Working with a fixed 640x480 format.
Now I want to implement all the nifty programmability. My problem is:
how do I represent this with regard to the StreamFormatsArray of the
HW_STREAM_INFORMATION? My original plan had been to write into the
KS_DATARANGE_XXX structure the currently programmed width/height/frame
rate options with the KS_VIDEO_STREAM_CONFIG_CAPS set such that there
was no other format option besides the one format.
The user would use either the custom property page or the COM interface
to set, for example, a new height. I would then issue a request to
renegotiate the format for the pin connection and dynamically create a
new KS_DATARANGE_XXX with the new settings. However, since I have now
discovered that StreamClassFilterReenumerateStreams (which I what I
think is needed for this renegotiation) is broken, I am not sure I can
do this any more.
Was this even a good plan to start with?
I really want to be able to use amcap/grapedit as a test interface for
the camera (so I don't have to maintain more code than the camera driver
for simple testing). Due to the programmability of the camera, it seems
crazy to try and set up KS_VIDEO_STREAM_CONFIG_CAPS to permit all the
possible combinations (in fact, I am not sure how I can force the image
to be at the bottom of the frame or how to handle the differences
between interlaced and progressive or the frame rate dependencies).
Moreover, it is not clear to me that graphedit would even give me *all*
the possibilities in the "Pin Properties:Stream Format:Output Size"
dropdown if I could get the KS_VIDEO_STREAM_CONFIG_CAPS set up correctly
(nor would I want the user to have to negotiate that list).
It would be alot more intuitive for the user to simply type in the
desired xsize/xstart, or ysize, in my custom property page and have the
output jump to that format. That way I could do all the parameter
validation (such as making sure the new bit rate does not exceed the
bounds) and issue sensible messages before trying to send it to the
camera.
I had considered forcing the KS_DATARANGE_XXX structure to always look
like it was 774x490 and then, based on the current settings of
interlace/progressive, xsize, etc. draw the actual camera output in the
right place - completely going behind the back of the
KS_VIDEO_STREAM_CONFIG_CAPS/bitmapinfo path to actually set those
parameters - and painting the rest of the image black. I suppose I
could do something similar for the frame rates as well.
Would that work? Is there at least a way to at least crop to the right
size bitmap?
I guess part of the trouble is it is not clear to me how much
information set in the SRB_GET_STREAM_INFO phase can be renegotiated
later during the SRB_GET_DATA_INTERSECTION phase of things. It looks
like I cannot make suggestions in SRB_GET_DATA_INTERSECTION, only
validate what the client wants to do (and thus if they don't pick what I
want, the connection will fail). If I could make suggestions, then I
could competely refill the PKSDATARANGE passed in the
STREAM_DATA_INTERSECT_INFO. But it looks like that data is "read only".
Any suggestions on solving this problem?
Thanks for any help.
Regards,
Tom