ISV (數位相機配置檔 V2 的詳細設計)
由於配置檔呈現方式的複雜本質，以及配置檔只是信息數據集的事實，基礎管線仍允許違反硬體條件約束的媒體類型和串流組合，因此使用相機配置檔 1507 帶來重大挑戰。
ISV 仍會以啟動數據流時失敗的方式來設定擷取管線的風險。
針對相機配置檔 V2，媒體擷取物件初始化時所選取配置檔的組態將會傳達給畫面伺服器，而 Frame Server 只會公開該配置檔內有效的數據流/媒體類型組合。
由於透過 Frame Server 路由傳送時建立多個媒體擷取物件的低成本，因此應用程式可以使用相同的來源預先建立多個媒體擷取對象的實例。 只有第一個建立的項目會產生來源建立延遲。 後續實例只會取得框架伺服器上的已建立來源，並根據配置檔篩選數據流/媒體類型集。
想要同時公開高品質相片模式和包含高幀速率視訊或 4K 視訊的視訊錄製模式的應用程式，可以建立多個媒體擷取對象的實例，每個物件都針對相同的相機來源使用不同的配置檔進行設定。 只要在任何指定時間只有其中一個媒體擷取對象主動串流處理，在媒體擷取對象之間切換會產生少量延遲， (通常是幾個 RPC 呼叫) 的成本。
數字相機配置檔 1507 會透過 MediaCaptureVideoProfile 物件公開配置檔。 藉由提供特定的裝置標識碼，可透過 MediaCapture 處理站探索此物件。 此裝置中心檢視表示想要啟用特定案例的應用程式必須先列舉/尋找所選裝置，並使用該裝置逐一查看可用的配置檔。
數位相機配置檔 V2 會擴充 API 介面以繼續提供以裝置為中心的 API 介面，但除了此介面之外，相機配置檔 V2 也會提供案例驅動配置檔列舉。
應用程式會從特定案例開始，而不是從特定相機開始。 例如，使用世界面向相機案例的視訊錄製。
此進入點提供適用於該案例的所有可用相機應用程式。 根據案例的特定性，產生的 MediaFrameSourceGroup 清單可能包含多個專案。 在某些情況下，可能沒有任何專案。 例如，針對沒有世界對向相機的 All-In-One 裝置，使用世界面向相機的視訊錄製會傳回空的集合。
用來描述案例的「語言」允許根據最低準則進行後援。 這是語言，允許「視訊錄製具有世界面向相機的喜好設定，以及可能的解析度下限為 30 fps」。
配置檔型篩選
使用 Frame Server 架構的主要優點之一是，Frame Server 上的 Client Context 對像是用戶端應用程式上媒體擷取對象的虛擬表示法，與實體來源分離。
這可讓多個用戶端內容對象的實例使用相同的來源 () 在特定作業模式中設定，其中包括篩選可能會與基礎使用案例衝突的針腳/媒體類型。
由於裝置來源不是用戶端內容的一部分，因此建立具有不同組態之用戶端內容物件的多個實例，並不會產生任何重大額外負荷 (只要追蹤內部數據結構) 所需的額外負荷。
建立/初始化來源的延遲仍然存在於第一個用戶端內容，但一旦建立之後，具有相同組態或不同組態的後續實例只會產生建立內部數據結構的額外負荷。
下圖顯示以 Null 設定檔設定的媒體擷取如何透過用戶端內容由 Frame Server 公開：
在上圖中，每個來源都會公開三個釘選：預覽、擷取和相片。 由於已設定 Null 配置檔，因此產生的媒體擷取會將所有九個針腳公開至應用程式。 應用程式可以檢查每個針腳，以及每個釘選上可用的每個媒體類型。
雖然這可為應用程式提供彈性，但它也會複合管理狀態機器的複雜度，以決定可以同時啟用哪種媒體類型/針腳的組合。
不過，藉由利用配置檔型篩選：
應用程式可以建立多個媒體擷取實例，每個實例都設定了特定配置檔。 在上圖中，Null 配置文件實例會保留為圖例，應用程式可以選擇不要建立 Null 配置文件實例。
較低的媒體擷取物件都是使用特定配置檔來設定。 根據來源 IHV/OEM 所發佈的配置檔資訊，產生的管線只會提取所需的來源。
針對 HQ 相片世界面向配置檔，只會公開世界面向 RGB (Source 3 的預覽和相片釘選，) 只會公開 IHV/OEM 指出的媒體類型適用於相片作業。 這假設 IHV/OEM 指出 HQ 相片無法同時擷取。 如果允許同時擷取，則會公開擷取釘選以及可用於同時相片和錄製作業的媒體類型。
針對錄製使用者面向，只會公開使用者面向 RGB (來源 1) 的預覽和擷取釘選。 同樣地，上圖假設擷取釘選作用中時無法執行相片作業。
針對 Mixed Reality 配置檔，世界面向 RGB 和世界面向感知視訊串流會公開給用戶端應用程式。 同樣地，只有保證同時運作的媒體類型可供使用。