Soporte de controladores para la orientación de la cámara

A medida que se introducen diferentes factores de forma de los dispositivos de computación, algunas de las restricciones físicas dan lugar a que los sensores de cámara se monten en una orientación no tradicional. Por este motivo, es necesario describir correctamente el sistema operativo y la aplicación, cómo se montan los sensores para que el vídeo resultante se pueda representar o grabar correctamente.

A partir de la ventana 10, versión 1607, todos los controladores de cámara deben especificar explícitamente la orientación de la cámara, independientemente de si la cámara está montada de acuerdo con los requisitos mínimos de hardware. En concreto, un controlador de cámara debe establecer un campo recién introducido, Rotation, en la estructura acpI _PLD asociada a una interfaz de dispositivo de captura:

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;

Para la cámara, el campo Rotación en una estructura ACPI _PLD especifica el número de grados ('0' para 0°, '2' para 90°, '4' para 180°, y '6' para 270°) un marco capturado se gira en relación con la pantalla mientras la pantalla está en su orientación nativa.

En función del valor del campo Rotación , una aplicación puede realizar una rotación adicional, si es necesario, para representar los fotogramas capturados correctamente.

Valores de rotación

Para aquellos dispositivos cuyas cámaras y pantallas comparten la misma carcasa (o/carcasa), es posible montar estos periféricos en diferentes superficies con cada uno de ellos girando por un grado fijo pero arbitrario en su plano respectivo. Por consiguiente, una aplicación necesita un mecanismo para describir la relación espacial entre los dos periféricos de forma que se pueda transponer un marco capturado a la superficie de representación en la orientación correcta.

Una manera de resolver el problema es usar la estructura de _PLD ACPI que ya tiene los conceptos de superficie y grados de rotación definidos. Por ejemplo, la estructura _PLD ya tiene un campo de panel que especifica la superficie en la que reside un periférico:

Definición del campo ACPI _PLD Panel (Rev. 5.0a)

Los dos diagramas siguientes muestran la definición de cada panel visualmente:

Definiciones de panel para equipos de escritorio y la mayoría de los dispositivos

Definiciones de panel para dispositivos plegables

De hecho, Windows ya ha adoptado el concepto de "panel ACPI" en el que:

• Una interfaz de cámara está asociada a una estructura de _PLD con el campo Panel que se configura en consecuencia si se monta estáticamente un dispositivo de captura en una ubicación fija.

• Una aplicación puede recuperar el panel en el que reside un dispositivo de captura llamando a la propiedad Windows.Devices.Enumeration.DeviceInformation.EnclosureLocation.Panel .

La estructura de _PLD ACPI también tiene un campo Rotación definido como sigue:

Definición del campo de rotación de _PLD ACPI (Rev 5.0a)

En lugar de usar la definición anterior tal como está, se refina aún más para evitar ambigüedad:

• Para la cámara, el campo de Rotación de la estructura ACPI _PLD especifica el número de grados ('0' para 0°, '2' para 90°, '4' para 180°, y '6' para 270°) que se gira un marco capturado en relación con la pantalla estando esta en su orientación nativa.

Orientación apaisada principal frente a orientación vertical principal

En Windows, se puede consultar la orientación de visualización nativa llamando a la propiedad Windows.Graphics.Display.DisplayInformation.NativeOrientation, que devuelve Horizontal o Vertical:

Independientemente del valor que devuelva NativeOrientation , el patrón de examen de visualización lógico comienza desde la esquina superior izquierda de la pantalla que se mueve de izquierda a derecha hacia abajo (vea la figura 5). Para aquellos dispositivos cuya orientación física predeterminada no es explícita, esta propiedad no solo determina la ubicación de un panel ACPI superior, sino que también proporciona la relación espacial entre un buffer de salida de la cámara y la superficie de representación.

Tenga en cuenta que, a diferencia de la cámara, la propiedad NativeOrientation no se basa en ACPI y, por tanto, no tiene una estructura _PLD. Esto es cierto incluso si una pantalla se monta estáticamente en un dispositivo.

Al montar en un dispositivo Portrait Primary, los controladores de cámara deben tener en cuenta que la mayoría de las aplicaciones tratarán al dispositivo como si entregara un búfer de salida de cámara en formato horizontal, independientemente de la orientación real del búfer de salida de la cámara. Por este motivo, se recomienda que los controladores de cámara produzcan un búfer de cámara que tenga un desplazamiento de orientación de 90 grados desde la Orientación Nativa Retrato cuando se encuentra en un dispositivo con orientación retrato primaria. De esta manera, se permitirá que las aplicaciones que realicen esta rotación adicional en dispositivos en modo vertical corrijan la rotación a la orientación esperada. Esto se puede comprobar mediante la aplicación de cámara con el ejemplo de rotación.

Montaje con desplazamiento

Se recomienda encarecidamente que IHV/OEMs evite montar el sensor en un desplazamiento distinto de 0 grados para mantener la compatibilidad de la aplicación. Muchas aplicaciones existentes y heredadas no saben buscar la tabla PLD de ACPI, ni intentarán corregir el desplazamiento no 0 grados. Por lo tanto, para estas aplicaciones, el vídeo resultante se representará incorrectamente.

En los casos en los que los IHV/OEM no pueden montar el sensor en orientación de 0 grados, como se ha descrito anteriormente, se recomiendan los siguientes pasos de mitigación en el orden de preferencia:

1. Corrija automáticamente la orientación que no sea de 0 grados dentro del controlador de cámara (ya sea en modo kernel con el controlador de miniporte de secuencia AV o en modo de usuario mediante un complemento como Device MFT o MFT0) para que los fotogramas de salida resultantes estén en la orientación de 0 grados.

2. Declare la orientación no 0 grados a través de la etiqueta FSSensorOrientation para que la canalización de cámara pueda corregir la imagen capturada.

3. Declare la orientación de no 0 grados en la tabla PLD de ACPI como se ha descrito anteriormente.

Tipos de medios comprimidos o codificados

Para los tipos de medios comprimidos o codificados (como MJPG, JPEG, H264, HEVC), no se puede usar la canalización correcta. Por este motivo, los tipos de medios comprimidos o codificados se filtrarán si FSSensorOrientation está establecido en un valor distinto de cero.

En el caso de los tipos de medios MJPG (como los de una cámara UVC), la canalización de Frame Server proporciona un tipo de medio descodificado automáticamente (NV12 o YUY2 para aplicaciones basadas en DShow). Se mostrará el tipo de medio descodificado y corregido automáticamente, pero el formato MJPG original no lo hará.

[!NOTA!] Si los tipos de medios comprimidos o codificados deben exponerse a las aplicaciones, los IHV/ODMs no deben utilizar la corrección FSSensorOrientation. En su lugar, el controlador de cámara debe realizar la corrección (ya sea en modo kernel a través del controlador av Stream o en modo de usuario a través de DMFT/MFT0).

Corrección automática a través de minipuerto de flujo AV/dispositivo MFT/MFT0

El escenario recomendado si los sensores no se pueden montar con un desplazamiento de 0 grados, es hacer que el controlador miniport de AV Stream (o los complementos en modo de usuario en forma de DMFT o MFT0) corrija el fotograma capturado resultante para que se exponga al flujo de datos con un desplazamiento de 0 grados.

Al corregir el fotograma de vídeo desde el Miniport de AV Stream o el complemento Device MFT/MFT0, la declaración de tipo de medio resultante debe basarse en el fotograma corregido. Si el sensor está montado en un desplazamiento de 90 grados para que el vídeo resultante sea la relación de aspecto 9:16 del sensor, pero el vídeo corregido sería 16:9, el tipo de medio debe declarar la relación de aspecto 16:9.

Esto incluye la información del paso resultante. Esto es necesario, ya que el componente responsable de realizar la corrección está controlado por el IHV/OEM y la canalización de la cámara no tiene visibilidad en el fotograma de vídeo, excepto después de que se corrija.

Se recomienda encarecidamente que se realice la corrección en modo de usuario y que se deba seguir el contrato de API entre la canalización y el complemento de modo de usuario. En concreto, cuando se usa DMFT o MFT0, si se invoca el IMFDeviceTransform::ProcessMessage o el IMFTransform::ProcessMessage con un mensaje MFT_MESSAGE_SET_D3D_MANAGER, el complemento en modo de usuario debe cumplir la siguiente directriz:

• Si no se proporciona ningún administrador D3D (el ulParam del mensaje es 0), el complemento de modo de usuario NO debe invocar ninguna operación de GPU para controlar la corrección de rotación. Y el marco resultante debe proporcionarse en la memoria del sistema.
• Si se proporciona el administrador D3D (el ulParam del mensaje es el IUnknown de un administrador DXGI), ese administrador DXGI debe usarse para la corrección de rotación y el fotograma resultante debe estar en la memoria GPU.
• El complemento de modo de usuario también debe controlar el mensaje del administrador D3D durante el tiempo de ejecución. Cuando se emite el mensaje de MFT_MESSAGE_SET_D3D_MANAGER, el siguiente fotograma generado por el complemento debe corresponder al tipo de memoria solicitado (es decir, GPU si se proporcionó DXGI Manager, CPU en caso contrario).
• Cuando el controlador AV Stream (o el complemento de modo de usuario) controla la corrección de Rotación, el campo Rotación de la estructura PLD de ACPI debe establecerse en 0.

Declarar a través de FSSensorOrientation

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

Al declarar la orientación del sensor que no es de 0 grados a través de la etiqueta del registro FSSensorOrientation, el flujo de cámara puede corregir el fotograma capturado antes de presentárselo a la aplicación.

La canalización optimizará la lógica de rotación aprovechando los recursos de GPU o CPU en función del caso de uso y la solicitud o el escenario de la aplicación.

Rotación de PLD ACPI

El campo Rotación de la estructura PLD ACPI debe ser 0. Esto es para evitar aplicaciones confusas que pueden usar la información de PLD para corregir el marco.

Información de tipo multimedia

El tipo de medio presentado por el controlador debe ser el tipo de medio no corregido. Al informar a la canalización de la cámara del desplazamiento no 0 grados mediante la entrada FSSensorOrientation, la información del tipo de medio presentada por el sensor debe ser el tipo de medio no corregido. Por ejemplo, si el sensor está desplazado 90 grados en sentido de las agujas del reloj, lo que significa que, en lugar de una relación de aspecto de 16:9, el vídeo resultante tiene una relación de aspecto de 9:16, el tipo de formato de 9:16 de relación de aspecto debe presentarse al procesamiento de la cámara.

Esto es necesario para asegurarse de que la canalización puede configurar correctamente el proceso de rotación de contadores: la canalización necesita el tipo de medio de entrada y el tipo de medio de salida deseado de la aplicación.

Esto incluye la información de paso. La información del desplazamiento debe presentarse para el tipo de media no corregido en la canalización de la cámara.

Subclave del Registro

La entrada del Registro FSSensorOrientation debe publicarse en el nodo Interfaz de dispositivo. El enfoque recomendado es declararlo como una directiva AddReg durante la declaración de la directiva AddInterface en el INF del controlador de cámara.

Los datos presentados en FSSensorOrientation deben ser un REG_DWORD y los únicos valores válidos aceptados serán 90, 180 y 270. Cualquier otro valor se tratará como desplazamiento de 0 grados (es decir, omitido).

Cada valor representa la orientación del sensor en grados en el sentido de las agujas del reloj. La canalización de cámara corregirá el fotograma de vídeo resultante girando el vídeo por la misma cantidad en sentido contrario a las agujas del reloj: es decir, una declaración en sentido contrario a las agujas del reloj de 90 grados dará como resultado una rotación en sentido contrario al reloj de 90 grados para devolver el fotograma de vídeo resultante a un desplazamiento de 0 grados.

Descriptor de SO de MS 1.0

En el caso de las cámaras basadas en USB, FSSensorOrientation también se puede publicar a través de descriptores de MSOS.

Ms OS Descriptor 1.0 tiene dos componentes:

• Una sección de encabezado de longitud fija
• Una o varias secciones de propiedades personalizadas de longitud variable, que siguen a la sección de encabezado

Sección de encabezado del descriptor 1.0 de MS OS

La sección encabezado describe una sola propiedad personalizada (Perfil de autenticación de Face).

Sección de propiedades del DESCRIPTOR DEL SO DE MS 1.0 personalizado

Descriptor de SO de MS 2.0

MsOS Extended Descriptor 2.0 se puede usar para definir los valores del Registro para agregar compatibilidad con FSSensorOrientation. Esto se hace mediante el Descriptor de propiedades del Registro de Microsoft OS 2.0.

Para la entrada del registro de UVC-FSSensorOrientation, se muestra a continuación un ejemplo de conjunto de descriptores de 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)
}

Declarar mediante la información de PLD de ACPI

Como opción del último recurso, la información de PLD se puede aprovechar como se ha descrito anteriormente para indicar a la aplicación que el fotograma de vídeo debe corregirse antes de representarse o codificarse. Sin embargo, como se indica, muchas aplicaciones existentes no usan la información de PLD ni controlan la rotación de fotogramas, por lo que habrá escenarios en los que es posible que las aplicaciones no puedan representar el vídeo resultante correctamente.

En las ilustraciones siguientes se muestran los valores del campo rotación de _PLD para cada configuración de hardware:

Rotación: 0 grados en el sentido de las agujas del reloj

En la ilustración anterior:

• La imagen de la izquierda muestra la escena que se va a capturar.

• La imagen en el medio muestra cómo un sensor CMOS ve una escena cuyo orden de lectura físico comienza desde la esquina inferior izquierda que se mueve de izquierda a derecha hacia arriba.

• La imagen de la derecha representa la salida del controlador de cámara. En este ejemplo, el contenido del búfer multimedia se puede mostrar directamente cuando la pantalla está en su orientación nativa, sin necesidad de rotación adicional. Por consiguiente, el campo ACPI _PLD Rotación tiene un valor de 0.

Rotación: 90 grados en el sentido de las agujas del reloj

En este caso, el contenido del búfer multimedia gira en 90 grados en el sentido de las agujas del reloj en comparación con la escena original. Como resultado, el campo ACPI _PLD Rotación tiene un valor de 2.

Rotación: 180 grados en el sentido de las agujas del reloj

En este caso, el contenido del búfer multimedia gira en 180 grados en el sentido de las agujas del reloj en comparación con la escena original. Como resultado, el campo ACPI _PLD Rotación tiene un valor de 4.

Rotación: 270 grados en sentido de las agujas del reloj

En este caso, el contenido del búfer multimedia gira en 270 grados en el sentido de las agujas del reloj en comparación con la escena original. Como resultado, el campo ACPI _PLD Rotación tiene un valor de 6.