Extensões da Microsoft para USB Video Class 1.5 especificação

1 Visão geral

1.1 Resumo

As extensões da Microsoft para a especificação USB Video Class permitem novos controles e a capacidade de transportar metadados de quadro bem definidos em um formato padrão.

1.2 Decisões de arquitetura

O suporte a metadados de quadro da USB Video Class (UVC) está disponível para os pontos finais ISOCH e BULK. No entanto, no caso do ponto de extremidade BULK, o tamanho dos metadados é limitado a 240 bytes (porque todos os dados de quadro de vídeo são transferidos em um único pacote de quadro de vídeo em pontos de extremidade BULK).

O suporte a metadados UVC só está disponível para cargas úteis baseadas em quadros.

O suporte a metadados UVC está disponível somente por meio do pipeline de captura do Media Foundation (MF).

Os metadados UVC são de adesão voluntária. Cada IHV/OEM que precisa de suporte a metadados deve ser habilitado por meio de um arquivo INF personalizado.

Os metadados UVC suportam apenas a memória alocada pelo sistema. As superfícies VRAM ou DX não serão suportadas.

2 Visão geral da arquitetura

2.1 Descrição

2.2.1 Descoberta de capacidade através do INF

2.2.1.1 Captura de imagem estática – Método 2

Alguns dispositivos UVC existentes podem não suportar o Método 2 descrito na seção 2.4.2.4 (Captura de Imagem Fixa) do UVC 1.5 Class specification.pdf que pode ser baixado no site da especificação da classe de vídeo USB.

No Windows 10, versão 1607 e anteriores, o pipeline de captura não usava o Método 2, mesmo que um dispositivo anunciasse suporte para ele de acordo com a especificação UVC 1.5.

No Windows 10, versão 1703, os dispositivos que usam esse método devem usar um arquivo INF personalizado para o driver da câmera, mas um INF personalizado é necessário para o hardware fornecido para habilitar o método 2 captura de imagem estática).

Nota: O driver da câmera pode ser baseado no Windows USBVIDEO.SYS ou pode ser baseado em um binário de driver personalizado.

O arquivo INF personalizado, baseado no driver UVC personalizado ou no driver UVC da caixa de entrada, deve incluir a seguinte entrada AddReg:

EnableDependentStillPinCapture: REG_DWORD: 0x0 (desativado) a 0x1 (habilitado)

Quando esta entrada é definida como Ativado (0x1), o pipeline de captura usa o Método 2 para Captura de Imagem Estática (assumindo que o firmware também anuncia suporte para o Método 2, conforme especificado pela especificação UVC 1.5).

Um exemplo para a seção INF personalizada seria o seguinte:

[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 Controlos unitários de extensão

A extensão da Microsoft para a especificação USB Video Class para ativar novos controlos é realizada por meio de uma unidade de extensão identificada pelo GUID MS_CAMERA_CONTROL_XU (referido como Microsoft-XU).

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

Um Microsoft-XU implementado pelo firmware do dispositivo abriga os novos controles definidos nas subseções a seguir. As seguintes definições de solicitação aplicam-se a todos esses controles, a menos que uma definição predominante seja especificada explicitamente para esse controle. Consulte UVC 1.5 Classe specification.pdf para obter as definições de D3, D4, GET_INFO e assim por diante.

GET_INFO requisição deve comunicar o controlo sem as capacidades AutoUpdate e Assíncronas (por exemplo, os bits D3 e D4 devem ser definidos como 0).

GET_LEN requisição deverá reportar o comprimento máximo da carga útil para este controlo (wLength).

GET_RES pedido deverá comunicar a resolução (passo) para qwValue/dwValue. Todos os outros campos são fixados em 0.

GET_MIN pedido deve indicar o valor mínimo suportado para qwValue/dwValue. Todos os outros campos são fixados em 0.

O pedido GET_MAX deve relatar o valor máximo suportado para qwValue/dwValue. Além disso, todos os sinalizadores suportados devem ser definidos como 1 em bmControlFlags. Todos os outros campos são fixados em 0.

GET_DEF e GET_CUR solicitações devem relatar as configurações padrão e atual, respectivamente, para os campos qwValue/dwValue e bmControlFlags. Todos os outros campos são fixados em 0.

Uma solicitação de SET_CUR é emitida pelo host depois de definir todos os campos.

A tabela a seguir mapeia os seletores de controle para Microsoft-XU para seus respetivos valores e a posição de bit para o campo bmControls no Descritor de Unidade de Extensão:

2.2.2.1 Controlos canceláveis

Um controle Cancelável é definido aqui usando o recurso Autoupdate.

O pedido GET_INFO deve relatar esse controlo como um controlo de atualização automática (por exemplo, o bit D3 deve ser definido como 1), mas não como um controlo assíncrono (por exemplo, o bit D4 deve ser definido como 0).

Para esse controle, uma solicitação SET_CUR pode ser emitida para definir um novo valor (uma solicitação SET_CUR(NORMAL) em que bmOperationFlags:D0 bit é definido como 0) ou cancelar uma solicitação SET_CUR(NORMAL) anterior (uma solicitação SET_CUR(CANCEL) em que bmOperationFlags:D0 bit é definido como 1). Uma solicitação de SET_CUR deve ser concluída pelo dispositivo imediatamente assim que a solicitação for recebida (mesmo que o hardware não esteja configurado ou convergido para as novas configurações solicitadas). Para cada solicitação SET_CUR(NORMAL), o dispositivo gera uma interrupção de Alteração de Controle correspondente para esse controlo, acionada quando as novas configurações são aplicadas ou quando chega uma solicitação SET_CUR(CANCEL); até que a referida interrupção ocorra, a solicitação SET_CUR(NORMAL) é considerada em andamento. Quando um pedido de SET_CUR(NORMAL) estiver em curso, os pedidos de SET_CUR(NORMAL) adicionais para este controlo específico resultarão numa falha. Um pedido de SET_CUR(CANCELAR) será sempre bem-sucedido. Se não houver nada para cancelar, então o dispositivo simplesmente não faz nada.

A carga útil de interrupção da Mudança de Controlo deve ter o bit bmOperationFlags:D0 configurado para 0 se as definições especificadas por SET_CUR(NORMAL) foram aplicadas (por exemplo, a convergência ocorreu) e configurado para 1 se as definições não foram aplicadas devido a uma solicitação SET_CUR(CANCEL) que ocorreu após a solicitação SET_CUR(NORMAL) (por exemplo, a convergência ainda não ocorreu).

2.2.2.2 Controlo da focagem

Este controlo permite que o software anfitrião especifique as configurações de foco para a câmera. Este é um controle global que afeta todos os pontos finais em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo.

Este controlo deve funcionar como um controlo cancelável (ver secção 2.2.2.1 para requisitos do pedido GET_INFO e comportamento funcional do pedido SET_CUR).

GET_MAX requisito: Este controle deve anunciar o suporte para bits D0, D1, D2, D8 e D18 em bmControlFlags.

GET_DEF requisito: O padrão para bmControlFlags deve ser D0 e D18 definido como 1 e dwValue definido como 0.

Para solicitações GET_CUR/SET_CUR, as seguintes restrições se aplicam ao campo bmControlFlags:

• Entre os bits D0, D1 e D8, apenas um bit pode ser definido; nenhum deles sendo definido também é válido se o bit D2 estiver definido.

• Entre D16, D17, D18, D19 e D20, apenas um bit pode ser definido, nenhum deles sendo definido é válido também.

• D1 é incompatível com todos os outros bits atualmente definidos (D0, D2, D8, D16, D17, D18, D19 e D20).

• D2 é incompatível com D1 e D8.

• D2 é incompatível com D16, D17, D18, D19 e D20 se D0 não estiver definido.

2.2.2.3 Controlo da exposição

Este controlo permite que o software host especifique as configurações de exposição da câmara. Este é um controle global que afeta todos os pontos finais em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo.

GET_INFO solicitação deve relatar esse controle como um controle assíncrono (por exemplo, o bit D4 deve ser definido como 1), mas não como um controle AutoUpdate (por exemplo, o bit D3 deve ser definido como 0).

GET_MAX requisito: Este controle deve anunciar o suporte para bits D0, D1 e D2 em bmControlFlags.

GET_DEF requisito: O padrão para bmControlFlags deve ser D0 definido como 1 e qwValue definido como 0.

Para solicitações GET_CUR/SET_CUR, as seguintes restrições se aplicam ao campo bmControlFlags:

• Entre os bits D0, D1 e D2, deve ser definido pelo menos um bit.
• D1 é incompatível com D0 e D2.

2.2.2.4 Controlo de compensação EV

Este controlo permite ao software anfitrião especificar as configurações de compensação de exposição (EV) para a câmera. Este é um controle global que afeta todos os pontos finais em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo.

GET_INFO solicitação deve relatar esse controle como um controle assíncrono (por exemplo, o bit D4 deve ser definido como 1), mas não como um controle AutoUpdate (por exemplo, o bit D3 deve ser definido como 0).

O pedido GET_RES deve reportar todas as resoluções suportadas ("step-size") definindo os bits correspondentes em bmControlFlags. Todos os outros campos são fixados em 0.

GET_MIN e GET_MAX solicitações devem informar o valor mínimo e máximo suportado para dwValue. O bit D4 (indicando um tamanho de passo de 1) deve ser o único bit definido em bmControlFlags. Todos os outros campos são fixados em 0.

GET_DEF, GET_CUR, SET_CUR solicitações devem seguir as definições da seção 2.2.2.1, mas devem ter um e apenas um bit definido entre D0, D1, D2, D3 e D4 bits para o campo bmControlFlags. Além disso, GET_DEF pedido deve ter dwValue definido como 0.

2.2.2.5 Controlo do balanço de brancos

Este controle permite ao software anfitrião especificar as configurações de balanço de branco da câmera. Este é um controle global que afeta todos os pontos finais em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo.

GET_INFO solicitação deve relatar esse controle como um controle assíncrono (por exemplo, o bit D4 deve ser definido como 1), mas não como um controle AutoUpdate (por exemplo, o bit D3 deve ser definido como 0).

GET_RES, GET_MIN GET_MAX pedidos devem seguir as definições do ponto 2.2.2.1, mas devem ter dwValueFormat definido como 1.

GET_MAX requisito: Este controle deve anunciar o suporte para bits D0, D1 e D2 em bmControlFlags.

GET_DEF requisito: O padrão para bmControlFlags deve ser D0 definido como 1 e dwValueFormat e dwValue definidos como 0.

Para solicitações GET_CUR/SET_CUR, as seguintes restrições se aplicam ao campo bmControlFlags:

• Entre os bits D0, D1 e D2, deve ser definido pelo menos um bit.
• D1 é incompatível com D0 e D2.

2.2.2.6 Controlo de autenticação facial

Esse controle permite que o software host especifique se a câmera suporta modos de streaming que são usados para autenticação facial. Suporte para este controle implica que a câmera é capaz de autenticação facial. Este controlo não deve ser apoiado de outro modo.

Este controle só é aplicável a câmeras que podem produzir dados Infra-Red (IR) e só é aplicável às interfaces de streaming especificadas (que é um subconjunto de todas as interfaces de streaming de vídeo associadas com a interface de controle de vídeo).

GET_RES e GET_MIN solicitações devem informar o campo bNumEntries definido como 0 e, portanto, não têm campos adicionais.

Para uma solicitação GET_MAX, um bit definido como 1 no campo bmControlFlags indica que o modo correspondente é suportado para essa interface de streaming. Uma saída de solicitação GET_MAX deve listar todas e apenas as interfaces de streaming capazes de D1 ou D2 (por exemplo, se uma interface de streaming é capaz de D1 ou D2, ela é listada; caso contrário, ela não é listada). Além disso, não deve ser anunciada nenhuma interface de streaming como sendo capaz de suportar tanto D1 quanto D2. Se uma interface de transmissão também se destinar a ser utilizada de uma forma geral (por exemplo, fora da finalidade da autenticação facial), D0 deve ser definido como 1 para essa interface de transmissão (para além de D1/D2).

Para solicitações GET_DEF / GET_CUR / SET_CUR, um bit definido como 1 no campo bmControlFlags indica que o modo correspondente é escolhido para essa interface de streaming. Nessas solicitações, um e apenas um bit (entre D0, D1 e D2) deve ser definido para uma interface de streaming específica. Para a solicitação de GET_DEF que retorna a opção padrão (que é específica da implementação), se uma interface de streaming também for destinada ao uso de uma maneira geral (por exemplo, fora da finalidade de autenticação facial), D0 deve ser definido como 1 por padrão nessa interface de streaming; caso contrário, D1 ou D2 (mas não ambos) devem ser definidos como 1 por defeito. Uma saída de solicitação GET_DEF/GET_CUR deve conter informações sobre todas as interfaces de streaming listadas na saída do pedido GET_MAX; no entanto, uma solicitação de SET_CUR só pode incluir um subconjunto das interfaces de streaming listadas na saída do pedido GET_MAX.

Exemplo:

Vamos supor que uma câmera tem quatro interfaces de streaming de vídeo com números 0x03, 0x05, 0x08 e 0x0b respectivamente, em que a interface de streaming de vídeo 0x05 produz dados RGB e as três interfaces de streaming de vídeo restantes produzem dados IR. Entre as interfaces de streaming que produzem dados IR, vamos supor que as interfaces de streaming 0x03 e 0x0b são capazes de D1, mas a interface de streaming 0x03 também é capaz de D0. Neste exemplo, o controle de autenticação facial só é aplicável às interfaces de streaming numeradas 0x03 e 0x0b e, portanto, apenas essas interfaces aparecem nas solicitações.

A saída para o pedido GET_MAX deverá ser a seguinte:

A saída para o pedido GET_DEF deve ser a seguinte:

Uma solicitação SET_CUR para alterar a configuração na interface de streaming 0x03 para D1 seria a seguinte:

A saída para um pedido de GET_CUR após o pedido de SET_CUR acima referido será a seguinte:

2.2.2.7 Controlo dos Parâmetros Externos da Câmara

Este controlo permite ao software host obter os dados extrínsecos da câmara para pontos terminais em interfaces de streaming de vídeo associadas à interface de controlo de vídeo. Os dados assim obtidos para cada ponto de extremidade aparecem como atributo MFStreamExtension_CameraExtrinsics no armazenamento de atributos para o fluxo correspondente (obtidos usando a chamada IMFDeviceTransform::GetOutputStreamAttributes).

GET_RES, GET_MIN, GET_MAX GET_CUR solicitações devem relatar o campo bNumEntries definido como 0 e, portanto, não têm campos adicionais.

O pedido GET_DEF deve listar todos os endpoints que têm as informações extrínsecas disponíveis.

Exemplo:

Vamos supor que uma câmera tenha três interfaces de streaming de vídeo com números 0x03, 0x05 e 0x08 respectivamente, em que a interface de streaming de vídeo 0x05 suporta captura de imagem estática usando o método 2, além da captura de vídeo suportada por todas as interfaces de streaming de vídeo. Entre essas interfaces de streaming, vamos supor que as interfaces de streaming 0x05 e 0x08 têm informações extrínsecas disponíveis, enquanto a interface de streaming 0x03 não tem as informações extrínsecas disponíveis.

Neste exemplo, a saída para GET_DEF solicitação deve ser a seguinte:

2.2.2.8 Controlo dos Parâmetros Intrínsecos da Câmara

Este controlo permite que o software host obtenha os dados intrínsecos da câmara para pontos finais em interfaces de streaming de vídeo associadas à interface de controlo de vídeo. Os dados assim obtidos para cada terminal aparecem como o atributo MFStreamExtension_PinholeCameraIntrinsics no repositório de atributos para o fluxo correspondente (obtidos usando a chamada IMFDeviceTransform::GetOutputStreamAttributes).

GET_RES, GET_MIN, GET_MAX GET_CUR solicitações devem relatar o campo bNumEntries definido como 0 e, portanto, não têm campos adicionais.

GET_DEF pedido deve enumerar todos os pontos finais com as informações intrínsecas disponíveis.

Exemplo:

Vamos supor que uma câmera tenha três interfaces de streaming de vídeo com números 0x03, 0x05 e 0x08 respectivamente, em que a interface de streaming de vídeo 0x05 suporta captura de imagem estática usando o método 2, além da captura de vídeo suportada por todas as interfaces de streaming de vídeo. Entre essas interfaces de streaming, vamos supor que as interfaces de streaming 0x05 e 0x08 têm informações intrínsecas disponíveis, enquanto a interface de streaming 0x03 não tem as informações intrínsecas disponíveis.

Neste exemplo, a saída para GET_DEF solicitação deve ser a seguinte:

2.2.2.9 Controlo de metadados

Este controlo permite que o software anfitrião consulte e controle os metadados produzidos pela câmara. Este é um controle global que afeta todos os pontos finais em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo.

Este controlador é mapeado para KSPROPERTY_CAMERACONTROL_EXTENDED_METADATA pelo controlador da câmera.

Caso o pedido SET_CUR seja suportado pelo firmware, aplica-se o seguinte:

• Os pedidos GET_MIN e GET_DEF devem indicar que o campo dwValue está definido como 0.

• O pedido GET_RES deve reportar o campo dwValue como sendo o mesmo valor reportado pelo pedido GET_MAX.

• Quando um pedido de SET_CUR é recebido com dwValue definido como 0, a câmara não deve produzir quaisquer metadados. Quando uma solicitação de SET_CUR é recebida com dwValue definido para ser o mesmo valor relatado por GET_MAX solicitação, a câmera pode produzir metadados e o tamanho desses metadados não pode exceder dwValue para qualquer quadro.

Se o pedido SET_CUR não for suportado pelo firmware, aplica-se o seguinte:

• As requisições GET_MIN e GET_DEF devem indicar o campo dwValue como sendo o mesmo valor comunicado pelo pedido GET_MAX.

• GET_RES requisição deve reportar o campo dwValue definido como 0.

• A câmera pode produzir metadados e o tamanho total desses metadados não pode exceder o dwValue - conforme relatado pela solicitação GET_MAX - multiplicado por 1024 bytes, menos o tamanho de uma carga útil de metadados UsbVideoHeader, para qualquer quadro.

• Uma carga útil de metadados UsbVideoHeader é sizeof(KSCAMERA_METADATA_ITEMHEADER) + sizeof(KSTREAM_UVC_METADATA) ou 24 bytes.

Os metadados produzidos devem estar em conformidade com os metadados de formato padrão da Microsoft descritos na secção 2.2.3.

2.2.2.10 Controlo da tocha IR

Este controle fornece um meio flexível para o hardware IR LED para relatar a extensão em que ele pode ser controlado e fornece a capacidade de controlá-lo. Este é um controle global que afeta todos os pontos finais em todas as interfaces de streaming de vídeo associadas com a interface de controle de vídeo, ajustando a alimentação para uma lâmpada IR conectada à câmera.

Este controle é mapeado para KSPROPERTY_CAMERACONTROL_EXTENDED_IRTORCHMODE pelo driver da câmera.

Aplica-se o seguinte:

• A requisição GET_LEN deve relatar um valor de 8.

• O pedido GET_INFO deve relatar um valor de 3. Esse valor indica um controle síncrono que oferece suporte a GET_CUR e SET_CUR.

• O pedido GET_MIN deve relatar o campo dwMode definido como 0 e dwValue definido como um valor que indique a potência mínima. Um nível de potência de 0 pode indicar OFF, mas o nível mínimo de potência operacional não precisa ser 0.

• GET_RES solicitação deve relatar o campo dwMode definido como 0 e dwValue definido como um número menor ou igual a GET_MAX(dwValue) – GET_MIN(dwValue) e tal que GET_MAX(dwValue) – GET_MIN(dwValue) seja uniformemente divisível por esse valor. dwValue pode não ser zero (0).

• O pedido GET_MAX deve reportar o campo dwMode configurado com os bits D[0-2] definidos para identificar as capacidades deste controlo. dwMode deve ter bit D0 definido, indicando que OFF é suportado, e deve ter pelo menos um outro bit definido, suportando um estado ativo. dwValue deve ser definido como um valor que indique potência normal.

• A solicitação GET_DEF deve informar o campo dwMode configurado para o modo padrão em que o sistema deve estar antes do início do streaming. dwMode deve ser definido como 2 (ON) ou 4 (ALTERNATING). dwValue deve ser definido para o nível de potência normalmente usado para o controle FaceAuth. dwValue é definido pelo fabricante.

• O pedido GET_CUR deve relatar o campo dwMode definido para o modo de operação atual e dwValue definido para a iluminação atual.

• Quando uma solicitação de SET_CUR é recebida, a lanterna IR ajusta a iluminação para uma intensidade proporcional, usando o modo de operação solicitado.

A tocha IR deve emitir o atributo MF_CAPTURE_METADATA_FRAME_ILLUMINATION para cada quadro. Ele pode fornecer isso através de um MFT de dispositivo ou incluindo um atributo MetadataId_FrameIllumination na carga útil de metadados da câmera. Ver secção 2.2.3.4.4.

O único objetivo desses metadados é indicar se um quadro está iluminado ou não. Estes são os mesmos metadados exigidos pela DDI KSPROPERTY_CAMERACONTROL_EXTENDED_FACEAUTH_MODE e pelos MSXU_FACE_AUTHENTICATION_CONTROL definidos na secção 2.2.2.6.

2.2.2.11 Controlo digital de janelas

Digital Window especifica o campo de visão e zoom da câmera enquanto a câmera está transmitindo. Esse controle é um substituto potencial para Pan, Tilt e Zoom. Este controle aplica-se apenas enquanto a câmara está a transmitir ativamente.

Este controle está disponível para todos os tipos de câmeras e é independente do tipo de mídia que está sendo transmitido.

Este controlo permite que o software anfitrião consulte e controle a janela digital associada a uma câmara.

Este é um controle global que afeta todos os pontos finais em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo. Ajusta a fonte de dados de pixel usada pelo ISP. Isso inclui que o Método 2 e o Método 3 continuam a capturar pinos.

Esse controle é mapeado para KSPROPERTY_CAMERACONTROL_EXTENDED_DIGITALWINDOW pelo driver da câmera da caixa de entrada.

Aplica-se o seguinte:

• GET_LEN solicitação deve indicar o valor de 16.

• O pedido GET_INFO deve relatar um valor de 3. Esse valor indica um controle síncrono que oferece suporte a GET_CUR e SET_CUR.

• GET_MIN solicitação deve informar o campo dwMode definido como 0, OriginX e OriginY definido como 0,0 e WindowSize definido como 1,0. Esta solicitação não é usada no momento.

• GET_RES solicitação deve informar o campo dwMode definido como 0, OriginX e OriginY definido como 0.0 e WindowSize definido como 1.0. Esta solicitação não é usada no momento.

• O pedido GET_MAX deve informar o campo dwMode configurado com o bit D0 ativado para identificar as capacidades deste controlo. Um valor 0 indica que apenas o modo manual é suportado. Um valor de 1 indica que o modo de enquadramento facial automático é suportado. O restante desses campos não é usado, no entanto, recomendamos que OriginX e OriginY sejam definidos como 0.0 e WindowSize definidos como 1.0.

• GET_DEF solicitação deve informar o campo dwMode definido como 0, OriginX e OriginY definido como 0,0 e WindowSize definido como 1,0. Esta é sempre a janela padrão.

• O pedido GET_CUR deve relatar o campo dwMode definido para o modo de operação atual, e OriginX, OriginY e WindowSize descrevem a janela digital atual.

• Quando uma solicitação de SET_CUR é recebida, a câmera ajusta seu campo de visão para corresponder ao modo de operação selecionado e janela digital.

• Se o modo de enquadramento facial automático estiver selecionado, a câmera selecionará uma janela que engloba totalmente o rosto dominante na cena e os OriginX, OriginY e WindowSize passados serão ignorados. Se não for encontrada nenhuma face, será utilizada a janela padrão.

• Quaisquer alterações na janela digital devem ser refletidas na carga útil de metadados de cada amostra.

• As alterações na janela digital podem não ser imediatamente eficazes, mas o controlo deve responder imediatamente. As alterações na janela digital devem ser relatadas na carga de metadados do quadro assim que entrarem em vigor.

2.2.2.12 Controle de configuração de janela digital

O controle Digital Window Config Caps especifica os limites de escala da câmera dadas todas as resoluções disponíveis. As resoluções são independentes do tipo de mídia, portanto, dois tipos de mídia que anunciam a mesma resolução de exibição são combinados em um único recurso.

Devido às limitações de tamanho de um ponto de extremidade de controle, esse controle pode descrever no máximo 1820 resoluções exclusivas.

Esse controle deve estar sempre disponível para relatar os recursos do controle de janela digital se esse controle também estiver presente.

Esse controle é mapeado para KSPROPERTY_CAMERACONTROL_EXTENDED_DIGITALWINDOW_CONFIGCAPS pelo driver da câmera da caixa de entrada.

Aplica-se o seguinte:

• A requisição GET_LEN deve indicar o tamanho total da carga útil. O tamanho da carga útil deve ser um múltiplo de 36, pois cada definição de resolução tem 36 bytes de comprimento.

• O pedido GET_INFO deve reportar um 1. Esse valor indica um controle síncrono que suporta apenas GET_CUR.

• A requisição GET_CUR deve relatar um conjunto de capacidades. Os campos da estrutura de capacidade são definidos acima.

• GET_MIN, GET_MAX, GET_RES e GET_DEF solicitações não são usadas, mas devem retornar os mesmos valores que GET_CUR.

• SET_CUR solicitações não são suportadas.

2.2.2.13 Controlo HDR de vídeo

Este controlo permite que o software anfitrião especifique se a câmara suporta Vídeo HDR. O apoio a este controlador implica que a câmera é capaz de executar vídeo HDR com o melhor resultado possível. Se a câmera não suportar HDR de vídeo, então, ela não deve implementar esse controle.

Este controle é mapeado para KSPROPERTY_CAMERACONTROL_EXTENDED_VIDEOHDR pelo driver da câmera.

Aplica-se o seguinte:

• GET_LEN pedido deve indicar a dimensão total da carga útil (por exemplo, 4 bytes).

• A requisição GET_INFO deve indicar o valor 3. Esse valor indica um controle síncrono que oferece suporte a GET_CUR, SET_CUR.

• GET_CUR pedido deve comunicar o campo dwMode definido para o modo de funcionamento atual.

• GET_DEF deve ter um dwMode definido como OFF (0).

• GET_MAX pedido deve anunciar o suporte para os modos de operação disponíveis: [1 (ON/OFF), 3 (ON/OFF/Auto)]. O suporte para ON (1) é obrigatório para este controlo.

• Os pedidos GET_MIN e GET_RES devem comunicar 0.

• SET_CUR solicitação deve definir o modo como OFF (0), ON (1) ou AUTO (2).

2.2.2.14 Controlo da Velocidade da Taxa de Quadros

Esse controle permite que o software host especifique se a câmera suporta o acelerador Framerate.

Este controle aplica-se apenas enquanto a câmara está a transmitir ativamente. Para ser transmitido ativamente, significa que um pino de visualização ou registro deve estar em KSSTATE_RUN, pronto e capaz de entregar quadros. Em um conjunto, se um fluxo não estiver ativo, esse controle deverá retornar STATUS_INVALID_DEVICE_STATE.

Mesmo que este seja um controle de escopo de filtro, o controle de taxa de quadros não deve afetar o pin de foto ou fluxos sem RGB, como IR/profundidade. Além disso, quando o acelerador de taxa de quadros estiver em vigor, a duração da amostra também deve ser ajustada de acordo.

Este controle é mapeado para KSPROPERTY_CAMERACONTROL_EXTENDED_FRAMERATE_THROTTLE pelo driver da câmera.

Aplica-se o seguinte:

• GET_LEN pedido deve indicar a dimensão total da carga útil (por exemplo, 20 bytes). 

• A requisição GET_INFO deve indicar o valor 3. Esse valor indica um controle síncrono que oferece suporte a GET_CUR, SET_CUR. 

• O pedido GET_CUR deve relatar o campo dwMode definido para o modo de funcionamento atual e o scaleFactorPercentage definido para o valor atual do scaleFactor. Min, max, e step devem relatar os valores conforme descrito na tabela acima.

• GET_DEF deve ter um dwMode definido como OFF(0), scaleFactorPercentage=100, Min definido como valor mínimo padrão, max definido como 100 e, step definido como valor de etapa padrão. Os valores de min e step devem ser definidos pelo fabricante, mas devem seguir as orientações mencionadas na tabela acima.

• GET_ pedido MAX anunciará o suporte para os modos de operações disponíveis e informará o valor 1 [ ON | DESLIGADO ]. O suporte para ON e OFF é obrigatório para este controlo. Min, max, step e scaleFactorPercentage podem ser definidos como os valores padrão.

• Os pedidos GET_MIN e GET_RES devem comunicar 0. 

• SET_CUR solicitação deve definir o modo como OFF(0), ON(1). Se dwMode estiver definido como ON, scaleFactorPercentage entrará em vigor. Para ambos os casos OFF e ON, o scaleFactorPercentage deve ser válido conforme descrito na tabela acima.

2.2.2.15 Campo de Visão 2 Controlo de Configuração

O controle Field of View 2 Config especifica os valores de grau do Campo de Visão diagonal suportados como uma matriz de valores. Todos os valores suportados devem estar na faixa do mínimo teórico e máximo teórico, de 1 grau a 360 graus.

Se o dispositivo quiser oferecer suporte a valores contínuos de campo de visualização, ele precisará relatar todos os valores suportados. Por exemplo, se o dispositivo quiser suportar campo de visão diagonal de 85 graus - 60 graus com tamanho de passo de 1, este controle precisa relatar matriz de valores [85, 84, 83, 82, ..., 62, 61, 60].

Esse controle deve estar disponível para relatar os recursos quando o controle Campo de Visão 2 estiver presente.

Este é o controle de nível síncrono do filtro.

Este controle é mapeado para KSPROPERTY_CAMERACONTROL_EXTENDED_ FIELDOFVIEW2_CONFIGCAPS pelo driver da câmera.

Aplica-se o seguinte:

• A requisição GET_LEN deve indicar o tamanho total da carga útil.

• O pedido GET_INFO deve reportar um 1. Esse valor indica um controle síncrono que suporta apenas GET_CUR.

• GET_CUR pedido deve comunicar dados que contenham o FoV predefinido e uma lista de valores de FoV suportados por ordem decrescente. Os campos da estrutura são definidos acima.

• O pedido GET_DEF deve refletir o mesmo que o GET_CUR.

• GET_MIN, GET_MAX e GET_RES solicitações não são usadas, mas devem retornar os mesmos valores que GET_CUR.

• SET_CUR solicitações não são suportadas.

Os valores do campo de visão devem estar em ordem decrescente, por exemplo, o campo de visão mais amplo é o primeiro e o mais estreito é o último.

Controlo do Campo de Visão 2

Esse controle especifica o campo de visão base que a câmera está usando ao transmitir. Esse controle pode ser aplicado antes ou durante o streaming.

Este controle está disponível para todos os tipos de câmeras e é independente do tipo de mídia que está sendo transmitido.

Este controlo permite que o software host consulte e controle o campo de visão associado a uma câmera.

Este é um controle global que afeta todos os pontos finais em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo. Ele ajusta a fonte de dados de pixel (ou sensor) usados pelo ISP (Processador de Sinal de Imagem). Isso inclui que o Método 2 e o Método 3 continuam a capturar pinos.

Este é o controle de nível síncrono do filtro.

Este controle é mapeado para KSPROPERTY_CAMERACONTROL_EXTENDED_ FIELDOFVIEW2 pelo driver da câmera.

Aplica-se o seguinte:

• GET_LEN requisição deverá reportar um valor de 4.

• GET_INFO pedido deve comunicar um 3. Esse valor indica um controle síncrono que oferece suporte a GET_CUR e SET_CUR.

• O pedido GET_MIN deve relatar o campo dwValue definido para o valor mínimo suportado do Campo de Visão.

• O pedido GET_RES deve relatar o campo dwValue definido como 0. Esta solicitação não é usada no momento.

• O pedido GET_MAX deve comunicar o campo dwValue definido como o valor máximo suportado do Campo de Visão.

• O pedido GET_DEF deverá reportar o campo dwValue definido como o valor padrão do campo de visão.

• A solicitação GET_CUR deve reportar o campo dwValue definido como o valor atual do campo de visão.

• Quando uma solicitação de SET_CUR é recebida, a câmera define seu campo de visão para corresponder ao dwValue fornecido.

• Se a câmara implementar CT_ZOOM_RELATIVE_CONTROL e/ou CT_ZOOM_ABSOLUTE_CONTROL, estes controlos devem repor os seus valores predefinidos quando MSXU_CONTROL_FIELDOFVIEW2 SET_CUR é chamado.

Se a câmara implementar MSXU_CONTROL_DIGITALWINDOW, deve refletir a mudança de janela quando for definido um novo valor de campo de visão. E vice-versa, o Campo de Visão deve refletir as alterações efetuadas através da Janela Digital. Consulte KSPROPERTY_CAMERACONTROL_EXTENDED_ FIELDOFVIEW2 para obter detalhes.

2.2.3 Metadados

O design para metadados de quadro de formato padrão baseia-se no design de metadados personalizados UVC do Windows 10. No Windows 10, os metadados personalizados são suportados para UVC usando um INF personalizado para o driver da câmera (observação: o driver da câmera pode ser baseado no USBVIDEO.SYS do Windows, mas um INF personalizado é necessário para o hardware fornecido para que os metadados sejam transmitidos). Se MetadataBufferSizeInKB<PinIndex> a entrada do Registro estiver presente e for diferente de zero, os metadados personalizados serão suportados para esse pino e o valor indicará o tamanho do buffer usado para os metadados. O <PinIndex> campo indica um índice baseado em 0 do índice de pinos de vídeo.

No Windows 10, versão 1703, um driver de câmera pode sinalizar suporte para metadados de formato padrão da Microsoft incluindo a seguinte entrada AddReg:

StandardFormatMetadata<PinIndex>: REG_DWORD: 0x0 (NãoSuportado) para 0x1 (Suportado)

Essa chave de registo será lida pelo DevProxy e informa ao driver UVC que os metadados estão no formato padrão, definindo a bandeira KSSTREAM_METADATA_INFO_FLAG_STANDARDFORMAT no campo de sinalizadores para a estrutura KSSTREAM_METADATA_INFO.

2.2.3.1 Metadados de formato padrão da Microsoft

Os metadados de formato padrão da Microsoft são uma ou mais instâncias da seguinte estrutura:

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

O campo MetadataId é preenchido por um identificador da seguinte definição enum que contém identificadores bem definidos e 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;

O campo Tamanho é definido como sizeof(KSCAMERA_METADATA_ITEMHEADER) + sizeof(Metadata Payload).

2.2.3.2 Metadados de formato padrão gerados por firmware a partir de pacotes de quadros de vídeo USB

Durante uma transferência por UVC para vídeo baseado em fotogramas, o fotograma de vídeo é empacotado numa série de pacotes, cada um precedido por um cabeçalho de carga útil UVC. Cada conector de carga útil UVC é definido pela especificação USB Video Class Driver Frame Based Payload:

Cabeçalho de payload

A seguir está uma descrição do formato de cabeçalho de carga útil para formatos baseados em quadros.

Campo HLE (Comprimento do cabeçalho)

O campo comprimento do cabeçalho especifica o comprimento do cabeçalho, em bytes.

Campo de cabeçalho de bits

FID: Identificador de quadro

• Esse bit alterna em cada limite de início do quadro e permanece constante para o resto do quadro.

EOF: Fim do quadro

• Este bit indica o fim de um quadro de vídeo e é definido na última amostra de vídeo pertencente a um quadro. O uso desse bit é uma otimização para reduzir a latência na conclusão de uma transferência de quadro e é opcional.

PTS: Carimbo de Tempo de Apresentação

• Este bit, quando definido, indica a presença de um campo PTS.

SCR: Referência do relógio de origem

• Este bit, quando definido, indica a presença de um campo SCR.

RES: Reservado.

• Defina como 0.

STI: Imagem fixa

• Este bit, quando definido, identifica uma amostra de vídeo como pertencente a uma imagem fixa.

ERR: Bit de erro

• Este bit, quando definido, indica um erro no streaming do dispositivo.

EOH: Fim do cabeçalho

• Este bit, quando definido, indica o fim dos campos BFH.

PTS: Carimbo de Tempo de Apresentação, Tamanho: 4 bytes, Valor: Número

• O campo PTS está presente quando o bit PTS é definido no campo BFH[0]. Consulte a Secção 2.4.3.3 "Cabeçalhos de carga útil de vídeo e imagem fixa" na especificação de Definição de Classe de Dispositivo USB para Dispositivos de Vídeo.

SCR: Referência do relógio de origem, Tamanho: 6 bytes, Valor: Número

• O campo SCR está presente quando o bit SCR é definido no campo BFH[0]. Consulte a Seção 2.4.3.3 Cabeçalhos de carga útil de vídeo e imagem fixa na especificação Definição de classe de dispositivo USB para dispositivos de vídeo.

O campo HLE no driver UVC existente é fixado para 2 bytes (sem PTS/SCR presente) ou até 12 bytes (PTS/SCR presente). No entanto, o campo HLE, sendo um campo de tamanho de byte, pode potencialmente especificar até 255 bytes de dados de cabeçalho. Se ambos PTS/SCR estiverem presentes e o HLE for maior que 12 bytes, quaisquer dados adicionais após os primeiros 12 bytes do cabeçalho de carga útil são tratados como metadados padrão específicos do quadro de vídeo, se a entrada INF StandardFormatMetadata<PinIndex> estiver definida.

Os metadados de formato padrão (gerados pelo firmware) para um quadro são obtidos concatenando os blobs parciais encontrados nos pacotes de quadros de vídeo que representam esse quadro.

2.2.3.3 Buffer de metadados fornecido ao componente de modo de usuário

O buffer de metadados disponibilizado ao componente em modo utilizador incluiria um item de metadados para os carimbos de data/hora UVC (gerados pelo driver UVC), seguido por itens de metadados gerados pelo firmware, dispostos da seguinte maneira:

2.2.3.4 Formato dos metadados para identificadores de metadados normalizados

O firmware pode optar por produzir ou não metadados correspondentes a um identificador. Se o firmware optar por produzir metadados correspondentes a um identificador, os metadados desse identificador devem estar presentes em todos os quadros emitidos pelo firmware.

2.2.3.4.1 MetadataId_CaptureStats

O formato dos metadados para este identificador é definido pela seguinte estrutura:

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;

O campo Sinalizadores indica quais dos campos posteriores da estrutura estão preenchidos e têm dados válidos. O campo bandeiras não deve variar de frame para frame. Atualmente, são definidas as seguintes bandeiras:

#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

O campo Reservado é reservado para o futuro e deve ser definido como 0.

O campo ExposureTime contém o tempo de exposição, em 100 ns, aplicado ao sensor quando o quadro foi capturado. Isso aparece como atributo MF_CAPTURE_METADATA_EXPOSURE_TIME na amostra MF correspondente.

O campo ExposureCompensationFlags contém a etapa de compensação de EV (exatamente uma das bandeiras de etapa KSCAMERA_EXTENDEDPROP_EVCOMP_XXX deve estar definida) utilizada para comunicar o valor da compensação de EV. O campo ExposureCompensationValue contém o valor de compensação EV em unidades do passo aplicado ao sensor quando a imagem foi capturada. Estes aparecem como o atributo MF_CAPTURE_METADATA_EXPOSURE_COMPENSATION na amostra MF correspondente.

O campo IsoSpeed contém o valor de velocidade ISO aplicado ao sensor quando o quadro foi capturado. Isto não tem unidade. Isso aparece como atributo MF_CAPTURE_METADATA_ISO_SPEED na amostra MF correspondente.

O campo FocusState contém o estado de foco atual que pode assumir um dos valores definidos em enum KSCAMERA_EXTENDEDPROP_FOCUSSTATE. Isso aparece como atributo MF_CAPTURE_METADATA_FOCUSSTATE na amostra MF correspondente.

O campo LensPosition contém a posição lógica da lente quando o quadro foi capturado, que é sem unidade. Este é o mesmo valor que pode ser consultado a partir de KSPROPERTY_CAMERACONTROL_EXTENDED_FOCUS em uma chamada GET. Isso aparece como atributo MF_CAPTURE_METADATA_LENS_POSITION na amostra MF correspondente.

O campo WhiteBalance contém o balanço de branco aplicado ao sensor quando o quadro foi capturado, que é um valor em Kelvin. Isso aparece como o atributo MF_CAPTURE_METADATA_WHITEBALANCE na amostra MF correspondente.

O campo Flash contém um valor booleano com 1 significando flash ligado, e 0 significando flash desligado, quando o quadro foi capturado. Isso aparece como atributo MF_CAPTURE_METADATA_FLASH na amostra MF correspondente.

O campo FlashPower contém a potência de flash aplicada ao quadro capturado, que é um valor no intervalo de [0, 100]. Este campo deve ser omitido se o controlador não oferecer suporte a potência ajustável do flash. Isso aparece como atributo MF_CAPTURE_METADATA_FLASH_POWER na amostra MF correspondente.

O campo ZoomFactor contém o valor de zoom no formato Q16 aplicado ao quadro capturado. Isso aparece como atributo MF_CAPTURE_METADATA_ZOOMFACTOR na amostra MF correspondente.

O campo SceneMode contém o modo de cena aplicado ao quadro capturado, que é um sinalizador de KSCAMERA_EXTENDEDPROP_SCENEMODE_XXX de 64 bits. Isto aparece como atributo MF_CAPTURE_METADATA_SCENE_MODE na amostra MF correspondente.

O campo SensorFramerate contém a taxa de leitura do sensor medida em hertz quando o quadro é capturado, que consiste em um valor de numerador no 32 bit superior e um valor de denominador no 32 bit inferior. Isso aparece como atributo MF_CAPTURE_METADATA_SENSORFRAMERATE na amostra MF correspondente.

2.2.3.4.2 MetadataId_CameraExtrinsics

O formato de metadados para esse identificador envolve o KSCAMERA_METADATA_ITEMHEADER padrão seguido por uma carga útil de matriz de bytes. A carga útil deve estar alinhada com uma estrutura MFCameraExtrinsics, seguida por zero ou mais estruturas MFCameraExtrinsic_CalibratedTransform. A carga útil deve estar alinhada a 8 bytes e todos os bytes não utilizados devem ocorrer no final da carga útil e ser definidos para 0.

2.2.3.4.3 MetadataId_CameraIntrinsics

O formato de metadados para esse identificador envolve o KSCAMERA_METADATA_ITEMHEADER padrão seguido por uma carga útil de matriz de bytes. A carga útil deve estar alinhada a uma estrutura MFPinholeCameraIntrinsics. A carga útil deve estar alinhada a 8 bytes e todos os bytes não utilizados devem ocorrer no final da carga útil e ser definidos para 0.

2.2.3.4.4 MetadataId_IluminaçãoDoFrame

O formato dos metadados para este identificador é definido pela seguinte estrutura:

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

O campo Sinalizadores indica informações sobre o quadro capturado. Atualmente, são definidas as seguintes bandeiras:

#define KSCAMERA_METADATA_FRAMEILLUMINATION_FLAG_ON 0x00000001

Se um frame foi capturado quando a iluminação estava acesa, a bandeira KSCAMERA_METADATA_FRAMEILLUMINATION_FLAG_ON deve ser definida. Caso contrário, esta bandeira não será fixada.

O campo Reservado é reservado para uso futuro e deve ser definido como 0.

Exemplo:

Por exemplo, uma estrutura KSCAMERA_METADATA_FRAMEILLUMINATION indicando que a iluminação estava ligada seria a seguinte:

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

O formato dos metadados para este identificador é definido por um KSCAMERA_METADATA_ITEMHEADER comum seguido de uma estrutura 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;

Os campos StartOfFrameTimestamp e EndOfFrameTimestamp são as marcas temporais contidas nos cabeçalhos UVC na primeira e última carga útil UVC emitida pela câmara para compor esta imagem.

Esta carga útil não deve ser enviada por um dispositivo.

Esta carga útil de metadados é única na medida em que é a única carga útil de metadados gerada diretamente pelo driver de classe vídeo USB a partir de informações obtidas de cabeçalhos de carga útil compatíveis com UVC.

Essa carga útil é anexada ao buffer de metadados de cada quadro.

Se o dispositivo suportar metadados normalizados, deve incluir o espaço necessário para armazenar esta carga útil nos seus requisitos de memória intermédia, conforme comunicado pelo controlo de metadados definido no ponto 2.2.2.9.