对于 ISV 来说，使用相机配置文件 1507 是一项重大挑战。这是由于配置文件的复杂呈现方式，以及它们仅仅作为一个信息性数据集的事实。尽管如此，底层管道仍允许可组合的媒体类型和流，这可能会违反硬件约束。
ISV 仍然面临配置捕获管道时的风险，即在激活流时可能导致失败。
对于相机配置文件 V2，媒体捕获对象的初始化时所选配置文件的配置将传达给帧服务器，帧服务器将仅公开该配置文件中有效的流/媒体类型的组合。
由于通过帧服务器路由时创建多个媒体捕获对象的成本较低，应用程序可以使用同一源预先创建多个媒体捕获对象的实例。 只有第一个创建的对象会产生源创建延迟。 后续实例只需在 Frame Server 上获取已创建的源，并根据配置文件筛选流和媒体类型集。
希望同时公开高质量照片模式和包含高帧速率视频或 4K 视频的视频录制模式的应用程序可以创建多个媒体捕获对象实例，每个实例都配置了同一相机源的不同配置文件。 只要任何给定时间只有一个媒体捕获对象正在主动流式传输，在媒体捕获对象之间切换会产生很少的延迟（通常是几个 RPC 调用的成本）。
相机配置文件 1507 通过 MediaCaptureVideoProfile 对象公开配置文件。 要通过 MediaCapture 工厂发现此对象，需要提供特定的设备 ID。 此以设备为中心的视图意味着希望启用特定方案的应用必须首先枚举/查找所选设备，并使用该设备循环访问可用配置文件。
相机配置文件 V2 扩展 API 图面以继续提供以设备为中心的 API 图面，但除此之外，相机配置文件 V2 还将提供方案驱动的配置文件枚举。
应用程序不是从特定相机开始，而是从特定场景开始。 例如，使用外向摄像头进行视频录制的场景。
此入口点提供适用于该方案的所有可用相机的应用。 根据方案的具体性，生成的 MediaFrameSourceGroup 列表可能包含多个条目。 在某些情况下，可能没有任何条目。 例如，对于没有世界摄像头的全In-One 设备，使用面向世界的视频录制将返回一个空集。
用于描述方案的“语言”允许基于最低条件进行回退。 该语言允许“进行视频录制，偏好使用面向世界的相机，并以最低30 fps的帧速率达到尽可能高的分辨率”。
基于配置文件的筛选
使用 Frame Server 体系结构的主要优点之一是，Frame Server 上的客户端上下文对象是客户端应用中媒体捕获对象的虚拟表示形式，与物理源分离。
这允许多个使用同一来源的客户端上下文对象实例在特定操作模式下进行设置和配置，其中包括筛选可能与底层用例冲突的引脚或媒体类型。
由于设备源不属于客户端上下文，因此创建具有不同配置的客户端上下文对象的多个实例不会产生任何重大开销（就像跟踪内部数据结构所需的开销一样）。
创建/初始化源的延迟仍然存在于第一个客户端上下文中，但创建后，具有相同配置或不同配置的后续实例只会产生创建内部数据结构的附加开销。
下图显示了配置了空配置文件的媒体捕获如何通过客户端上下文被帧服务器暴露。
在上图中，每个源都暴露三个引脚：预览、捕获和拍照。 由于设置了 null 配置文件，因此生成的媒体捕获会向应用程序公开所有 9 个引脚。 应用程序可以检查每个引脚，以及每个引脚上可用的每种媒体类型。
虽然这为应用程序提供了灵活性，但也增加了管理状态机的复杂性，需要确定可以同步激活的媒体类型和引脚组合。
但是，通过使用基于配置文件的筛选：
应用程序可以创建多个媒体捕获实例，每个实例都配置了特定的配置文件。 在上图中，null 配置文件实例保留为插图，应用程序可以选择不创建 null 配置文件实例。
每个低层的媒体捕获对象都配置有特定的配置文件。 根据 IHV/OEM 发布的配置文件信息，生成的管道将仅拉取所需的源。
对于 HQ 照片面向世界的配置文件，仅面向世界的 RGB（源 3）的预览和照片插针会被公开，同时仅公开 IHV/OEM 指示适用于照片操作的媒体类型。 在这种情况下，假定 IHV/OEM 已指明，对于高清照片，不支持同时捕获。 如果允许同时捕获，捕获引脚以及可用于同时进行照片和录制操作的媒体类型将可见。
对于“面向录制用户”，只会公开面向用户的 RGB（源 1）的预览和捕获引脚。 同样，上图假设在捕获引脚处于启用状态时无法进行拍摄操作。
对于混合现实配置文件，世界面向的 RGB 和感知视频流将被公开给客户端应用程序。 同样，只有那些保证能够同时工作的媒体类型才会被提供。