0

I'm wondering what the parameter pCapsFlags of DirectShow's IAMCameraControl::GetRange and IAMVideoProcAmp::GetRange mean. MSDN says the following

Receives a member of the CameraControlFlags enumeration, indicating whether the property is controlled automatically or manually.

however, this doesn't make a lot of sense to me since this is what the Get methods do. Also, GetRange gives me values of 1, 2 and 3 for most properties, so I was assuming that the return value here would be possible flags, thus a combination of CameraControl_Flags_Auto (0x0001) and CameraControl_Flags_Manual (0x0002).

While this would be handy, for some properties the returned value is 0, which doesn't support my assumption.

Can anybody tell me what the true meaning is?

Roman R.
  • 68,205
  • 6
  • 94
  • 158
iko79
  • 1,127
  • 10
  • 23
  • 2
    The meaning is straightforward: property can be controlled manually and/or automatically (by hardware). Zero value meaning is that there is no control (not so much different from "property not supported"). – Roman R. Dec 17 '15 at 17:56
  • Okay, what I thought would mean "property not supported" would be a `HRESULT` return value other than `S_OK`. What sense does it make to specify minimum, maximum, steppingDelta and default values (via `GetRange`) when the property is not supported in the first place? I'd assume, non-supported properties would simple be not "gettable"? After all there are such properties, and I thought these are the ones not supported. – iko79 Dec 17 '15 at 19:54
  • 1
    A buggy driver can pass that - I saw cases like this. – Roman R. Dec 17 '15 at 20:17
  • Actually, no, using a _MS LifeCam Studio_ I'm able to set both values and flags (in this case it's about `VideoProcAmp_Brightness`) without Set returning an error. I'm not sure about the flags, but I can definitely tell that the image is changing when I modify the value. – iko79 Dec 18 '15 at 09:11
  • I don't think you get zero in `pCapsFlags` with MS LifeCam Studio camera. – Roman R. Dec 18 '15 at 09:50
  • 1
    Well, in fact, I do. – iko79 Dec 19 '15 at 10:15
  • This is possible, however highly unexpected. Microsoft LifeCam HD-5001, Microsoft LifeCam VX-1000, Microsoft® LifeCam Cinema(TM) - all for brightness report 2, not zero. You can check it with [`DirectShowCaptureCapabilities`](http://alax.info/blog/1531) if you want. – Roman R. Dec 19 '15 at 12:19
  • My LifeCam HD-5001 also reports zeros in both sets of flags as well. DirectShowCaptureCapabilities confirms this (see below). Despite the zero flags, the camera reacts normally to changes in the brightness property. Here is the (abbreviated output) from DirectShowCaptureCapabilities: ## Device: Microsoft® LifeCam HD-5001 ### IAMVideoProcAmp VideoProcAmp_Brightness: 169, flags 0x00, 30..255, step 1, default 133, cap flags 0x00 – Stevens Miller Jul 27 '16 at 20:14
  • 1
    Yeah, same here, driver version 4.25.531.0: _VideoProcAmp_Brightness: 143, flags 0x00, 30..255, step 1, default 133, cap flags 0x00_ Well, at least I know it is not standard behaviour and my interpretation of the flags are correct. – iko79 Jul 28 '16 at 12:17
  • Glad to know I'm not the only one who sees this behavior. We are seeing it via the IAMVideoProcAmp interface, but note the strong similarity between that and the IAMCameraControl interface. The MSDN doc on the latter actually says, albeit obliquely, that a `KSPROPERTY_CAMERACONTROL_FLAGS_ABSOLUTE` flag is a possibility and that this "flag's" bit-mask is, indeed, 0x0000L. Never heard of a no-flag flag before, but there it is. Not sure what it means, but have a look yourself and let me know what you think: https://msdn.microsoft.com/en-us/library/windows/desktop/dd318251 – Stevens Miller Jul 28 '16 at 13:19
  • BTW, my driver is version 4.25.532.0. – Stevens Miller Jul 28 '16 at 13:22
  • Yeah, that's pretty weird, I agree. Only thing to do is check if 'KSPROPERTY_CAMERACONTROL_FLAGS_RELATIVE' bit is set and assume relative otherwise. Still, a value of 0x00 for an actually supported property seems like a bug to me. – iko79 Jul 28 '16 at 13:29
  • Agreed. Looking at Ksmedia.h, it appears that the `KSPROPERTY_CAMERACONTROL_FLAGS_ABSOLUTE` "flag" is really just the absence of the `KSPROPERTY_CAMERACONTROL_FLAGS_RELATIVE` flag. Your camera either takes relative values, or it doesn't (and if it doesn't, it necessarily takes absolute values). Calling this a flag seems like a really bad decision. Moreover, this may have nothing to do with why our LifeCams behave as they do. Most likely, it's just the bug it appears to be. – Stevens Miller Jul 28 '16 at 13:35
  • For even more wacky fun with your LifeCam 5001, create a simple graph to render its output in graphedt.exe or GraphEditPlus, run the graph, open the cam's property sheet, set the brightness to 255 and then set the zoom to 5 or more. The brightness will suddenly drop to its lowest level, although the property value won't change on the sheet. Not sure, but I think it goes to zero. Be sure to set to something in the legal 30-255 range before you exit, or things go badly the next time you try to add the cam to a graph. Something goes awry and Windows unloads the driver. This is one cranky gadget. – Stevens Miller Jul 29 '16 at 20:55

0 Answers0