Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die Verwendung von Kameraprofilen 1507 für ISV stellte aufgrund der komplexen Darstellung der Profile und der Tatsache, dass Profile lediglich informative Datensätze waren, eine erhebliche Herausforderung dar. Die zugrunde liegende Pipeline würde dennoch Kombinationen von Medientypen und Datenströmen ermöglichen, die gegen die Hardware-Beschränkungen verstoßen.
ISVs gingen weiterhin das Risiko ein, die Aufnahmepipeline so zu konfigurieren, dass beim Starten der Datenströme ein Fehler auftritt.
Für Kameraprofil V2 wird die Konfiguration eines ausgewählten Profils zur Initialisierungszeit des Medienaufnahmeobjekts an den Frameserver kommuniziert, und der Frameserver macht nur Kombinationen aus Datenströmen/Medientypen verfügbar, die innerhalb dieses Profils gültig sind.
Aufgrund der niedrigen Kosten für das Erstellen mehrerer Medienaufnahmeobjekte, die über den Frameserver geleitet werden, kann eine Anwendung mehrere Instanzen von Medienaufnahmeobjekten mit derselben Quelle erstellen. Nur die erste erstellte würde eine Quellerstellungslatenz verursachen. Nachfolgende Instanzen verwenden einfach die bereits erstellte Quelle auf dem Frame-Server und filtern den Satz von Streams/Medientypen basierend auf dem Profil.
Eine Anwendung, die sowohl einen Fotomodus mit hoher Qualität als auch einen Videoaufzeichnungsmodus verfügbar machen möchte, der entweder Video mit hoher Bildfrequenz oder 4K-Video enthält, könnte mehrere Instanzen von Medienaufnahmeobjekten erstellen, die jeweils mit einem anderen Profil für dieselbe Kameraquelle konfiguriert sind. Solange zu einem bestimmten Zeitpunkt nur eines der Medienaufnahmeobjekte aktiv gestreamt wird, verursacht der Wechsel zwischen dem Medienaufnahmeobjekt wenig Latenz (in der Regel die Kosten einiger RPC-Aufrufe).
Kameraprofil 1507 macht Profile über das MediaCaptureVideoProfile -Objekt verfügbar. Dieses Objekt wird über die MediaCapture-Factory ermittelt, indem eine bestimmte Geräte-ID bereitgestellt wird. Diese geräteorientierte Ansicht bedeutet, dass eine App, die ein bestimmtes Szenario aktivieren möchte, zuerst das gewünschte Gerät aufzählen/suchen und zum Durchlaufen der verfügbaren Profile verwenden muss.
Kameraprofil V2 erweitert die API-Oberfläche, um weiterhin eine gerätezentrierte API-Oberfläche bereitzustellen, aber zusätzlich dazu stellt Kameraprofil V2 auch eine szenariogesteuerte Profilaufzählung bereit.
Anstatt mit einer bestimmten Kamera zu beginnen, beginnt eine Anwendung mit einem bestimmten Szenario. Beispiel: Videoaufzeichnung in einem Szenario mit einer nach außen gerichteten Kamera.
Dieser Einstiegspunkt stellt die Anwendung aller verfügbaren Kameras bereit, 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 es keine Einträge gibt. Beispielsweise würde die Videoaufzeichnung mit der World Facing Camera für ein All-In-One-Gerät, das nicht über eine weltgerichtete Kamera verfügt, einen leeren Satz zurückgeben.
Die "Sprache", die zum Beschreiben des Szenarios verwendet wird, ermöglicht Fallbacks basierend auf Mindestkriterien. Dies ist die Sprache für "Videoaufzeichnung mit einer Einstellung für die nach vorne gerichtete Kamera und die höchstmögliche Auflösung bei einer minimalen Bildfrequenz 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 Medienaufnahmeobjekts in der Client-App handelt, von der physischen Quelle entkoppelt wird.
Auf diese Weise können mehrere Instanzen von Clientkontextobjekten mit derselben Quelle(n) in bestimmten Betriebsmodi konfiguriert werden, was das Filtern von Pins/Medientypen umfassen kann, 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 Aufwand (ebenso viel Aufwand zum Nachverfolgen der internen Datenstrukturen).
Die Latenz für das Erstellen/Initialisieren einer Quelle ist weiterhin für den ersten Client-Kontext vorhanden, aber nach der Erstellung verursachen nachfolgende Instanzen mit derselben oder einer anderen Konfiguration nur den zusätzlichen Aufwand für das Erstellen der internen Datenstrukturen.
Das folgende Diagramm zeigt, wie eine mit NULL-Profil konfigurierte Medienaufnahme von Frame Server über den Clientkontext verfügbar gemacht wird:
Im obigen Diagramm stellen alle Quellen drei Pins zur Verfügung: Vorschau, Aufnahme und Foto. Und da ein Nullprofil festgelegt wurde, werden bei der resultierenden Medienerfassung alle neun Pins für die Anwendung freigelegt. Die Anwendung kann jeden Pin und jeden Medientyp untersuchen, der auf jedem Pin verfügbar ist.
Dies bietet zwar Flexibilität für die App, erhöht aber auch die Komplexität der Verwaltung der Statusmaschine, die festlegt, welche Kombinationen von Medientypen/Pins gleichzeitig aktiviert werden können.
Verwenden Sie jedoch die profilbasierte Filterung:
Die Anwendung kann mehrere Instanzen der Medienaufnahme erstellen, die jeweils mit einem bestimmten Profil konfiguriert sind. Im obigen Diagramm verbleibt die NULL-Profilinstanz als Abbildung, die Anwendung kann auswählen, dass die NULL-Profilinstanz nicht erstellt werden soll.
Die unteren Medienaufnahmeobjekte sind jeweils mit einem bestimmten Profil konfiguriert. Basierend auf den Profilinformationen, die vom IHV/OEM der Quellen veröffentlicht werden, ruft die resultierende Pipeline nur die benötigten Quellen ab.
Für das HQ Photo World Facing-Profil würden nur die Vorschau- und Foto-Pins des World Facing RGB (Source 3) sowie nur die Medientypen verfügbar gemacht, die vom IHV/OEM für die Fotovorgänge als kompatibel angegeben wurden. Dabei wird davon ausgegangen, dass der IHV/OEM darauf hingewiesen hat, dass bei HQ-Fotos die gleichzeitige Aufnahme nicht möglich ist. Wenn eine gleichzeitige Aufnahme zulässig ist, werden der Capture-Pin und die Medientypen, die für gleichzeitige Foto- und Videoaufnahmen verwendet werden können, freigegeben.
Für den aufnahmebenutzergerichteten Benutzer würden nur die Pins „Vorschau“ und „Aufnahme“ des Benutzer-Facing RGB (Quelle 1) freigelegt. Auch hier wird davon ausgegangen, dass Fotovorgänge nicht möglich sind, wenn die Aufnahmenadel aktiv ist.
Für das Mixed Reality-Profil würden die Videostreams "World Facing RGB" und "World Facing Perception" für die Client-App verfügbar gemacht. Und wieder werden nur die Medientypen, die garantiert funktionieren, gleichzeitig zur Verfügung gestellt.