Prise en charge du pilote pour l’orientation de la caméra

À mesure que de nouveaux facteurs de forme pour les appareils informatiques sont introduits, certaines contraintes physiques font que les capteurs de caméra peuvent être montés dans une orientation non traditionnelle. En raison de cela, il est nécessaire de décrire correctement le système d’exploitation et l’application, comment les capteurs sont montés afin que la vidéo résultante puisse être rendue/enregistrée correctement.

À partir de Windows 10, version 1607, tous les pilotes de caméra sont tenus de spécifier explicitement l’orientation de la caméra, que la caméra soit montée conformément à la configuration matérielle minimale requise. Plus précisément, un pilote de caméra doit définir un champ nouvellement introduit, rotation, dans la structure d'_PLD ACPI associée à une interface de périphérique de capture :

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;

Pour la caméra, le champ rotation d’une structure ACPI _PLD spécifie le nombre de degrés ('0' pour 0°, '2' pour 90°, '4' pour 180° et '6' pour 270°) qu’un cadre capturé est pivoté par rapport à l’écran pendant que l’affichage est dans son orientation native.

En fonction de la valeur du champ Rotation , une application peut effectuer une rotation supplémentaire, si nécessaire, afin d’afficher correctement les images capturées.

Valeurs de rotation

Pour les appareils dont les caméras et les affichages partagent le même boîtier (ou lacasse du boîtier/), il est possible que ces périphériques soient montés sur différentes surfaces avec chacun d’eux pivoté par un degré fixe et arbitraire sur son plan respectif. Par conséquent, une application a besoin d’un mécanisme pour décrire la relation spatiale entre les deux périphériques afin qu’une trame capturée puisse être transposee sur la surface de rendu dans l’orientation correcte.

Une façon de résoudre le problème consiste à utiliser la structure ACPI _PLD qui a déjà les concepts de surface et de degrés de rotation définis. Par exemple, la structure _PLD possède déjà un champ de panneau qui spécifie la surface sur laquelle réside un périphérique :

Définition du champ _PLD panneau ACPI (Rev. 5.0a)

Les deux diagrammes suivants illustrent visuellement la définition de chaque panneau :

Définitions de panneau pour les PC de bureau et la plupart des appareils

Définitions de panneau pour les appareils pliables

En fait, le concept d’un « panneau » ACPI est déjà adopté par Windows où :

• Une interface d’appareil photo est associée à une structure _PLD avec le champ Panneau défini en conséquence si un appareil de capture est monté statiquement à un emplacement fixe.

• Une application peut récupérer le panneau sur lequel réside un appareil de capture en appelant la propriété Windows.Devices.Enumeration.DeviceInformation.EnclosureLocation.Panel .

La structure _PLD ACPI a également un champ de rotation défini comme suit :

Définition du champ de rotation _PLD ACPI (Rev 5.0a)

Au lieu d’utiliser la définition ci-dessus, nous l’affinons davantage pour éviter toute ambiguïté :

• Pour la caméra, le champ rotation d’une structure ACPI _PLD spécifie le nombre de degrés ('0' pour 0°, '2' pour 90°, '4' pour 180° et '6' pour 270°) qu’un cadre capturé est pivoté par rapport à l’écran pendant que l’affichage est dans son orientation native.

Paysage principal et portrait principal

Dans Windows, vous pouvez interroger l’orientation d’affichage native en appelant la propriété, Windows.Graphics.Display.DisplayInformation.NativeOrientation, qui retourne Paysage ou Portrait :

Quelle que soit la valeur retournée par NativeOrientation , le modèle d’analyse d’affichage logique commence à partir du coin supérieur gauche de l’affichage qui passe de gauche à droite vers le bas (voir la figure 5). Pour les appareils dont l’orientation physique par défaut est inexplicit, cette propriété implique non seulement l’emplacement d’un panneau TOP ACPI, mais fournit également la relation spatiale entre une mémoire tampon de sortie de caméra et l’aire de rendu.

Notez que, contrairement à la caméra, la propriété NativeOrientation n’est pas basée sur ACPI et n’a donc pas de structure _PLD. Cela est vrai même si un affichage est monté statiquement sur un appareil.

Lors du montage sur un appareil en mode portrait principal, les pilotes de caméra doivent être conscients que la plupart des applications traiteront l'appareil comme fournissant une mémoire tampon de sortie de caméra en mode paysage, indépendamment de l'orientation réelle de cette mémoire tampon. En raison de cela, nous recommandons aux pilotes de caméra de générer une mémoire tampon de caméra avec un décalage d’orientation de 90 degrés par rapport à l’orientation native en mode Portrait sur un appareil dont le mode principal est Portrait. Cela permettra ensuite aux applications qui effectuent cette rotation supplémentaire sur les appareils portrait de corriger la rotation à l’orientation attendue. Cela peut être vérifié à l’aide de l’Application Caméra avec Exemples de Rotation.

Montage de décalage

Les IHV/OEM sont fortement encouragés à éviter de monter le capteur dans un décalage de non-0 degré pour maintenir la compatibilité des applications. De nombreuses applications existantes et héritées ne savent pas rechercher la table PLD de l’ACPI et n'essaieront pas de corriger le décalage différent de 0 degrés. Par conséquent, pour ces applications, la vidéo résultante sera rendue incorrectement.

Dans les cas où les IHV/OEM ne peuvent pas monter le capteur en orientation de 0 degrés comme décrit ci-dessus, les étapes d’atténuation suivantes sont recommandées dans l’ordre de préférence :

1. Corrigez automatiquement l’orientation non à 0 degrés dans le pilote caméra (en mode noyau avec le pilote miniport av stream ou en mode utilisateur à l’aide d’un plug-in tel que Device MFT ou MFT0) afin que les images de sortie résultantes soient dans l’orientation de 0 degrés.

2. Déclarez une orientation différente de 0 degré via la balise FSSensorOrientation afin que la chaîne de traitement de la caméra puisse corriger l’image capturée.

3. Déclarez l’orientation non à 0 degrés dans la table PLD de l’ACPI, comme décrit ci-dessus.

Types de supports compressés/encodés

Pour les types multimédias compressés et/ou encodés (tels que MJPG, JPEG, H264, HEVC), le pipeline correct ne peut pas être utilisé. En raison de cela, les types de médias compressés/encodés sont filtrés si la valeur FSSensorOrientation est définie sur une valeur non nulle.

Dans le cas de types de supports MJPG (tels que ceux d’une caméra UVC), le pipeline Frame Server fournit un type de média décodé automatiquement (NV12 ou YUY2 pour les applications basées sur DShow). Le type de média automatiquement décodé et corrigé sera présenté, mais le format MJPG d’origine ne le sera pas.

[! REMARQUE !] Si les types de médias compressés/encodés doivent être exposés aux applications, les IHV/ODM ne doivent pas utiliser la correction FSSensorOrientation. Au lieu de cela, la correction doit être effectuée par le pilote de caméra (en mode noyau via le pilote AV Stream ou en mode utilisateur via DMFT/MFT0).

Correction automatique via AV Stream Miniport/Device MFT/MFT0

Le scénario recommandé si les capteurs ne peuvent pas être montés avec un décalage de 0 degrés est d’avoir le pilote miniport AV Stream (ou les plug-ins en mode utilisateur sous la forme de DMFT ou MFT0) corrigent le cadre capturé obtenu afin qu’il soit exposé au pipeline dans un décalage de 0 degrés.

Lors de la correction de l’image vidéo à partir du miniport AV Stream et/ou du plug-in Device MFT/MFT0, la déclaration de type multimédia résultante doit être basée sur l’image corrigée. Si le capteur est monté à un décalage de 90 degrés afin que la vidéo résultante soit de 9:16 proportions du capteur, mais la vidéo corrigée serait de 16:9, le type de média doit déclarer le rapport d’aspect 16:9.

Cela inclut les informations de progression résultantes. Cela est nécessaire, car le composant responsable de la correction est contrôlé par l’IHV/OEM et le pipeline de caméra n’a pas de visibilité dans la trame vidéo, sauf après avoir été corrigé.

Il est vivement recommandé que la correction soit effectuée en mode utilisateur et que le contrat d’API entre le pipeline et le plug-in en mode utilisateur doivent être suivis. Plus précisément, lors de l’utilisation du DMFT ou de MFT0, lorsque le IMFDeviceTransform ::P rocessMessage ou IMFTransform ::P rocessMessage est appelé avec un message MFT_MESSAGE_SET_D3D_MANAGER, le plug-in de mode utilisateur doit respecter les instructions suivantes :

• Si aucun gestionnaire D3D n’est fourni (ulParam du message est 0), le plug-in en mode utilisateur ne doit pas appeler d’opérations GPU pour gérer la correction de rotation. Et le cadre obtenu doit être fourni dans la mémoire système.
• Si le gestionnaire D3D est fourni (l’ulParam du message est l’IUnknown d’un gestionnaire DXGI), alors le gestionnaire DXGI doit être utilisé pour la correction de rotation et l’image résultante doit résider dans la mémoire GPU.
• Le plug-in en mode utilisateur doit également gérer le message du gestionnaire D3D pendant l’exécution. Lorsque le message MFT_MESSAGE_SET_D3D_MANAGER est émis, l’image suivante produite par le plug-in doit correspondre au type de mémoire demandé (par exemple, GPU si le Gestionnaire DXGI a été fourni, le processeur sinon).
• Lorsque le pilote AV Stream (ou le plug-in en mode utilisateur) gère la correction de rotation, le champ Rotation de la structure PLD de l’ACPI doit être défini sur 0.

Déclarer via FSSensorOrientation

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

En déclarant une orientation du capteur différente de 0 degré via la balise de registre FSSensorOrientation, le pipeline de caméra peut corriger l’image capturée avant de la présenter à l’application.

Le pipeline optimise la logique de rotation en tirant parti des ressources GPU ou processeur en fonction du cas d’usage et de la demande/scénario d’application.

Rotation du PLD ACPI

Le champ Rotation de la structure ACPI PLD doit être 0. Cela permet d’éviter les applications déroutantes qui peuvent utiliser les informations PLD pour corriger le cadre.

Informations sur le type de média

Le type de média présenté par le pilote doit être le type de média non correct. Lorsque vous informez le pipeline de caméra du décalage non nul en degrés à l’aide de l’entrée FSSensorOrientation, les informations de type multimédia présentées par le capteur doivent être le type de média non corrigé. Par exemple, si le capteur est monté à 90 degrés de décalage dans le sens des aiguilles d'une montre, au lieu d'un rapport d'aspect 16:9, la vidéo résultante est de 9:16, le type de média au format 9:16 doit être présenté au processus de traitement de la caméra.

Cela est nécessaire pour vous assurer que le pipeline peut configurer correctement le processus de rotation des compteurs : le pipeline a besoin du type de média d’entrée et du type de média de sortie souhaité de l’application.

Cela inclut les informations de progression. Les informations de progression doivent être présentées pour le type de média non correct sur le pipeline de caméra.

Sous-clé de Registre

L’entrée de Registre FSSensorOrientation doit être publiée sur le nœud Device Interface. L’approche recommandée consiste à déclarer cela en tant que directive AddReg pendant la déclaration de directive AddInterface dans l’INF du pilote de caméra.

Les données présentées dans FSSensorOrientation doivent être un REG_DWORD et les seules valeurs valides acceptées seront 90, 180 et 270. Toute autre valeur sera traitée comme un décalage de 0 degrés (c’est-à-dire ignoré).

Chaque valeur représente l’orientation du capteur dans le sens des aiguilles d’une montre. Le pipeline de caméra corrige l’image vidéo résultante en faisant pivoter la vidéo de la même quantité dans le sens des aiguilles d’une montre : c’est-à-dire une déclaration à 90 degrés dans le sens des aiguilles d’une montre entraîne une rotation de 90 degrés dans le sens des aiguilles d’une montre pour ramener l’image vidéo résultante à un décalage de 0 degrés.

Descripteur MS OS 1.0

Pour les caméras USB, FSSensorOrientation peut également être publié via des descripteurs MSOS.

MS OS Descriptor 1.0 a deux composants :

• Section d’en-tête de longueur fixe
• Une ou plusieurs sections de propriétés personnalisées de longueur variable, qui suivent la section d’en-tête

Section d’en-tête MS OS DESCRIPTOR 1.0

La section En-tête décrit une propriété personnalisée unique (Profil d’authentification visage).

Section de propriété MS OS DESCRIPTOR 1.0 personnalisée

Descripteur MS OS 2.0

Le descripteur étendu MSOS 2.0 peut être utilisé pour définir les valeurs de registre pour ajouter la prise en charge de FSSensorOrientation. Pour ce faire, utilisez le descripteur de propriété de Registre Microsoft OS 2.0.

Pour l'entrée de registre UVC-FSSensorOrientation, voici un exemple d'ensemble de descripteurs MSOS 2.0 :

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)
}

Déclarez via les informations PLD ACPI

En guise d’option de dernier recours, les informations PLD peuvent être exploitées comme décrit ci-dessus pour indiquer à l’application que la trame vidéo doit être corrigée avant d’être rendue/encodée. Toutefois, comme indiqué ci-après, de nombreuses applications existantes n’utilisent pas les informations PLD ni gèrent la rotation des images. Il existe donc des scénarios où les applications peuvent ne pas être en mesure d’afficher correctement la vidéo résultante.

Les illustrations suivantes illustrent les valeurs du champ rotation _PLD pour chaque configuration matérielle :

Rotation : 0 degré dans le sens des aiguilles d’une montre

Dans la figure ci-dessus :

• L’image à gauche illustre la scène à capturer.

• L’image au milieu montre comment une scène est vue par un capteur CMOS dont l’ordre de lecture physique commence à partir du coin inférieur gauche se déplaçant de gauche à droite vers le haut.

• L’image à droite représente la sortie du pilote de caméra. Dans cet exemple, le contenu de la mémoire tampon multimédia peut être rendu directement lorsque l'affichage est dans son orientation native, sans rotation supplémentaire. Par conséquent, le champ de rotation _PLD ACPI a la valeur 0.

Rotation : 90 degrés dans le sens des aiguilles d’une montre

Dans ce cas, le contenu de la mémoire tampon multimédia est pivoté de 90 degrés dans le sens des aiguilles d'une montre par rapport à la scène d’origine. Par conséquent, le champ de rotation _PLD ACPI a la valeur 2.

Rotation : 180 degrés dans le sens des aiguilles d’une montre

Dans ce cas, le contenu de la mémoire tampon multimédia est tourné de 180 degrés dans le sens des aiguilles d'une montre par rapport à la scène d'origine. Par conséquent, le champ de rotation _PLD ACPI a la valeur 4.

Rotation : 270 degrés dans le sens des aiguilles d’une montre

Dans ce cas, le contenu de la mémoire tampon multimédia est pivoté de 270 degrés dans le sens des aiguilles d'une montre par rapport à la scène d’origine. Par conséquent, le champ de rotation _PLD ACPI a la valeur 6.