Camera Profile V2 developer specification

This article provides an overview of the Camera Profile V2 developer specification.

Contents

Camera Profile V2 developer specification overview

Architectural overview

Detailed design for IHVs and OEMs

Sample profile declaration

Legacy profile

Sensor group generation

Sensor group configuration

Device MFT support

Sensor group transforms

Constraint match logic

Detailed design for ISVs

Profile discovery

Interfaces and interactions

Sample code

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.