Detaillierter Entwurf für ISVs (Kameraprofil V2)
Der Verbrauch von Kameraprofilen 1507 für ISV stellte eine erhebliche Herausforderung dar, da die Darstellung von Profilen komplex ist und die Tatsache, dass Profile lediglich ein informatives Dataset waren, die zugrunde liegende Pipeline weiterhin Kombinationen von Medientypen und Streams zulassen würde, die die Hardwareeinschränkungen verletzten.
ISVs liefen weiterhin Gefahr, die Erfassungspipeline so zu konfigurieren, dass bei der Aktivierung von Streams ein Fehler auftritt.
Für Kameraprofil V2 wird die Konfiguration eines ausgewählten Profils zum Initialisierungszeitpunkt des Media Capture-Objekts an den Frameserver übermittelt, und der Frameserver macht nur Kombinationen von Streams/Medientypen verfügbar, die innerhalb dieses Profils gültig sind.
Aufgrund der niedrigen Kosten für die Erstellung mehrerer Media Capture-Objekte beim Routing über den Frame Server kann eine Anwendung mehrere Instanzen von Media Capture-Objekten mit derselben Quelle vorstellen. Nur bei der ersten Erstellung würde eine Latenz für die Quellerstellung auftreten. Nachfolgende Instanzen verwenden einfach die bereits erstellte Quelle auf dem Frameserver und filtern den Satz von Streams/Medientypen basierend auf dem Profil.
Eine Anwendung, die sowohl einen Fotomodus für hohe Qualität als auch einen Videoaufzeichnungsmodus verfügbar machen möchte, der entweder Video mit hoher Bildfrequenz oder 4K-Video enthält, kann mehrere Instanzen von Media Capture-Objekten erstellen, die jeweils mit einem anderen Profil für dieselbe Kameraquelle konfiguriert sind. Solange nur eines der Media Capture-Objekte zu einem bestimmten Zeitpunkt aktiv gestreamt wird, verursacht der Wechsel zwischen dem Media Capture-Objekt eine geringe Latenz (in der Regel die Kosten einiger RPC-Aufrufe).
Kameraprofil 1507 macht Profile über das MediaCaptureVideoProfile-Objekt verfügbar. Dieses Objekt wird durch die MediaCapture-Factory ermittelt, indem eine bestimmte Geräte-ID angegeben wird. Diese geräteorientierte Ansicht bedeutet, dass eine App, die ein bestimmtes Szenario aktivieren möchte, zuerst das gerät der Wahl auflisten/finden und dieses verwenden muss, um die verfügbaren Profile zu durchlaufen.
Kameraprofil V2 erweitert die API-Oberfläche, um weiterhin eine gerätezentrierte API-Oberfläche bereitzustellen, aber darüber hinaus bietet Kameraprofil V2 auch eine szenariogesteuerte Profilaufzählung.
Anstatt mit einer bestimmten Kamera zu beginnen, beginnt eine Anwendung mit einem bestimmten Szenario. Beispiel: Videoaufzeichnung mithilfe eines Weltkameraszenarios.
Dieser Einstiegspunkt bietet die Anwendung aller verfügbaren Kameras, die für dieses Szenario geeignet sind. Je nach Spezifität des Szenarios kann die resultierende MediaFrameSourceGroup-Liste mehrere Einträge enthalten. In einigen Fällen ist es möglich, dass keine Einträge vorhanden sind. Die Videoaufzeichnung mit der Weltkamera für ein All-In-One-Gerät ohne Weltkamera würde beispielsweise eine leere Gruppe zurückgeben.
Die "Sprache", die zur Beschreibung des Szenarios verwendet wird, ermöglicht Fallbacks basierend auf Mindestkriterien. Dies ist die Sprache ermöglicht für "Videoaufzeichnung mit einer Vorliebe für Weltkamera und höchste Auflösung möglich mit einer Mindestbildrate von 30 fps".
Profilbasierte Filterung
Einer der hauptvorteile der Verwendung der Frame Server-Architektur ist die Tatsache, dass das Clientkontextobjekt auf dem Frame Server, bei dem es sich um eine virtuelle Darstellung eines Media Capture-Objekts in der Client-App handelt, von der physischen Quelle entkoppelt ist.
Dadurch können mehrere Instanzen von Clientkontextobjekten, die dieselbe Quelle(en) verwenden, in bestimmten Betriebsmodi konfiguriert werden. Dies kann auch die Filterung von Pins/Medientypen umfassen, die mit dem zugrunde liegenden Anwendungsfall in Konflikt stehen können.
Da die Gerätequellen nicht Teil des Clientkontexts sind, verursacht das Erstellen mehrerer Instanzen von Clientkontextobjekten mit unterschiedlicher Konfiguration keinen erheblichen Mehraufwand (ebenso viel Aufwand, der zum Nachverfolgen der internen Datenstrukturen erforderlich ist).
Die Wartezeit für das Erstellen/Initialisieren einer Quelle ist für den ersten Clientkontext noch vorhanden, aber nach der Erstellung verursachen nachfolgende Instanzen mit der gleichen Konfiguration oder einer anderen Konfiguration nur den zusätzlichen Mehraufwand beim Erstellen der internen Datenstrukturen.
Das folgende Diagramm zeigt, wie ein mit NULL-Profil konfigurierter Medienerfassung vom Frame Server über den Clientkontext verfügbar gemacht wird:
Im obigen Diagramm macht jede der Quellen drei Pins verfügbar: Vorschau, Aufnahme und Foto. Da ein NULL-Profil festgelegt wurde, macht die resultierende Medienerfassung alle neun Pins für die Anwendung verfügbar. Die Anwendung kann jeden Pin und jeden Medientyp untersuchen, der an jedem Pin verfügbar ist.
Dies bietet zwar Flexibilität für die App, erhöht aber auch die Komplexität der Verwaltung des Zustandscomputers, um zu bestimmen, welche Kombination von Medientypen/Pins gleichzeitig aktiviert werden kann.
Verwenden Sie jedoch die profilbasierte Filterung:
Die Anwendung kann mehrere Instanzen von Media Capture erstellen, die jeweils mit einem bestimmten Profil konfiguriert sind. Im obigen Diagramm wird das NULL-Profil instance als Abbildung belassen. Die Anwendung kann auswählen, dass das NULL-Profil nicht instance erstellt wird.
Die unteren Media Capture-Objekte sind jeweils mit einem bestimmten Profil konfiguriert. Basierend auf den Profilinformationen, die vom IHV/OEM der Quellen veröffentlicht werden, wird die resultierende Pipeline nur die benötigten Quellen abrufen.
Für das HQ Photo World Facing-Profil würden nur die Vorschau- und Fotopins der World Facing RGB (Quelle 3) verfügbar gemacht, und nur die Medientypen, die der IHV/OEM angegeben hat, funktionieren für die Fotovorgänge. Dies setzt voraus, dass der IHV/OEM angegeben hat, dass für HQ Photo die gleichzeitige Erfassung nicht möglich ist. Wenn die gleichzeitige Aufnahme zulässig ist, werden der Capture-Pin zusammen mit den Medientypen, die für gleichzeitige Foto- und Aufzeichnungsvorgänge verwendet werden können, verfügbar gemacht.
Für die Aufzeichnung benutzerseitig werden nur die Vorschau- und Erfassungspins des benutzerseitigen RGB (Quelle 1) verfügbar gemacht. Auch im obigen Diagramm wird davon ausgegangen, dass Fotovorgänge nicht möglich sind, wenn der Aufnahmepin aktiv ist.
Für das Mixed Reality-Profils würden die Videostreams World Facing RGB und World Facing Perception der Client-App verfügbar gemacht. Und auch hier werden nur die Medientypen zur Verfügung gestellt, die garantiert gleichzeitig funktionieren.