Treiberunterstützung für Kameraausrichtung

Da verschiedene Formfaktoren für Computer eingeführt werden, führen einige der physischen Einschränkungen dazu, dass Kamerasensoren in einer nicht herkömmlichen Ausrichtung montiert werden. Aus diesem Grund ist es notwendig, das Betriebssystem und die Anwendung ordnungsgemäß zu beschreiben, wie die Sensoren montiert werden, damit das resultierende Video ordnungsgemäß gerendert/aufgezeichnet werden kann.

Ab Windows 10, Version 1607, sind alle Kameratreiber erforderlich, um die Kameraausrichtung explizit anzugeben, unabhängig davon, ob die Kamera gemäß den Mindesthardwareanforderungen montiert ist. Insbesondere muss ein Kameratreiber ein neu eingeführtes Feld , Drehung, in der ACPI-_PLD Struktur festlegen, die einer Aufnahmegeräteschnittstelle zugeordnet ist:

typedef struct _ACPI_PLD_V2_BUFFER {

    UINT32 Revision:7;
    UINT32 IgnoreColor:1;
    UINT32 Color:24;
    // …
    UINT32 Panel:3;         // Already supported by camera.
    // …
    UINT32 CardCageNumber:8;
    UINT32 Reference:1;
    UINT32 Rotation:4;      // 0 – Rotate by 0° clockwise
                            // 1 – Rotate by 45° clockwise (N/A to camera)
                            // 2 – Rotate by 90° clockwise
                            // 3 – Rotate by 135° clockwise (N/A to camera)
                            // 4 – Rotate by 180° clockwise
                            // 5 – Rotate by 225° clockwise (N/A to camera)
                            // 6 – Rotate by 270° clockwise
    UINT32 Order:5;
    UINT32 Reserved:4;

    //
    // _PLD v2 definition fields.
    //

    USHORT VerticalOffset;
    USHORT HorizontalOffset;
} ACPI_PLD_V2_BUFFER, *PACPI_PLD_V2_BUFFER;

Für die Kamera gibt das Drehfeld in einer ACPI-_PLD-Struktur an, um wie viele Grad ('0' für 0°, '2' für 90°, '4' für 180° und '6' für 270°) ein aufgenommenes Bild relativ zum Bildschirm gedreht wird, während dieser in seiner nativen Ausrichtung ist.

Basierend auf dem Wert im Drehungsfeld kann eine Anwendung bei Bedarf zusätzliche Drehung durchführen, um erfasste Frames korrekt zu rendern.

Drehungswerte

Für Geräte, deren Kameras und Displays das gleiche Gehäuse (oder Gehäusegehäuse/) aufweisen, ist es möglich, dass diese Peripheriegeräte auf unterschiedlichen Oberflächen montiert werden, wobei jeder von ihnen durch einen festen, aber willkürlichen Grad auf seiner jeweiligen Ebene gedreht wird. Folglich benötigt eine Anwendung einen Mechanismus, um die räumliche Beziehung zwischen den beiden Peripheriegeräten zu beschreiben, sodass ein erfasster Frame in die Renderingoberfläche in der richtigen Ausrichtung transponiert werden kann.

Eine Möglichkeit, das Problem zu lösen, besteht darin, die ACPI-_PLD Struktur zu verwenden, die bereits die Konzepte der Oberfläche und grad der Drehung definiert hat. Beispielsweise verfügt die _PLD Struktur bereits über ein Panelfeld , das die Oberfläche angibt, auf der sich ein Peripheriegerät befindet:

Definition des ACPI-_PLD-Panel-Felds (Rev. 5.0a)

Die nächsten beiden Diagramme veranschaulichen die Definition der einzelnen Panels visuell:

Paneldefinitionen für Desktop-PCs und die meisten Geräte

Paneldefinitionen für faltbare Geräte

In der Tat wird das Konzept eines ACPI-"Panels" bereits von Windows angenommen, in dem:

• Eine Kamerageräteschnittstelle ist einer _PLD Struktur zugeordnet, bei der das Feld "Panel" entsprechend festgelegt wird, wenn ein Aufnahmegerät an einer festen Position statisch montiert wird.

• Eine Anwendung kann den Bereich abrufen, auf dem sich ein Aufnahmegerät befindet, indem die Windows.Devices.Enumeration.DeviceInformation.EnclosureLocation.Panel-Eigenschaft aufgerufen wird.

Die ACPI-_PLD-Struktur weist außerdem ein Wie folgt definiertes Rotationsfeld auf:

Definition des ACPI-_PLD Rotationsfelds (Rev 5.0a)

Anstatt die oben genannte Definition zu verwenden, verfeinern wir sie weiter, um Mehrdeutigkeit zu vermeiden:

• Für die Kamera gibt das Drehfeld in einer ACPI-_PLD Struktur die Anzahl von Grad ('0' für 0°, '2' für 90°, '4' für 180° und '6' für 270°) an, um die ein aufgenommenes Bild relativ zum Bildschirm gedreht wird, während die Anzeige in ihrer nativen Ausrichtung bleibt.

Querformat Primär vs Hochformat Primär

In Windows kann man die native Anzeigeausrichtung abfragen, indem die Eigenschaft Windows.Graphics.Display.DisplayInformation.NativeOrientation aufgerufen wird, die entweder Querformat oder Hochformat zurückgibt:

Unabhängig davon, welcher Wert NativeOrientation zurückgegeben wird, beginnt das logische Anzeigescanmuster von der oberen linken Ecke der Anzeige, die von links nach rechts nach unten bewegt wird (siehe Abbildung 5). Für Geräte, deren physische Standardausrichtung unerklärlich ist, impliziert diese Eigenschaft nicht nur die Position eines ACPI Top-Panels , sondern stellt auch die räumliche Beziehung zwischen einem Kameraausgabepuffer und der Renderingoberfläche bereit.

Beachten Sie, dass die NativeOrientation-Eigenschaft im Gegensatz zur Kamera nicht auf ACPI basiert und somit keine _PLD Struktur aufweist. Dies gilt auch dann, wenn eine Anzeige statisch an ein Gerät montiert wird.

Bei der Montage auf einem Primären Hochformat-Gerät müssen Kameratreiber beachten, dass die meisten Anwendungen das Gerät als Ausgabe eines Querformat-Kameraausgabepuffers behandeln, unabhängig von der tatsächlichen Ausrichtung des Kameraausgabepuffers. Aus diesem Grund empfehlen wir, dass Kameratreiber einen Kamerapuffer ausgeben, der um 90 Grad vom NativeOrientation Portrait abweicht, wenn das primäre Gerät ein Hochformat ist. Dadurch können Anwendungen, die diese zusätzliche Drehung auf Hochformatgeräten durchführen, die Drehung auf die erwartete Ausrichtung korrigieren. Dies kann mithilfe der Kameraanwendung mit Drehungsbeispiel überprüft werden.

Versatzmontage

IHV/OEMs wird dringend empfohlen, auf die Montage des Sensors in einem anderen als einem 0-Grad-Offset zu verzichten, um die Kompatibilität mit Anwendungen sicherzustellen. Viele vorhandene und ältere Apps sind nicht in der Lage, die PLD-Tabelle der ACPI zu berücksichtigen, noch werden sie versuchen, den Offset von Nicht-0 Grad zu korrigieren. Folglich wird für solche Apps das resultierende Video falsch gerendert.

In Fällen, in denen IHV/OEMs den Sensor nicht in der 0-Grad-Ausrichtung montieren können, wie oben beschrieben, werden die folgenden Abhilfemaßnahmen in der Reihenfolge der Präferenz empfohlen:

1. Automatische Korrektur einer nicht-0-Grad-Ausrichtung innerhalb des Kameratreibers (entweder im Kernelmodus mit dem AV-Stream-Miniport-Treiber oder im Benutzermodus mit einem Plug-in wie Device MFT oder MFT0), sodass die resultierenden Ausgangs-Frames in der 0-Grad-Ausrichtung sind.

2. Deklarieren Sie die Ausrichtung, die nicht 0 Grad beträgt, über das FSSensorOrientation-Tag, damit die Kamerapipeline das aufgenommene Bild korrigieren kann.

3. Deklarieren Sie die Ausrichtung ungleich 0 Grad in der PLD-Tabelle der ACPI wie oben beschrieben.

Komprimierte/codierte Medientypen

Für komprimierte und/oder codierte Medientypen (z. B. MJPG, JPEG, H264, HEVC) kann keine Pipelinekorrektur verwendet werden. Aus diesem Grund werden komprimierte/codierte Medientypen herausgefiltert, wenn die FSSensorOrientation auf einen Wert ungleich Null festgelegt ist.

Bei MJPG-Medientypen (z. B. von einer UVC-Kamera) stellt die Frame Server-Pipeline einen automatisch decodierten Medientyp (NV12 oder YUY2 für DShow-basierte Anwendungen) bereit. Der automatisch decodierte und korrigierte Medientyp wird präsentiert, das ursprüngliche MJPG-Format wird jedoch nicht angezeigt.

[! HINWEIS!] Wenn komprimierte/codierte Medientypen für Anwendungen verfügbar gemacht werden müssen, darf IHV/ODMs die FSSensorOrientation-Korrektur nicht verwenden. Stattdessen muss die Korrektur durch den Kameratreiber erfolgen (entweder im Kernelmodus über den AV Stream-Treiber oder im Benutzermodus über DMFT/MFT0).

Autokorrektur über AV Stream Miniport/Gerät MFT/MFT0

Das empfohlene Szenario, wenn die Sensoren nicht mit einem Offset von 0 Grad montiert werden können, besteht darin, dass der AV Stream-Miniporttreiber (oder der Benutzermodus-Plug-Ins in Form von DMFT oder MFT0) den resultierenden erfassten Frame korrigieren, sodass er der Pipeline in einem Offset von 0 Grad verfügbar gemacht wird.

Beim Korrigieren des Videoframes aus dem AV Stream Miniport und/oder dem Device MFT/MFT0-Plug-In muss die resultierende Medientypdeklaration auf dem korrigierten Frame basieren. Wenn der Sensor mit einem Offset von 90 Grad montiert wird, sodass das resultierende Video 9:16 Seitenverhältnis vom Sensor ist, das korrigierte Video jedoch 16:9 ist, muss der Medientyp das Seitenverhältnis von 16:9 deklarieren.

Dazu gehören die erhaltenen Stride-Informationen. Dies ist erforderlich, da die für die Korrektur zuständige Komponente von der IHV/OEM gesteuert wird und die Kamerapipeline keine Sichtbarkeit in den Videoframe hat, es sei denn, sie wurde korrigiert.

Es wird dringend empfohlen, dass die Korrektur im Benutzermodus durchgeführt wird und der API-Vertrag zwischen der Pipeline und dem Benutzermodus-Plug-In befolgt werden muss. Insbesondere bei der Verwendung von DMFT oder MFT0, wenn IMFDeviceTransform::ProcessMessage oder IMFTransform::ProcessMessage mit einer MFT_MESSAGE_SET_D3D_MANAGER Nachricht aufgerufen wird, muss das Benutzermodus-Plugin die folgende Richtlinie einhalten:

• Wenn kein D3D-Manager bereitgestellt wird (die ulParam der Nachricht ist 0), darf das Plug-In für den Benutzermodus KEINE GPU-Vorgänge aufrufen, um die Drehungskorrektur zu verarbeiten. Und der resultierende Frame muss im Systemspeicher bereitgestellt werden.
• Wenn ein D3D-Manager bereitgestellt wird (das ulParam der Nachricht ist die IUnknown eines DXGI-Managers), muss dieser DXGI-Manager für die Drehkorrektur verwendet werden, und der resultierende Frame muss sich im GPU-Speicher befinden.
• Das Benutzermodus-Plug-In muss auch die D3D-Manager-Nachricht während der Laufzeit behandeln. Wenn die MFT_MESSAGE_SET_D3D_MANAGER Nachricht ausgegeben wird, muss der nächste frame, der vom Plug-In erzeugt wird, dem angeforderten Speichertyp entsprechen (d. h. GPU, wenn DXGI-Manager bereitgestellt wurde, CPU andernfalls).
• Wenn der AV Stream-Treiber (oder das Benutzermodus-Plug-In) die Drehungskorrektur verarbeitet, muss das PLD-Strukturfeld der ACPI auf 0 festgelegt sein.

Deklarieren über FSSensorOrientation

; Defines the sensor mounting orientation offset angle in
; degrees clockwise.
FSSensorOrientation: REG_DWORD: 90, 180, 270

Durch Deklarieren der Nicht-0-Grad-Ausrichtung des Sensors über das FSSensorOrientation-Registrierungstag kann die Kamerapipeline den aufgenommenen Frame korrigieren, bevor er der Anwendung präsentiert wird.

Die Pipeline wird die Rotationslogik optimieren, indem sie GPU- oder CPU-Ressourcen je nach Anwendungsfall und spezifischer App-Anfrage oder Szenario nutzt.

ACPI PLD-Drehung

Das Rotationsfeld der ACPI PLD-Struktur muss 0 sein. Dies ist die Vermeidung verwirrender Anwendungen, die die PLD-Informationen verwenden können, um den Frame zu korrigieren.

Medientypinformationen

Der vom Treiber angezeigte Medientyp muss der nicht korrigierte Medientyp sein. Wenn Sie die Kamerapipeline über den Nicht-0-Grad-Offset mithilfe des FSSensorOrientation-Eintrags informieren, müssen die vom Sensor dargestellten Medientypinformationen der nicht korrigierte Medientyp sein. Wenn der Sensor beispielsweise um 90 Grad im Uhrzeigersinn versetzt montiert ist, wird anstelle des Seitenverhältnisses 16:9 das resultierende Video im Format 9:16 dargestellt. Der Medientyp mit dem Seitenverhältnis 9:16 muss daher der Kamerapipeline übergeben werden.

Dies ist erforderlich, um sicherzustellen, dass die Pipeline den Gegendrehungsprozess ordnungsgemäß konfigurieren kann: Die Pipeline benötigt den Eingabemedientyp und den gewünschten Ausgabemedientyp der Anwendung.

Dazu gehören die Stride-Informationen. Die Strideinformation für den nicht korrigierten Medientyp muss der Kamerapipeline präsentiert werden.

Registrierungsunterschlüssel

Der FSSensorOrientation-Registrierungseintrag muss auf dem Knoten "Device Interface" veröffentlicht werden. Der empfohlene Ansatz besteht darin, dies im Kameratreiber-INF während der Deklaration der AddInterface-Direktive als AddReg-Direktive zu deklarieren.

Die in der FSSensorOrientation dargestellten Daten müssen eine REG_DWORD sein, und die zulässigen Werte sind 90, 180 und 270. Jeder andere Wert wird als Offset von 0 Grad behandelt (d. h. ignoriert).

Jeder Wert stellt die Sensorausrichtung im Uhrzeigersinn dar. Die Kamerapipeline korrigiert den resultierenden Videoframe, indem das Video um den gleichen Gegenwert gegen den Uhrzeigersinn gedreht wird: Eine 90-Grad-Deklaration im Uhrzeigersinn führt zu einer Drehung von 90 Grad gegen den Uhrzeigersinn, um den resultierenden Videoframe wieder auf 0 Grad Offset zu bringen.

MS OS Descriptor 1.0

Für USB-basierte Kameras kann FSSensorOrientation auch über MSOS-Deskriptoren veröffentlicht werden.

MS OS Descriptor 1.0 verfügt über zwei Komponenten:

• Ein Kopfzeilenabschnitt mit fester Länge
• Ein oder mehrere benutzerdefinierte Eigenschaftenabschnitte mit variabler Länge, die dem Kopfzeilenabschnitt folgen

MS OS DESCRIPTOR 1.0 Header Section

Der Kopfzeilenabschnitt beschreibt eine einzelne benutzerdefinierte Eigenschaft (Face Auth Profile).

Abschnitt Custom MS OS DESCRIPTOR 1.0 Eigenschaftenabschnitt

MS OS Descriptor 2.0

MSOS Extended Descriptor 2.0 kann verwendet werden, um die Registrierungswerte zu definieren, um FSSensorOrientation-Unterstützung hinzuzufügen. Dies erfolgt mithilfe des Microsoft OS 2.0 Registry-Deskriptors.

Für den Registrierungseintrag UVC-FSSensorOrientation zeigt Folgendes einen MSOS 2.0-Beispieldeskriptorsatz:

UCHAR Example2_MSOS20DescriptorSet_UVCFSSensorOrientationForFutureWindows[0x3C] =
{
    //
    // Microsoft OS 2.0 Descriptor Set Header
    //
    0x0A, 0x00,                 // wLength - 10 bytes
    0x00, 0x00,                 // MSOS20_SET_HEADER_DESCRIPTOR
    0x00, 0x00, 0x0?, 0x06,     // dwWindowsVersion – 0x060?0000 for future Windows version
    0x4A, 0x00,                 // wTotalLength – 74 bytes

    //
    // Microsoft OS 2.0 Registry Value Feature Descriptor
    //
    0x40, 0x00,                 // wLength - 64 bytes
    0x04, 0x00,                 // wDescriptorType – 4 for Registry Property
    0x04, 0x00,                 // wPropertyDataType - 4 for REG_DWORD_LITTLE_ENDIAN
    0x32, 0x00,                 // wPropertyNameLength – 50 bytes
    0x55, 0x00, 0x56, 0x00,     // Property Name - "UVC-FSSensorOrientation"
    0x43, 0x00, 0x2D, 0x00,
    0x46, 0x00, 0x53, 0x00,
    0x53, 0x00, 0x65, 0x00,
    0x6E, 0x00, 0x73, 0x00,
    0x6F, 0x00, 0x72, 0x00,
    0x4F, 0x00, 0x72, 0x00,
    0x69, 0x00, 0x65, 0x00,
    0x6E, 0x00, 0x74, 0x00,
    0x61, 0x00, 0x74, 0x00,
    0x69, 0x00, 0x6F, 0x00,
    0x6E, 0x00, 0x00, 0x00,
    0x00, 0x00,
    0x04, 0x00,                 // wPropertyDataLength – 4 bytes
    0x5A, 0x00, 0x00, 0x00      // PropertyData – 0x0000005A (90 degrees offset)
}

Deklaration mithilfe von ACPI PLD-Informationen

Als Option der letzten Möglichkeit können PLD-Informationen wie oben beschrieben genutzt werden, um der Anwendung mitzuteilen, dass der Videoframe korrigiert werden muss, bevor er gerendert/codiert wird. Wie bereits erwähnt, verwenden viele vorhandene Anwendungen jedoch weder die PLD-Informationen noch behandeln die Framedrehung. Daher gibt es Szenarien, in denen Apps das resultierende Video möglicherweise nicht ordnungsgemäß rendern können.

Die folgenden Abbildungen veranschaulichen die Werte des _PLD Rotationsfelds für jede Hardwarekonfiguration:

Drehung: 0 Grad im Uhrzeigersinn

In der abbildung oben:

• Das Bild auf der linken Seite veranschaulicht die zu erfassende Szene.

• Das Bild in der Mitte zeigt, wie eine Szene von einem CMOS-Sensor erfasst wird, dessen physische Lesereihenfolge in der unteren linken Ecke beginnt und sich von links nach rechts nach oben bewegt.

• Das Bild rechts stellt die Ausgabe des Kameratreibers dar. In diesem Beispiel kann der Inhalt des Medienpuffers direkt gerendert werden, während die Anzeige die systemeigene Ausrichtung ohne zusätzliche Drehung aufweist. Folglich weist das ACPI _PLD Rotationsfeld den Wert 0 auf.

Drehung: 90 Grad im Uhrzeigersinn

In diesem Fall wird der Inhalt des Medienpuffers im Vergleich zur ursprünglichen Szene um 90 Grad im Uhrzeigersinn gedreht. Daher weist das ACPI-_PLD Rotationsfeld den Wert 2 auf.

Drehung: 180 Grad im Uhrzeigersinn

In diesem Fall wird der Inhalt des Medienpuffers im Vergleich zur ursprünglichen Szene um 180 Grad im Uhrzeigersinn gedreht. Daher weist das ACPI-_PLD Rotationsfeld den Wert 4 auf.

Drehung: 270 Grad im Uhrzeigersinn

In diesem Fall wird der Inhalt des Medienpuffers im Vergleich zur ursprünglichen Szene um 270 Grad im Uhrzeigersinn gedreht. Daher weist das ACPI-_PLD Rotationsfeld den Wert 6 auf.