Especificación de extensiones de Microsoft a usb Video Class 1.5

  • Artículo

1 Introducción

1.1 Resumen

Las extensiones de Microsoft a la especificación de clase de vídeo USB permiten nuevos controles, así como la capacidad de llevar metadatos de fotogramas bien definidos en un formato estándar.

1.2 Decisiones de arquitectura

La compatibilidad con metadatos de fotogramas de clase de vídeo USB (UVC) estará disponible para los puntos de conexión ISOCH y BULK. Sin embargo, en el caso del punto de conexión BULK, el tamaño de los metadatos se limitará a 240 bytes (debido al hecho de que todos los datos de fotogramas de vídeo se transfieren en un único paquete de fotogramas de vídeo en puntos de conexión BULK).

La compatibilidad con metadatos uvC solo estará disponible para cargas basadas en fotogramas.

La compatibilidad con metadatos UVC solo estará disponible a través de la canalización de captura de Media Foundation (MF).

Los metadatos de UVC serán opcionales. Cada IHV/OEM que necesite compatibilidad con metadatos debe habilitarlo a través de un archivo INF personalizado.

Los metadatos de UVC solo admitirán la memoria asignada por el sistema. No se admitirán superficies VRAM o DX.

2 Introducción a la arquitectura

2.1 Descripción

2.2.1 Detección de funcionalidades a través de INF

2.2.1.1 Captura de imágenes fijas: método 2

Es posible que algunos dispositivos UVC existentes no admitan el método 2 descrito en la sección 2.4.2.4 (Captura de imágenes fijas) de la clase UVC 1.5 specification.pdf que se pueden descargar en el sitio web de especificación de clase de vídeo USB .

En Windows 10, versión 1607 y anteriores, la canalización de captura no aprovechaba el método 2, incluso si un dispositivo anunciaba compatibilidad con ella según la especificación UVC 1.5.

En Windows 10, versión 1703, los dispositivos que aprovechan este método deben usar un archivo INF personalizado para el controlador de cámara, pero se requiere un INF personalizado para que el hardware especificado habilite la captura de imágenes del método 2).

Nota: El controlador de cámara se puede basar en el USBVIDEO.SYS de Windows o puede basarse en un archivo binario de controlador personalizado.

El archivo INF personalizado, basado en el controlador UVC personalizado o en el controlador UVC de bandeja de entrada, debe incluir la siguiente entrada AddReg:

EnableDependentStillPinCapture: REG_DWORD: 0x0 (deshabilitado) en 0x1 (habilitado)

Cuando esta entrada se establece en Habilitado (0x1), la canalización de captura aprovechará el método 2 para la captura de imágenes fijas (suponiendo que el firmware también anuncia la compatibilidad con el método 2 según lo especificado por la especificación UVC 1.5).

Un ejemplo de la sección INF personalizada sería el siguiente:

[USBVideo.NT.Interfaces]
AddInterface=%KSCATEGORY_CAPTURE%,GLOBAL,USBVideo.Interface
AddInterface=%KSCATEGORY_RENDER%,GLOBAL,USBVideo.Interface
AddInterface=%KSCATEGORY_VIDEO%,GLOBAL,USBVideo.Interface
AddInterface=%KSCATEGORY_RENDER_EXT%,GLOBAL,USBVideo.Interface
AddInterface=%KSCATEGORY_VIDEO_CAMERA%,GLOBAL,USBVideo.Interface

[USBVideo.Interface]
AddReg=USBVideo.Interface.AddReg

[USBVideo.Interface.AddReg]
HKR,,CLSID,,%ProxyVCap.CLSID%
HKR,,FriendlyName,,%USBVideo.DeviceDesc%
HKR,,RTCFlags,0x00010001,0x00000010
HKR,,EnableDependentStillPinCapture,0x00010001,0x00000001

2.2.2 Controles de unidad de extensión

La extensión de Microsoft a la especificación de clase de vídeo USB para habilitar nuevos controles se realiza a través de una unidad de extensión identificada por el GUID MS_CAMERA_CONTROL_XU (denominada Microsoft-XU).

// {0F3F95DC-2632-4C4E-92C9-A04782F43BC8}
DEFINE_GUID(MS_CAMERA_CONTROL_XU,
    0xf3f95dc, 0x2632, 0x4c4e, 0x92, 0xc9, 0xa0, 0x47, 0x82, 0xf4, 0x3b, 0xc8);

Un Microsoft-XU implementado por el firmware del dispositivo hospedará los nuevos controles definidos en las siguientes subsecciones. Las siguientes definiciones de solicitud se aplican a todos estos controles a menos que se especifique explícitamente una definición de invalidación para ese control. Consulte la specification.pdfde clase UVC 1.5 para ver las definiciones de D3, D4, GET_INFO, etc.

GET_INFO solicitud notificará el control sin capacidades autoactualizaciones y asincrónicas (por ejemplo, los bits D3 y D4 se establecerán en 0).

GET_LEN solicitud informará de la longitud máxima de la carga útil para este control (wLength).

GET_RES solicitud notificará la resolución (tamaño de paso) para qwValue/dwValue. Todos los demás campos se establecerán en 0.

GET_MIN solicitud notificará el valor mínimo admitido para qwValue/dwValue. Todos los demás campos se establecerán en 0.

GET_MAX solicitud notificará el valor máximo admitido para qwValue/dwValue. Además, todas las marcas admitidas se establecerán en 1 en bmControlFlags. Todos los demás campos se establecerán en 0.

GET_DEF y GET_CUR solicitudes notificarán la configuración predeterminada y actual respectivamente para los campos qwValue/dwValue y bmControlFlags. Todos los demás campos se establecerán en 0.

Un host emite una solicitud de SET_CUR después de establecer todos los campos.

En la tabla siguiente se asignan los selectores de control de Microsoft-XU a sus respectivos valores y la posición de bits del campo bmControls en descriptor de unidad de extensión:

controles de unidad de extensión.

2.2.2.1 Controles cancelables

Aquí se define un control Cancelable aprovechando la funcionalidad Autoupdate.

GET_INFO solicitud notificará un control como un control de actualización automática (por ejemplo, el bit D3 se establecerá en 1), pero no como un control asincrónico (por ejemplo, el bit D4 se establecerá en 0).

Para este control, se puede emitir una solicitud de SET_CUR para establecer un nuevo valor (una solicitud SET_CUR(NORMAL) donde en bmOperationFlags:D0 bit está establecido en 0) o cancelar una solicitud de SET_CUR(NORMAL) anterior (una solicitud SET_CUR(CANCEL) dondein bmOperationFlags:D0 bit está establecido en 1). El dispositivo debe completar inmediatamente una solicitud de SET_CUR en cuanto se reciba la solicitud (aunque el hardware no esté configurado o convergente con la nueva configuración solicitada). Para cada solicitud de SET_CUR(NORMAL), el dispositivo genera una interrupción de cambio de control correspondiente para este control que se genera cuando se han aplicado las nuevas configuraciones o cuando llega una solicitud de SET_CUR(CANCEL); hasta que llegue esta interrupción, la solicitud SET_CUR(NORMAL) se considerará en curso. Cuando una solicitud SET_CUR(NORMAL) está en curso, las solicitudes adicionales de SET_CUR(NORMAL) para este control en particular producirán un error. Una solicitud SET_CUR(CANCEL) siempre se realizará correctamente. Si no hay nada que cancelar, el dispositivo simplemente no hace nada.

La carga de interrupción de cambio de control tendrá el bit bmOperationFlags:D0 establecido en 0 si la configuración especificada por SET_CUR(NORMAL) se aplicó (por ejemplo, se ha producido la convergencia) y se estableció en 1 si no se aplicó la configuración debido a una solicitud de SET_CUR(CANCEL) que se produjo después de la solicitud SET_CUR(NORMAL) (por ejemplo, la convergencia aún no se ha producido).

2.2.2.2 Control de foco

Este control permite al software host especificar la configuración de foco de la cámara. Se trata de un control global que afecta a todos los puntos de conexión de todas las interfaces de streaming de vídeo asociadas a la interfaz de control de vídeo.

control de foco.

Este control funcionará como control cancelable (consulte la sección 2.2.2.1 para GET_INFO requisitos de solicitud y comportamiento funcional de SET_CUR solicitud).

GET_MAX requisito: este control anunciará la compatibilidad con bits D0, D1, D2, D8 y D18 en bmControlFlags.

GET_DEF requisito: el valor predeterminado para bmControlFlags será D0 y D18 establecido en 1 y dwValue establecido en 0.

Para las solicitudes GET_CUR/SET_CUR, se aplican las restricciones siguientes para el campo bmControlFlags:

  • Entre los bits D0, D1 y D8, solo se puede establecer un bit; ninguno de ellos que se establece es válido también si se establece el bit D2.

  • Entre D16, D17, D18, D19 y D20, solo se puede establecer un bit; ninguno de ellos se establece también es válido.

  • D1 no es compatible con todos los demás bits definidos actualmente (D0, D2, D8, D16, D17, D18, D19 y D20).

  • D2 no es compatible con D1 y D8.

  • D2 no es compatible con D16, D17, D18, D19 y D20 si no se establece D0.

2.2.2.3 Control de exposición

Este control permite al software host especificar la configuración de exposición de la cámara. Se trata de un control global que afecta a todos los puntos de conexión de todas las interfaces de streaming de vídeo asociadas a la interfaz de control de vídeo.

control de exposición.

GET_INFO solicitud notificará este control como un control asincrónico (por ejemplo, el bit D4 se establecerá en 1), pero no como un control AutoUpdate (por ejemplo, el bit D3 se establecerá en 0).

GET_MAX requisito: este control anunciará la compatibilidad con bits D0, D1 y D2 en bmControlFlags.

GET_DEF requisito: el valor predeterminado para bmControlFlags debe ser D0 establecido en 1 y qwValue establecido en 0.

Para las solicitudes GET_CUR/SET_CUR, se aplican las restricciones siguientes para el campo bmControlFlags:

  • Entre los bits D0, D1 y D2, se establecerá al menos un bit.

  • D1 no es compatible con D0 y D2.

2.2.2.4 Control de compensación ev

Este control permite al software host especificar la configuración de compensación ev para la cámara. Se trata de un control global que afecta a todos los puntos de conexión de todas las interfaces de streaming de vídeo asociadas a la interfaz de control de vídeo.

Control de compensación de E V.

GET_INFO solicitud notificará este control como un control asincrónico (por ejemplo, el bit D4 se establecerá en 1), pero no como un control AutoUpdate (por ejemplo, el bit D3 se establecerá en 0).

GET_RES solicitud notificará todas las resoluciones admitidas (tamaño de paso) estableciendo los bits correspondientes en bmControlFlags. Todos los demás campos se establecerán en 0.

GET_MIN y GET_MAX solicitudes notificarán el valor mínimo y máximo admitido para dwValue. El bit D4 (que indica el tamaño del paso de 1) será el único bit establecido en bmControlFlags. Todos los demás campos se establecerán en 0.

GET_DEF, GET_CUR, SET_CUR solicitudes seguirán las definiciones de la sección 2.2.2.1, pero tendrán uno y un solo bit entre D0, D1, D2, D3 y D4 bits para el campo bmControlFlags. Además, GET_DEF solicitud tendrá dwValue establecido en 0.

2.2.2.5 Control de equilibrio de blancos

Este control permite al software host especificar la configuración del equilibrio de blancos para la cámara. Se trata de un control global que afecta a todos los puntos de conexión de todas las interfaces de streaming de vídeo asociadas a la interfaz de control de vídeo.

control de equilibrio de blancos.

GET_INFO solicitud notificará este control como un control asincrónico (por ejemplo, el bit D4 se establecerá en 1), pero no como un control AutoUpdate (por ejemplo, el bit D3 se establecerá en 0).

GET_RES, GET_MIN, las solicitudes de GET_MAX seguirán las definiciones de la sección 2.2.2.1, pero tendrán dwValueFormat establecido en 1.

GET_MAX requisito: este control anunciará la compatibilidad con bits D0, D1 y D2 en bmControlFlags.

GET_DEF requisito: el valor predeterminado para bmControlFlags debe ser D0 establecido en 1 y dwValueFormat , así como dwValue establecido en 0.

Para las solicitudes GET_CUR/SET_CUR, se aplican las restricciones siguientes para el campo bmControlFlags:

  • Entre los bits D0, D1 y D2, se establecerá al menos un bit.

  • D1 no es compatible con D0 y D2.

2.2.2.6 Control de autenticación facial

Este control permite al software host especificar si la cámara admite modos de streaming que se usan para la autenticación facial. La compatibilidad con este control implica que la cámara es capaz de autenticación facial. De lo contrario, no se admitirá este control.

Este control solo es aplicable a las cámaras que pueden producir datos de Infra-Red (IR) y solo se aplica a las interfaces de streaming especificadas (que es un subconjunto de todas las interfaces de streaming de vídeo asociadas a la interfaz de control de vídeo).

control de autenticación facial.

GET_RES y solicitudes de GET_MIN notificarán el campo bNumEntries establecido en 0 y, por tanto, no tendrán campos adicionales.

Para una solicitud de GET_MAX, un bit establecido en 1 en el campo bmControlFlags indica que el modo correspondiente es compatible con esa interfaz de streaming. Una salida de solicitud de GET_MAX enumerará todas las interfaces de streaming y solo las interfaces de streaming capaces de D1 o D2 (por ejemplo, si una interfaz de streaming es capaz de D1 o D2, aparece; de lo contrario, no aparece en la lista). Además, no se anunciará ninguna interfaz de streaming para poder ser capaz de D1 y D2. Si una interfaz de streaming también está pensada para su uso de manera general (por ejemplo, fuera del propósito de la autenticación facial), D0 se establecerá en 1 para esa interfaz de streaming (además de D1/D2).

Para las solicitudes GET_DEF/GET_CUR/SET_CUR, un bit establecido en 1 en el campo bmControlFlags indica que se elige el modo correspondiente para esa interfaz de streaming. En estas solicitudes, se establecerá un bit (entre D0, D1 & D2) para una interfaz de streaming determinada. Para la solicitud de GET_DEF que devuelve la opción predeterminada (que es específica de la implementación), si una interfaz de streaming también está pensada para usarse de forma general (por ejemplo, fuera del propósito de la autenticación facial), D0 se establecerá en 1 de forma predeterminada en esa interfaz de streaming; de lo contrario, D1 o D2 (pero no ambos) se establecerán en 1 de forma predeterminada. Sin embargo, una salida de solicitud de GET_DEF o GET_CUR contendrá información sobre todas las interfaces de streaming enumeradas en GET_MAX salida de solicitud, pero una solicitud de SET_CUR solo puede incluir un subconjunto de las interfaces de streaming enumeradas en GET_MAX salida de solicitud.

Ejemplo:

Supongamos que una cámara tiene cuatro interfaces de streaming de vídeo con números 0x03, 0x05, 0x08 y 0x0b respectivamente, donde la interfaz de streaming de vídeo 0x05 genera datos RGB y las tres interfaces de streaming de vídeo restantes producen datos ir. Entre las interfaces de streaming que producen datos de IR, supongamos que las interfaces de streaming 0x03 y 0x0b son capaces de D1, pero la interfaz de streaming 0x03 también es capaz de D0. En este ejemplo, el control de autenticación facial solo se aplica a las interfaces de streaming numeradas 0x03 y 0x0b y, por lo tanto, solo estas interfaces aparecerán en las solicitudes.

La salida de GET_MAX solicitud será la siguiente:

GET_MAX de autenticación facial.

La salida de GET_DEF solicitud será la siguiente:

GET_DEF de autenticación facial.

Una solicitud de SET_CUR para cambiar la configuración de la interfaz de streaming 0x03 a D1 sería la siguiente:

SET_CUR de autenticación facial.

La salida de una solicitud de GET_CUR después de la solicitud de SET_CUR anterior será la siguiente:

GET_CUR de autenticación facial.

2.2.2.7 Control extrinsics de cámara

Este control permite que el software host obtenga los datos extrinsics de la cámara para los puntos de conexión en interfaces de streaming de vídeo asociadas a la interfaz de control de vídeo. Los datos obtenidos para cada punto de conexión se mostrarán como atributos MFStreamExtension_CameraExtrinsics en el almacén de atributos para la secuencia correspondiente (obtenido mediante la llamada IMFDeviceTransform::GetOutputStreamAttributes).

control de extrinsics de cámara.

GET_RES, GET_MIN, GET_MAX, las solicitudes de GET_CUR notificarán los campos bNumEntries establecidos en 0 y, por tanto, no tendrán campos adicionales.

GET_DEF solicitud enumerará todos los puntos de conexión que tengan la información extrinsica disponible.

Ejemplo:

Supongamos que una cámara tiene tres interfaces de streaming de vídeo con números 0x03, 0x05 y 0x08 respectivamente, donde la interfaz de streaming de vídeo 0x05 admite la captura de imágenes con el método 2, además de la captura de vídeo compatible con todas las interfaces de streaming de vídeo. Entre estas interfaces de streaming, supongamos que las interfaces de streaming 0x05 y 0x08 tienen información extrinsica disponible mientras que la interfaz de streaming 0x03 no tiene la información extrinsica disponible.

En este ejemplo, la salida de GET_DEF solicitud será la siguiente:

extrinsics de cámara GET_DEF.

2.2.2.8 Control intrínseco de cámara

Este control permite que el software host obtenga los datos intrínsecos de la cámara para los puntos de conexión en interfaces de streaming de vídeo asociadas a la interfaz de control de vídeo. Los datos obtenidos para cada punto de conexión se mostrarán como atributos MFStreamExtension_PinholeCameraIntrinsics en el almacén de atributos para la secuencia correspondiente (obtenido mediante la llamada IMFDeviceTransform::GetOutputStreamAttributes).

control intrínsecos de cámara.

GET_RES, GET_MIN, GET_MAX, las solicitudes de GET_CUR notificarán los campos bNumEntries establecidos en 0 y, por tanto, no tendrán campos adicionales.

GET_DEF solicitud enumerará todos los puntos de conexión que tengan la información intrínseca disponible.

Ejemplo:

Supongamos que una cámara tiene tres interfaces de streaming de vídeo con números 0x03, 0x05 y 0x08 respectivamente, donde la interfaz de streaming de vídeo 0x05 admite la captura de imágenes con el método 2, además de la captura de vídeo compatible con todas las interfaces de streaming de vídeo. Entre estas interfaces de streaming, supongamos que las interfaces de streaming 0x05 y 0x08 tienen información intrínseca disponible, mientras que la interfaz de streaming 0x03 no tiene disponible la información intrínseca.

En este ejemplo, la salida de GET_DEF solicitud será la siguiente:

GET_DEF intrínsecos de cámara.

2.2.2.9 Control de metadatos

Este control permite que el software host consulte y controle los metadatos generados por la cámara. Se trata de un control global que afecta a todos los puntos de conexión de todas las interfaces de streaming de vídeo asociadas a la interfaz de control de vídeo.

Este control se asigna a KSPROPERTY_CAMERACONTROL_EXTENDED_METADATA por el controlador de cámara.

control de metadatos.

Si el firmware admite SET_CUR solicitud, se aplica lo siguiente:

  • GET_MIN, GET_DEF solicitudes notificarán el campo dwValue establecido en 0.
  • GET_RES solicitud notificará el campo dwValue para que sea el mismo valor que el notificado por GET_MAX solicitud.
  • Cuando se recibe una solicitud de SET_CUR con dwValue establecido en 0, la cámara no generará ningún metadato. Cuando se recibe una solicitud de SET_CUR con dwValue establecido para que sea el mismo valor notificado por GET_MAX solicitud, la cámara puede generar metadatos y el tamaño de dichos metadatos no puede superar dwValue para cualquier fotograma.

Si el firmware no admite SET_CUR solicitud, se aplica lo siguiente:

  • GET_MIN, GET_DEF solicitudes notificarán al campo dwValue el mismo valor que la solicitud de GET_MAX.
  • GET_RES solicitud notificará el campo dwValue establecido en 0.
  • La cámara puede generar metadatos y el tamaño total de estos metadatos no puede superar dwValue , como se indica en la solicitud de GET_MAX, veces 1024 bytes menos el tamaño de una carga de metadatos de UsbVideoHeader , para cualquier fotograma.
  • Una carga de metadatos de UsbVideoHeader es sizeof(KSCAMERA_METADATA_ITEMHEADER) + sizeof(KSTREAM_UVC_METADATA) o 24 bytes.

Los metadatos generados se ajustarán a los metadatos de formato estándar de Microsoft descritos en la sección 2.2.3.

2.2.2.10 Ir Torch Control

Este control proporciona un medio flexible para que el hardware del LED de IR notifique la medida en que se puede controlar y proporciona la capacidad de controlarlo. Se trata de un control global que afecta a todos los puntos de conexión de todas las interfaces de streaming de vídeo asociadas a la interfaz de control de vídeo ajustando la potencia a una lámpara ir conectada a la cámara.

Este control se asigna a KSPROPERTY_CAMERACONTROL_EXTENDED_IRTORCHMODE por el controlador de cámara.

Control de antorcha I R.

Resultan aplicables los puntos siguientes:

  • GET_LEN solicitud notificará un valor de 8.
  • GET_INFO solicitud notificará un 3. Este valor indica un control sincrónico que admite GET_CUR y SET_CUR.
  • GET_MIN solicitud notificará el campo dwMode establecido en 0 y dwValue establecido en un valor que indique la potencia mínima. Un nivel de potencia de 0 puede indicar OFF, pero el nivel de energía operativo mínimo no necesita ser 0.
  • GET_RES solicitud notificará el campo dwMode establecido en 0 y dwValue establecerá en un número menor o igual que GET_MAX(dwValue): GET_MIN(dwValue) y de modo que GET_MAX(dwValue) – GET_MIN(dwValue) sea divisible uniformemente por ese valor. dwValue no puede ser cero (0).
  • GET_MAX solicitud notificará el campo dwMode establecido con bits D[0-2] establecido para identificar las capacidades de este control. dwMode debe tener el bit D0 establecido, lo que indica que se admite OFF y debe tener al menos otro conjunto de bits, lo que admite un estado activo. dwValue debe establecerse en un valor que indique la potencia normal.
  • GET_DEF solicitud notificará el campo dwMode establecido en el modo predeterminado en el que debe estar el sistema antes de que comience el streaming. dwMode debe establecerse en 2 (ON) o 4 (ALTERNATING). dwValue debe establecerse en el nivel de energía que se usa normalmente para el control FaceAuth. dwValue se define mediante el fabricante.
  • GET_CUR solicitud notificará el campo dwMode establecido en el modo de funcionamiento actual y dwValue establecido en la iluminación actual.
  • Cuando se recibe una solicitud de SET_CUR, el IR Torch establecerá la iluminación en una intensidad de prorateo mediante el modo de funcionamiento solicitado.

Ir Torch debe emitir el atributo MF_CAPTURE_METADATA_FRAME_ILLUMINATION para cada fotograma. Puede proporcionar esto a través de un MFT de dispositivo o mediante la inclusión de un atributo MetadataId_FrameIllumination en la carga de metadatos de la cámara. Consulte la sección 2.2.3.4.4.

El único propósito de estos metadatos es indicar si un marco está iluminado o no. Se trata de los mismos metadatos que requiere el KSPROPERTY_CAMERACONTROL_EXTENDED_FACEAUTH_MODE DDI y el MSXU_FACE_AUTHENTICATION_CONTROL definido en la sección 2.2.2.6.

2.2.2.11 Control de ventana digital

Ventana digital especifica el campo de vista y zoom de la cámara mientras la cámara está transmitiendo. Este control es un posible sustituto de Panorámica, Inclinación y Zoom. Este control solo se aplica mientras la cámara está transmitiendo activamente.

Este control está disponible para todos los tipos de cámaras y es independiente del tipo multimedia que se transmite.

Este control permite que el software host consulte y controle la ventana digital asociada a una cámara.

Se trata de un control global que afecta a todos los puntos de conexión de todas las interfaces de streaming de vídeo asociadas a la interfaz de control de vídeo. Ajusta el origen de los datos de píxeles utilizados por el ISP. Esto incluye el método 2 y el método 3 siguen capturando patillas.

Este control se asigna a KSPROPERTY_CAMERACONTROL_EXTENDED_DIGITALWINDOW por el controlador de cámara de la bandeja de entrada.

control de ventana digital.

Resultan aplicables los puntos siguientes:

  • GET_LEN solicitud notificará un valor de 16.

  • GET_INFO solicitud informará de 3. Este valor indica un control sincrónico que admite GET_CUR y SET_CUR.

  • GET_MIN solicitud notificará el campo dwMode establecido en 0, OriginX y OriginY establecido en 0.0 y WindowSize establecido en 1.0. Esta solicitud no se usa actualmente.

  • GET_RES solicitud notificará el campo dwMode establecido en 0, OriginX y OriginY establecido en 0.0 y WindowSize establecido en 1.0. Esta solicitud no se usa actualmente.

  • GET_MAX solicitud notificará el campo dwMode establecido con el bit D0 establecido para identificar las funcionalidades de este control. Un valor de 0 indica que solo se admite el modo manual. Un valor de 1 indica que se admite el modo de trama facial automática. Sin embargo, el resto de estos campos no se usan, se recomienda establecer OriginX y OriginY en 0,0 y WindowSize establecido en 1,0.

  • GET_DEF solicitud notificará el campo dwMode establecido en 0, OriginX y OriginY establecido en 0.0 y WindowSize establecido en 1.0. Esta es siempre la ventana predeterminada.

  • GET_CUR solicitud notificará el campo dwMode establecido en el modo de funcionamiento actual y OriginX, OriginY y WindowSize describirán la ventana digital actual.

  • Cuando se recibe una solicitud de SET_CUR, la cámara ajustará su campo de vista para que coincida con el modo de funcionamiento seleccionado y la ventana digital.

  • Si se selecciona el modo de trama facial automática, la cámara seleccionará una ventana que abarque completamente la cara dominante en la escena y se omitirán OriginX, OriginY y WindowSize pasados. Si no se encuentra ninguna cara, se usará la ventana predeterminada.

  • Cualquier cambio en la ventana digital debe reflejarse en la carga de metadatos de cada ejemplo.

  • Los cambios en la ventana digital no deben ser efectivos inmediatamente, pero el control debe responder inmediatamente. Los cambios en la ventana digital deben notificarse en la carga de metadatos del marco en cuanto entren en vigor.

2.2.2.12 Control de configuración de ventana digital

El control Digital Window Config Caps especifica los límites de escalado de la cámara dadas todas las resoluciones disponibles. Las resoluciones son independientes del tipo de medio, por lo que dos tipos multimedia que anuncian la misma resolución de pantalla se combinan en una sola funcionalidad.

Debido a las limitaciones de tamaño de un punto de conexión de control, este control puede describir como máximo 1820 resoluciones únicas.

Este control siempre debe estar disponible para notificar las funciones del control Ventana digital si ese control también está presente.

Este control se asigna a KSPROPERTY_CAMERACONTROL_EXTENDED_DIGITALWINDOW_CONFIGCAPS por el controlador de cámara de la bandeja de entrada.

control de configuración de ventana digital.

Resultan aplicables los puntos siguientes:

  • GET_LEN solicitud notificará el tamaño completo de la carga útil. El tamaño de carga debe tener un múltiplo de 36, ya que cada definición de resolución tiene una longitud de 36 bytes.

  • GET_INFO solicitud notificará un 1. Este valor indica un control sincrónico que solo admite GET_CUR.

  • GET_CUR solicitud notificará una matriz de capacidades. Los campos de la estructura de funcionalidad se definen anteriormente.

  • GET_MIN, GET_MAX, GET_RES y solicitudes de GET_DEF no se usan, pero deben devolver los mismos valores que GET_CUR.

  • no se admiten las solicitudes de SET_CUR.

2.2.2.13 Control HDR de vídeo

Este control permite al software host especificar si la cámara admite Video HDR. La compatibilidad con este control implica que la cámara es capaz de realizar video HDR como el mejor esfuerzo. Si la cámara no es compatible con Video HDR, no implementa este control.

Este control se asigna a KSPROPERTY_CAMERACONTROL_EXTENDED_VIDEOHDR por el controlador de cámara.

control de vídeo H D R.

Resultan aplicables los puntos siguientes:

  • GET_LEN solicitud notificará el tamaño completo de la carga útil. (por ejemplo, 4 bytes).

  • GET_INFO solicitud notificará un valor 3. Este valor indica un control sincrónico que admite GET_CUR, SET_CUR.

  • GET_CUR solicitud notificará el campo dwMode establecido en el modo de funcionamiento actual.

  • GET_DEF debe tener un dwMode establecido en OFF (0).

  • GET_MAX solicitud anunciará el soporte técnico para los modos de operaciones disponibles: [1 (ON/OFF), 3 (ON/OFF/Auto)]. La compatibilidad con ON (1) es obligatoria para este control.

  • GET_MIN y solicitudes de GET_RES notificarán 0.

  • SET_CUR solicitud debe establecer el modo en OFF (0), ON (1) o AUTO (2).

Metadatos de la versión 2.2.3

El diseño de los metadatos de fotogramas de formato estándar se basa en el diseño de metadatos personalizados uvC a partir de Windows 10. En Windows 10, los metadatos personalizados se admiten para UVC mediante un INF personalizado para el controlador de cámara (nota: el controlador de cámara se puede basar en la USBVIDEO.SYS de Windows, pero se requiere un INF personalizado para el hardware especificado para que los metadatos pasen). Si MetadataBufferSizeInKB<PinIndex> la entrada del Registro está presente y no es cero, se admiten metadatos personalizados para ese pin y el valor indica el tamaño del búfer usado para los metadatos. El <PinIndex> campo indica un índice basado en 0 del índice de patilla de vídeo.

En Windows 10, versión 1703, un controlador de cámara puede indicar compatibilidad con los metadatos de formato estándar de Microsoft incluyendo la siguiente entrada AddReg:

StandardFormatMetadata<PinIndex>: REG_DWORD: 0x0 (No compatible) a 0x1 (compatible)

DevProxy leerá esta clave del Registro e informará al controlador UVC de que los metadatos están en formato estándar estableciendo la marca KSSTREAM_METADATA_INFO_FLAG_STANDARDFORMAT en el campo Flags (Marcas) para KSSTREAM_METADATA_INFO estructura.

2.2.3.1 Metadatos de formato estándar de Microsoft

Los metadatos de formato estándar de Microsoft son una o varias instancias de la estructura siguiente:

metadatos de formato estándar.

typedef struct tagKSCAMERA_METADATA_ITEMHEADER {
    ULONG MetadataId;
    ULONG Size; // Size of this header + metadata payload following
} KSCAMERA_METADATA_ITEMHEADER, *PKSCAMERA_METADATA_ITEMHEADER;

El campo MetadataId se rellena mediante un identificador de la siguiente definición de enumeración que contiene identificadores bien definidos, así como identificadores personalizados (identificadores >= MetadataId_Custom_Start).

typedef enum {
    MetadataId_Standard_Start = 1,
    MetadataId_PhotoConfirmation = MetadataId_Standard_Start,
    MetadataId_UsbVideoHeader,
    MetadataId_CaptureStats,
    MetadataId_CameraExtrinsics,
    MetadataId_CameraIntrinsics,
    MetadataId_FrameIllumination,
    MetadataId_Standard_End = MetadataId_FrameIllumination,
    MetadataId_Custom_Start = 0x80000000,
} KSCAMERA_MetadataId;

El campo Tamaño se establece en sizeof(KSCAMERA_METADATA_ITEMHEADER) + sizeof(Metadata Payload).

2.2.3.2 Metadatos de formato estándar generados por firmware a partir de paquetes de fotogramas de vídeo USB

Durante una transferencia a través de UVC para el vídeo basado en fotogramas, el fotograma de vídeo se empaqueta en una serie de paquetes, cada uno precedido por un encabezado de carga UVC. Cada encabezado de carga UVC se define mediante la especificación de carga basada en fotogramas de controlador de clase de vídeo USB:

Encabezado de carga

A continuación se muestra una descripción del formato de encabezado de carga para los formatos basados en fotogramas.

encabezado de carga.

Campo HLE (longitud del encabezado)

El campo de longitud del encabezado especifica la longitud del encabezado, en bytes.

Campo de encabezado de campo de bits

FID: identificador de fotograma

  • Este bit alterna en cada límite de inicio de fotograma y permanece constante para el resto del marco.

EOF: Fin del marco

  • Este bit indica el final de un fotograma de vídeo y se establece en la última muestra de vídeo que pertenece a un fotograma. El uso de este bit es una optimización para reducir la latencia al finalizar una transferencia de fotogramas y es opcional.

PTS: Marca de tiempo de presentación

  • Este bit, cuando se establece, indica la presencia de un campo PTS.

SCR: Referencia del reloj de origen

  • Este bit, cuando se establece, indica la presencia de un campo SCR.

RES: Reservado.

  • Establecer en 0.

STI: Imagen fija

  • Este bit, cuando se establece, identifica un ejemplo de vídeo como perteneciente a una imagen fija.

ERR: Error Bit

  • Este bit, cuando se establece, indica un error en el streaming del dispositivo.

EOH: Fin del encabezado

  • Este bit, cuando se establece, indica el final de los campos BFH.

PTS: Marca de tiempo de presentación, Tamaño: 4 bytes, Valor: Número

  • El campo PTS está presente cuando el bit PTS se establece en el campo BFH[0]. Consulte la sección 2.4.3.3 "Encabezados de carga de imagen de vídeo y de imagen todavía" en la especificación de definición de clase de dispositivo USB para dispositivos de vídeo .

SCR: Referencia del reloj de origen, Tamaño: 6 bytes, Valor: Número

  • El campo SCR está presente cuando el bit SCR se establece en el campo BFH[0]. Consulte la sección 2.4.3.3 Encabezados de carga de imagen y vídeo en la especificación de definición de clase de dispositivo USB para dispositivos de vídeo .

El campo HLE del controlador UVC existente se fija en 2 bytes (no hay PTS/SCR presente) o hasta 12 bytes (PTS/SCR presentes). Sin embargo, el campo HLE, que es un campo de tamaño de byte, puede especificar potencialmente hasta 255 bytes de datos de encabezado. Si ambos PTS/SCR están presentes y el HLE es de más de 12 bytes, los datos adicionales que siguen a los primeros 12 bytes del encabezado de carga se seleccionan como metadatos estándar específicos del fotograma de vídeo cuando se establece la entrada StandardFormatMetadata<PinIndex> INF.

Los metadatos de formato estándar (generados por firmware) para un fotograma se obtienen mediante la concatenación de los blobs parciales que se encuentran en los paquetes de fotogramas de vídeo que representan ese fotograma.

paquetes de fotogramas de metadatos.

2.2.3.3 Búfer de metadatos proporcionado al componente en modo de usuario

El búfer de metadatos proporcionado al componente de modo de usuario tendría un elemento de metadatos para las marcas de tiempo UVC (generadas por el controlador UVC) seguidas de los elementos de metadatos generados por firmware y se establecen de la siguiente manera:

Búfer de metadatos.

2.2.3.4 Formato de metadatos para identificadores de metadatos estándar

El firmware puede elegir si se van a generar metadatos correspondientes a un identificador. Si el firmware elige generar metadatos correspondientes a un identificador, los metadatos del identificador estarán presentes en todos los fotogramas emitidos por el firmware.

2.2.3.4.1 MetadataId_CaptureStats

El formato de metadatos para este identificador se define mediante la estructura siguiente:

typedef struct tagKSCAMERA_METADATA_CAPTURESTATS {
    KSCAMERA_METADATA_ITEMHEADER Header;
    ULONG Flags;
    ULONG Reserved;
    ULONGLONG ExposureTime;
    ULONGLONG ExposureCompensationFlags;
    LONG ExposureCompensationValue;
    ULONG IsoSpeed;
    ULONG FocusState;
    ULONG LensPosition; // a.k.a Focus
    ULONG WhiteBalance;
    ULONG Flash;
    ULONG FlashPower;
    ULONG ZoomFactor;
    ULONGLONG SceneMode;
    ULONGLONG SensorFramerate;
} KSCAMERA_METADATA_CAPTURESTATS, *PKSCAMERA_METADATA_CAPTURESTATS;

El campo Marcas indica cuáles de los campos posteriores de la estructura se rellenan y tienen datos válidos. El campo Marcas no variará de marco a marco. Actualmente, se definen las marcas siguientes:

#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_EXPOSURETIME            0x00000001
#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_EXPOSURECOMPENSATION    0x00000002
#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_ISOSPEED                0x00000004
#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_FOCUSSTATE              0x00000008
#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_LENSPOSITION            0x00000010
#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_WHITEBALANCE            0x00000020
#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_FLASH                   0x00000040
#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_FLASHPOWER              0x00000080
#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_ZOOMFACTOR              0x00000100
#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_SCENEMODE               0x00000200
#define KSCAMERA_METADATA_CAPTURESTATS_FLAG_SENSORFRAMERATE         0x00000400

El campo Reservado está reservado para el futuro y se establecerá en 0.

El campo ExposureTime contiene el tiempo de exposición, en 100ns, aplicado al sensor cuando se capturó el fotograma. Esto se mostrará como atributo MF_CAPTURE_METADATA_EXPOSURE_TIME en el ejemplo MF correspondiente.

El campo ExposureCompensationFlags contiene el paso de compensación ev (se establecerá exactamente una de las marcas de paso de KSCAMERA_EXTENDEDPROP_EVCOMP_XXX) para transmitir el valor de compensación de EV. El campo ExposureCompensationValue contiene el valor de compensación ev en unidades del paso aplicado al sensor cuando se capturó el marco. Se mostrarán como atributos MF_CAPTURE_METADATA_EXPOSURE_COMPENSATION en el ejemplo MF correspondiente.

El campo IsoSpeed contiene el valor de velocidad ISO aplicado al sensor cuando se capturó el marco. Esto no es unitario. Esto se mostrará como atributo MF_CAPTURE_METADATA_ISO_SPEED en el ejemplo MF correspondiente.

El campo FocusState contiene el estado de foco actual que puede tomar uno de los valores definidos en la enumeración KSCAMERA_EXTENDEDPROP_FOCUSSTATE. Esto se mostrará como atributo MF_CAPTURE_METADATA_FOCUSSTATE en el ejemplo MF correspondiente.

El campo LensPosition contiene la posición lógica de la lente cuando se capturó el marco, que no es unitaria. Este es el mismo valor que se puede consultar desde KSPROPERTY_CAMERACONTROL_EXTENDED_FOCUS en una llamada GET. Esto se mostrará como atributo MF_CAPTURE_METADATA_LENS_POSITION en el ejemplo MF correspondiente.

El campo WhiteBalance contiene el balance de blancos aplicado al sensor cuando se capturó el marco, que es un valor de Kelvin. Esto se mostrará como atributo MF_CAPTURE_METADATA_WHITEBALANCE en el ejemplo MF correspondiente.

El campo Flash contiene un valor booleano con 1 significado flash encendido y 0 significado flash off, cuando se capturó el fotograma. Esto se mostrará como atributo MF_CAPTURE_METADATA_FLASH en el ejemplo MF correspondiente.

El campo FlashPower contiene la potencia flash aplicada al marco capturado, que es un valor en el intervalo de [0, 100]. Este campo debe omitirse si el controlador no admite la alimentación ajustable para flash. Esto se mostrará como atributo MF_CAPTURE_METADATA_FLASH_POWER en el ejemplo MF correspondiente.

El campo ZoomFactor contiene el valor de zoom en formato Q16 aplicado al fotograma capturado. Esto se mostrará como atributo MF_CAPTURE_METADATA_ZOOMFACTOR en el ejemplo MF correspondiente.

El campo SceneMode contiene el modo de escena aplicado al marco capturado, que es una marca de KSCAMERA_EXTENDEDPROP_SCENEMODE_XXX de 64 bits. Esto se mostrará como atributo MF_CAPTURE_METADATA_SCENE_MODE en el ejemplo MF correspondiente.

El campo SensorFramerate contiene la velocidad de lectura del sensor medido en hercios cuando se captura el fotograma, que consta de un valor numerador en la parte superior de 32 bits y un valor de denominador en el bit inferior de 32 bits. Esto se mostrará como atributo MF_CAPTURE_METADATA_SENSORFRAMERATE en el ejemplo MF correspondiente.

2.2.3.4.2 MetadataId_CameraExtrinsics

El formato de metadatos de este identificador implica el KSCAMERA_METADATA_ITEMHEADER estándar seguido de una carga de matriz de bytes. La carga debe alinearse con una estructura MFCameraExtrinsics seguida de cero o más estructuras MFCameraExtrinsic_CalibratedTransform . La carga debe estar alineada con 8 bytes y todos los bytes no utilizados se producirán al final de la carga y se establecerán en 0.

2.2.3.4.3 MetadataId_CameraIntrinsics

El formato de metadatos de este identificador implica el KSCAMERA_METADATA_ITEMHEADER estándar seguido de una carga de matriz de bytes. La carga debe alinearse con una estructura MFPinholeCameraIntrinsics . La carga debe estar alineada con 8 bytes y todos los bytes no utilizados se producirán al final de la carga y se establecerán en 0.

2.2.3.4.4 MetadataId_FrameIllumination

El formato de metadatos para este identificador se define mediante la estructura siguiente:

typedef struct tagKSCAMERA_METADATA_FRAMEILLUMINATION {
    KSCAMERA_METADATA_ITEMHEADER Header;
    ULONG Flags;
    ULONG Reserved;
} KSCAMERA_METADATA_FRAMEILLUMINATION, *PKSCAMERA_METADATA_FRAMEILLUMINATION;

El campo Marcas indica información sobre el marco capturado. Actualmente, se definen las marcas siguientes:

#define KSCAMERA_METADATA_FRAMEILLUMINATION_FLAG_ON 0x00000001

Si se captura un marco cuando la iluminación estaba activada, se establecerá la marca KSCAMERA_METADATA_FRAMEILLUMINATION_FLAG_ON. De lo contrario, no se establecerá esta marca.

El campo Reservado está reservado para uso futuro y se establecerá en 0.

Ejemplo:

Por ejemplo, una estructura de KSCAMERA_METADATA_FRAMEILLUMINATION que indica que la iluminación estaba activada sería la siguiente:

KSCAMERA_METADATA_FRAMEILLUMINATION.Header.MetadataId = MetadataId_FrameIllumination;
KSCAMERA_METADATA_FRAMEILLUMINATION.Header.Size = 16; // 4 ULONG variables in total inside the structure
KSCAMERA_METADATA_FRAMEILLUMINATION.Flags = KSCAMERA_METADATA_FRAMEILLUMINATION_FLAG_ON;
KSCAMERA_METADATA_FRAMEILLUMINATION.Reserved = 0;
2.2.3.4.5 MetadataId_USBVideoHeader

El formato de metadatos de este identificador se define mediante un KSCAMERA_METADATA_ITEMHEADER común seguido de una estructura de KSSTREAM_UVC_METADATA:

typedef struct
{
    ULONG       PresentationTimeStamp;
    ULONG       SourceClockReference;
    union
    {
        struct
        {
            USHORT    Counter : 11;
            USHORT  Reserved : 5;
        };
        USHORT    SCRToken;
    };
    USHORT      Reserved0;
    ULONG       Reserved1;
} KSSTREAM_UVC_METADATATYPE_TIMESTAMP, *PKSSTREAM_UVC_METADATATYPE_TIMESTAMP;

typedef struct {
    KSSTREAM_UVC_METADATATYPE_TIMESTAMP StartOfFrameTimestamp;
    KSSTREAM_UVC_METADATATYPE_TIMESTAMP EndOfFrameTimestamp;
} KSSTREAM_UVC_METADATA, *PKSSTREAM_UVC_METADATA;

El campo StartOfFrameTimestamp y EndOfFrameTimestamp son las marcas de tiempo contenidas en los encabezados UVC en las cargas DE UVC primera y última emitidas por la cámara para construir este fotograma.

Este dispositivo no debe enviar esta carga.

Esta carga de metadatos es única en que es la única carga de metadatos generada directamente por el controlador de clase de vídeo USB a partir de información obtenida de encabezados de carga compatibles con UVC.

Esta carga se antepone al búfer de metadatos de cada fotograma.

Si el dispositivo admite metadatos estandarizados, debe incluir el espacio necesario para almacenar esta carga en sus requisitos de búfer según lo notificado por el control metadatos definido en la sección 2.2.2.9.