ISV (相机配置文件 V2) 的详细设计

使用相机配置文件 1507 for ISV 带来了重大挑战，因为配置文件的呈现方式很复杂，而且配置文件只是一个信息数据集，基础管道仍允许媒体类型和流组合，从而违反硬件约束。

ISV 仍存在以在激活流时失败的方式配置捕获管道的风险。

对于相机配置文件 V2，媒体捕获对象初始化时所选配置文件的配置将传达给帧服务器，帧服务器将仅公开在该配置文件中有效的流/媒体类型组合。

由于通过帧服务器路由时创建多个媒体捕获对象的成本较低，应用程序可以使用同一源预创建媒体捕获对象的多个实例。只有第一个创建的会引发源创建延迟。后续实例只需在帧服务器上获取已创建的源，并根据配置文件筛选流/媒体类型集。

希望同时公开“高质量照片”模式和包含高帧速率视频或 4K 视频的视频录制模式的应用程序可以创建媒体捕获对象的多个实例，每个实例都配置了同一相机源的不同配置文件。只要在任何给定时间只有一个媒体捕获对象正在主动流式传输，在媒体捕获对象之间切换不会产生很少的延迟 (通常) 几个 RPC 调用的成本。

相机配置文件 1507 通过 MediaCaptureVideoProfile 对象公开配置文件。此对象通过提供特定的设备 ID 通过 MediaCapture 工厂发现。此以设备为中心的视图意味着希望启用特定方案的应用必须首先枚举/查找所选设备，然后使用该设备循环访问可用的配置文件。

相机配置文件 V2 扩展 API 图面以继续提供以设备为中心的 API 图面，但除此之外，相机配置文件 V2 还将提供方案驱动的配置文件枚举。

应用程序从特定的相机开始，而不是从特定的方案开始。例如，使用面向世界的相机场景进行视频录制。

此入口点提供适用于该方案的所有可用相机的应用程序。根据方案的特殊性，生成的 MediaFrameSourceGroup 列表可能包含多个条目。在某些情况下，可能没有任何条目。例如，对于没有面向世界摄像头的一应一应设备，使用面向世界摄像头的视频录制将返回空集。

用于描述方案的“语言”允许基于最低条件进行回退。这是允许的语言，“视频录制优先于面向世界的相机和最高分辨率，最小帧速率为 30 fps”。

基于配置文件的筛选

使用帧服务器体系结构的主要优点之一是，帧服务器上的客户端上下文对象（客户端应用上媒体捕获对象的虚拟表示形式）与物理源分离。

这允许使用同一源 () 的多个客户端上下文对象的实例以特定的操作模式进行配置，其中包括筛选可能与基础用例冲突的引脚/媒体类型。

由于设备源不是客户端上下文的一部分，因此创建具有不同配置的客户端上下文对象的多个实例不会产生任何重大开销， (跟踪内部数据结构) 所需的开销相同。

对于第一个客户端上下文，创建/初始化源的延迟仍然存在，但创建后，具有相同配置或不同配置的后续实例只会增加创建内部数据结构的开销。

下图显示了帧服务器如何通过客户端上下文公开配置了 null 配置文件的媒体捕获：

在上图中，每个源都公开了三个引脚：预览、捕获和照片。由于设置了 null 配置文件，因此生成的媒体捕获会向应用程序公开所有 9 个引脚。应用程序可以检查每个引脚和每个引脚上可用的每种媒体类型。

虽然这为应用提供了灵活性，但也加剧了管理状态机的复杂性，从而确定可以同时激活哪种媒体类型/引脚组合。

但是，通过使用基于配置文件的筛选：

应用程序可以创建媒体捕获的多个实例，每个实例都配置有特定的配置文件。在上图中，空配置文件实例留作图示，应用程序可以选择不创建 null 配置文件实例。

每个较低的媒体捕获对象都配置了一个特定的配置文件。根据源的 IHV/OEM 发布的配置文件信息，生成的管道将仅拉取所需的源。

对于 HQ“面向世界照片”配置文件，仅公开面向世界 RGB (源 3) 的预览和照片引脚，以及 IHV/OEM 已指示的媒体类型将适用于照片操作。这假定 IHV/OEM 已指示，对于 HQ 照片，无法同时捕获。如果允许同时捕获，则会公开捕获引脚以及可用于同步照片和录制操作的媒体类型。

对于面向用户的录制，仅公开面向用户的 RGB (源 1) 的预览和捕获引脚。同样，上图假设在捕获引脚处于活动状态时无法执行照片操作。

对于混合现实配置文件，将向客户端应用公开面向世界的 RGB 和面向世界感知视频流。同样，只有保证同时工作的媒体类型才可用。