Share via

KSPROPERTY_CAMERACONTROL_PANTILT: values not in arc-seconds as documented

TomQuant 0 Reputation points
2026-05-07T21:32:39.32+00:00

The documentation for KSPROPERTY_CAMERACONTROL_PANTILT states:

"These values are expressed in arc-second units. One arc second is 1/3600 of a degree. Acceptable values range from −180×3600 to +180×3600 arc seconds."

However, for every camera tested (AVer CAM540, Logitech Rally, Poly EagleEye IV), IKsControl::KsProperty on PROPSETID_VIDCAP_CAMERACONTROL returns values which are clearly in deg.

Is the driver expected to convert to arc-seconds, or is the documentation wrong?

Environment: Windows 11 24H2

Windows development | Windows API - Win32
0 comments No comments

2 answers

Sort by: Most helpful
  1. TomQuant 0 Reputation points
    2026-05-08T10:34:22.8533333+00:00

    In fact, you can simply compare to the individual pan and tilt properties, which are actually specified in degrees - that is the trivial solution which we have implemented. But that is not the question I was asking. The underlying UVC interface definitely is specified in arcsec. I am trying to understand

    • whether the usbvideo.sys simply mis-implements this property, or whether the hardware is inconsistent with the standard. In the former case we might try to access the USB port directly, in the latter this would be a waste of time
    • whether there is any other way of getting the information at high resolution position.

    Was this answer helpful?


  2. Taki Ly (WICLOUD CORPORATION) 1,500 Reputation points Microsoft External Staff Moderator
    2026-05-08T08:57:29.3633333+00:00

    Hello @TomQuant ,

    To handle this situation, you might consider an approach of dynamically detecting based on the supported value bounds. You could refer to the following implementation approach:

    1. Use the IKsControl::KsProperty function with the KSPROPERTY_TYPE_BASICSUPPORT flag to retrieve the KSPROPERTY_STEPPING_LONG structure, which describes the bounds of the Pan/Tilt property.
    2. Based on the Bounds.SignedMaximum value, you can make an assessment:
      • If the maximum value is relatively small (e.g., <= 360), it is highly likely that the driver is using degrees.
      • If the maximum value is quite large (e.g., close to 180 * 3600 = 648000), this indicates the driver might be adhering to the documentation and using arc-seconds.
    3. Build a logic check to automatically apply the appropriate conversion ratio based on the conditions evaluated in step 2.

    In addition, you might also consider submitting a report via the feedback feature directly on the documentation page. You can find the "Was this page helpful?" section with thumbs up/down icons on the right side of the page. Clicking either icon will open a dialog where you can select a reason and use the "Tell us more" box to share information about the inconsistencies in real-world drivers. This could help the Microsoft documentation team consider adding necessary notes, which would better support the developer community in the future.

    Hopefully, these suggestions will be helpful for you. If you found my response helpful or informative, you could follow this guide to provide feedback.

    Thank you.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.