Camera Profile V2 developer specification
This article provides an overview of the Camera Profile V2 developer specification.
Contents
Camera Profile V2 developer specification overview
Detailed design for IHVs and OEMs
Overview
With Windows 10 1507, Camera Profile (herein referred to as Camera Profile 1507) support was added to allow IHV/OEMs to describe to the platform and to the developers the hardware limitation of the camera(s) available on the device.
These limitations ranged from concurrent use of cameras, limited media types based on concurrent use, and/or limited media types based on combinations of streams on one or more cameras.
However, the generation and consumption of these descriptive limitations proved to be cumbersome and error prone. Camera Profile V2 is an extension to the original spec to address many of the pain points discovered in the original Camera Profile specification.
V2 will also attempt to address the difficulty in consumption of the Camera Profiles by ISVs by using the support of Frame Server that is now available on Windows 10 platforms.
In Camera Profile 1507, there were two ways for Camera Profiles to be defined for any given machine:
KS API
INF Override
The KS API is a driver initialization time API to publish or update any profile information. To maintain backwards compatibility, these APIs are re-routed to support to Camera Profile V2 schema described below.
The INF Override was intended as a means to provide an override mechanism for a common driver set. For example, an IHV creates a single binary driver that initializes the Camera Profile based on a reference implementation, then produces multiple INFs that overrides the reference profiles with SKU specific profiles.
These INF Overrides will also be rerouted internally to the Camera Profile V2 to maintain backwards compatibility.
There are two major goals for this design:
Simplify Publishing of Camera Profiles
Simplify Consumption of Camera Profiles
For publishing of camera profiles, the requirements to declare profiles will be simplified to reduce the amount of code/INF that IHV/OEMs have to write.
For consumption of camera profiles, we'll use Frame Server's context management to alter pin/media types during initialization of each context to match the available profile information.
Terminology
| Term | Definition |
|---|---|
| Profile Constraint | A set of constraints that applies to the entire profile. |
| LRS | Profile Constraint tag: Represents Lock Resolution. |
| LFR | Profile Constraint tag: Represents Lock Frame Rate. |
| LST | Profile Constraint tag: Represents Lock Subtype. |
| DIS | Profile Constraint tag: Disable Profile. |
| UAR | Profile Constraint tag: Unlock Aspect Ratio. |
| Filter Set | A Profile Schema entry representing a set of Filters. |
| Filter | A Profile Schema entry representing a combination of Filter Attribute, Filter Comparison Operator and Filter Value. |
| Filter Attribute | Represents one of the attributes available in an MF Media Type. Currently only Resolution, Frame Rate and Subtype are defined: RES – Resolution FRT – Frame Rate SUT – Subtype |
| Filter Comparison Operator | Represents the comparison operation for a Resolution, Frame Rate or Subtype. |
| Filter Value | Value of the Filter Attribute. The representation of each varies based on the Filter Attribute. See below. |
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for