Extensões da Microsoft à especificação da Classe de Vídeo USB 1.5

1 Visão geral

Resumo 1.1

As extensões da Microsoft para a especificação da Classe de Vídeo USB 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 Classe de Vídeo USB (UVC) está disponível para terminais ISOCH e BULK. No entanto, no caso do endpoint BULK, o tamanho dos metadados é limitado a 240 bytes (porque todos os dados do quadro de vídeo são transferidos em um único pacote de quadro de vídeo nesses endpoints).

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

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

Os metadados do UVC são opt-in. Cada IHV/OEM que precisa de suporte a metadados deve ser habilitado por meio de um arquivo INF personalizado.

Os metadados do UVC dão suporte apenas à memória alocada pelo sistema. Não haverá suporte para superfícies VRAM ou DX.

Visão geral da arquitetura 2

2.1 Descrição

2.2.1 Descoberta de funcionalidade por meio 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 Estática) do UVC 1.5 Class specification.pdf, que pode ser baixado no site da especificação da USB Video Class.

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

No Windows 10, versão 1703, dispositivos que utilizam esse método devem empregar um arquivo INF personalizado para o driver da câmera. Além disso, um INF personalizado é necessário para que o hardware especificado habilite a captura de imagem estática do Método 2.

Observação: 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, com base no driver UVC personalizado ou no driver UVC da caixa de entrada, deve incluir a seguinte entrada AddReg:

EnableDependentStillPinCapture: REG_DWORD: 0x0 (Desativado) até 0x1 (Ativado)

Quando essa entrada é definida como Habilitada (0x1), o pipeline de captura usa o Método 2 para Captura de Imagem Estática (supondo que o firmware também anuncie suporte para o Método 2, conforme especificado pela 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 Controles de unidade de extensão

A extensão da Microsoft para a especificação de Classe de Vídeo USB para habilitar novos controles é feita por meio de uma unidade de extensão identificada pelo GUID MS_CAMERA_CONTROL_XU (conhecida 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 definições de solicitação a seguir se aplicam a todos esses controles, a menos que uma definição de substituição seja especificada explicitamente para esse controle. Consulte Classe UVC 1.5 specification.pdf para definições de D3, D4, GET_INFO e assim por diante.

A solicitação GET_INFO deve relatar o controle sem recursos AutoUpdate e Assíncrono (por exemplo, os bits D3 e D4 devem ser definidos como 0).

GET_LEN requisição deve indicar o comprimento máximo do payload para esse controle (wLength).

A solicitação GET_RES deve relatar a resolução (passo) para qwValue/dwValue. Todos os outros campos devem ser definidos como 0.

GET_MIN solicitação deve relatar o valor mínimo com suporte para qwValue/dwValue. Todos os outros campos devem ser definidos como 0.

GET_MAX solicitação deve relatar o valor máximo com suporte para qwValue/dwValue. Além disso, todos os sinalizadores com suporte devem ser definidos como 1 em bmControlFlags. Todos os outros campos devem ser definidos como 0.

GET_DEF e GET_CUR solicitações devem relatar as configurações padrão e atuais, respectivamente, para os campos qwValue/dwValue e bmControlFlags. Todos os outros campos devem ser definidos como 0.

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

A tabela a seguir faz a correspondência dos seletores de controle para Microsoft-XU com seus respectivos valores e a posição do bit no campo bmControls no Descritor de Unidade de Extensão:

2.2.2.1 Controles canceláveis

Um controle cancelável é definido aqui usando a funcionalidade de Atualização Automática.

GET_INFO requisição deve relatar tal controle como um Controle de Atualização Automática (por exemplo, o bit D3 deve ser configurado para 1), mas não como um controle assíncrono (por exemplo, o bit D4 deve ser configurado para 0).

Para esse controle, uma solicitação SET_CUR pode ser emitida para definir um novo valor (uma solicitação SET_CUR(NORMAL) na qual bmOperationFlags:D0 bit está definido como 0) ou cancelar uma solicitação SET_CUR(NORMAL) anterior (uma solicitação SET_CUR(CANCEL) em que bmOperationFlags:D0 bit está definido como 1). Uma solicitação 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 produz uma interrupção de alteração de controle correspondente para esse controle gerado quando as novas configurações foram aplicadas ou quando uma solicitação SET_CUR(CANCEL) chega; até que essa interrupção chegue, a solicitação SET_CUR(NORMAL) é considerada em andamento. Quando uma solicitação SET_CUR(NORMAL) estiver em andamento, solicitações adicionais de SET_CUR(NORMAL) para esse controle específico resultarão em uma falha. Uma solicitação SET_CUR(CANCEL) sempre terá êxito. Se não houver nada para cancelar, o dispositivo não fará nada.

A carga de interrupção de alteração de controle deverá ter o bit bmOperationFlags:D0 definido como 0 se as configurações especificadas por SET_CUR(NORMAL) foram aplicadas (por exemplo, a convergência ocorreu) e definido como 1 se as configurações não foram aplicadas devido a uma solicitação SET_CUR(CANCEL) que veio após a solicitação SET_CUR(NORMAL) (por exemplo, a convergência ainda não ocorreu).

2.2.2.2 Controle de foco

Esse controle permite que o software host especifique as configurações de foco para a câmera. Esse é um controle global que afeta todos os endpoints em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo.

Esse controle deve funcionar como um Controle Cancelável (consulte a seção 2.2.2.1, para os requisitos de solicitação GET_INFO e o comportamento funcional da solicitação SET_CUR).

GET_MAX requisito: esse 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 de 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 será 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 também é válido.

• 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 Controle de exposição

Esse controle permite que o software host especifique as configurações de exposição para a câmera. Esse é um controle global que afeta todos os endpoints 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: esse controle deve anunciar o suporte para os bits D0, D1 e D2 no bmControlFlags.

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

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

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

2.2.2.4 Controle de compensação de EV

Esse controle permite que o software host especifique as configurações de compensação de EV para a câmera. Esse é um controle global que afeta todos os endpoints 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).

A solicitação GET_RES deverá relatará todas as resoluções suportadas (tamanho da etapa) definindo os bits correspondentes em bmControlFlags. Todos os outros campos devem ser definidos como 0.

GET_MIN e GET_MAX solicitações devem relatar o valor mínimo e máximo com suporte para dwValue. O bit D4 (indicando o tamanho do passo de 1) deve ser o único bit configurado em bmControlFlags. Todos os outros campos devem ser definidos como 0.

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

2.2.2.5 Controle de saldo em branco

Esse controle permite que o software host especifique as configurações de equilíbrio em branco para a câmera. Esse é um controle global que afeta todos os endpoints 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 solicitações devem seguir as definições na seção 2.2.2.1, mas devem ter dwValueFormat definido como 1.

GET_MAX requisito: esse controle deve anunciar o suporte para os bits D0, D1 e D2 no bmControlFlags.

Requisito GET_DEF: o padrão para bmControlFlags deve ser D0 configurado para 1 e dwValueFormat e dwValue configurados para 0.

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

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

2.2.2.6 Controle de Autenticação Facial

Esse controle permite que o software host especifique se a câmera dá suporte a modos de streaming usados para autenticação facial. O suporte para esse controle implica que a câmera é capaz de autenticação facial. Esse controle não terá suporte caso contrário.

Esse 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 à interface de controle de vídeo).

GET_RES e GET_MIN solicitações devem relatar 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 tem suporte para essa interface de streaming. Uma saída de solicitação GET_MAX deve listar todas e somente as interfaces de streaming capazes de D1 ou D2 (por exemplo, se uma interface de streaming for capaz de D1 ou D2, ela será listada; caso contrário, ela não será listada). Além disso, nenhuma interface de streaming deve ser anunciada como compatível com D1 e D2. Se uma interface de streaming também for destinada a ser usada de maneira geral (por exemplo, fora da finalidade da autenticação facial), d0 será definido como 1 para essa interface de streaming (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 &D2) devem ser definidos para uma interface de streaming específica. Para a solicitação GET_DEF que retorna a opção padrão (que é específica de implementação), se uma interface de streaming também for destinada a ser usada de maneira geral (por exemplo, fora da finalidade da autenticação facial), o D0 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 padrão. Uma saída de solicitação GET_DEF/GET_CUR deve conter informações sobre todas as interfaces de streaming listadas na saída da solicitação GET_MAX; no entanto, uma solicitação SET_CUR pode incluir apenas um subconjunto das interfaces de streaming listadas na saída da solicitação GET_MAX.

Exemplo:

Vamos supor que uma câmera tenha 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 de IR, vamos supor que interfaces de streaming 0x03 e 0x0b sejam 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 a solicitação GET_MAX deve ser a seguinte:

A saída para GET_DEF solicitação 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 de uma solicitação de GET_CUR após a solicitação de SET_CUR acima deve ser a seguinte:

Controle extrínseco da câmera 2.2.2.7

Esse controle permite que o software hospedeiro obtenha os dados extrínsecos da câmera para pontos de extremidade em interfaces de streaming de vídeo associadas à interface de controle de vídeo. Os dados obtidos para cada ponto de extremidade aparecem como o atributo MFStreamExtension_CameraExtrinsics no repositório de atributos do 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 solicitação deve listar todos os pontos de extremidade nos quais as informações extrínsecas estão disponíveis.

Exemplo:

Vamos supor que uma câmera tenha três interfaces de transmissão de vídeo com números 0x03, 0x05 e 0x08, respectivamente, em que a interface de transmissão de vídeo 0x05 dá suporte à captura de imagens estáticas usando o método 2, além da captura de vídeo suportada por todas as interfaces de transmissão de vídeo. Entre essas interfaces de streaming, vamos supor que as interfaces 0x05 e 0x08 tenham informações extrínsecas disponíveis enquanto a interface 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:

Controle intrínseco de câmera 2.2.2.8

Esse controle permite que o software host obtenha os dados intrínsecos da câmera para pontos de extremidade em interfaces de streaming de vídeo associadas à interface de controle de vídeo. Os dados obtidos para cada endpoint aparecem como o atributo MFStreamExtension_PinholeCameraIntrinsics na loja de atributos do 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.

A solicitação GET_DEF deve listar todos os endpoints que têm 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 dá suporte à captura de imagem estática usando o método 2, além do suporte à captura de vídeo proporcionado por todas as interfaces de streaming de vídeo. Entre essas interfaces de streaming, vamos supor que as interfaces de streaming 0x05 e 0x08 tenham 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:

Controle de metadados 2.2.2.9

Esse controle permite que o software host consulte e controle metadados produzidos pela câmera. Esse é um controle global que afeta todos os endpoints em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo.

Esse controle é mapeado para KSPROPERTY_CAMERACONTROL_EXTENDED_METADATA pelo driver de câmera.

Se SET_CUR solicitação tiver suporte pelo firmware, o seguinte se aplicará:

• GET_MIN, GET_DEF solicitações devem relatar o campo dwValue definido como 0.

• A solicitação GET_RES deve informar o campo dwValue com o mesmo valor informado pela solicitação GET_MAX.

• Quando uma solicitação de SET_CUR é recebida com dwValue definido como 0, a câmera não deve produzir metadados. Quando uma solicitação SET_CUR é recebida com dwValue definido como 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 SET_CUR solicitação não for compatível com o firmware, o seguinte se aplicará:

• As solicitações GET_MIN, GET_DEF devem relatar que o campo dwValue é o mesmo valor relatado pela solicitação GET_MAX.

• A solicitação GET_RES deve relatar 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 - vezes 1.024 bytes, menos o tamanho de um conteúdo de metadados UsbVideoHeader, para qualquer quadro.

• Um payload de metadados UsbVideoHeader é o 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 seção 2.2.3.

2.2.2.10 Controle de tochas IR

Esse controle fornece um meio flexível para o hardware de LED IR indicar a extensão em que pode ser controlado e oferece a capacidade de controlá-lo. Esse é um controle global que afeta todos os pontos de extremidade em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo, ajustando a potência para uma lâmpada IR conectada à câmera.

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

O seguinte se aplica:

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

• A solicitação GET_INFO deve informar um valor de 3. Esse valor indica um controle síncrono que dá suporte a GET_CUR e SET_CUR.

• GET_MIN solicitação deve relatar o campo dwMode definido como 0 e dwValue definido como um valor que indica a potência mínima. Um nível de energia de 0 pode indicar OFF, mas o nível mínimo de energia 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 de modo que GET_MAX(dwValue) – GET_MIN(dwValue) é uniformemente divisível por esse valor. dwValue pode não ser zero (0).

• A solicitação GET_MAX deve relatar o campo dwMode configurado com bits D[0-2] definidos para identificar as capacidades desse controle. dwMode deve ter o bit D0 definido, indicando que OFF tem suporte e deve ter pelo menos um outro conjunto de bits, dando suporte a um estado ativo. dwValue deve ser definido como um valor que indica a potência normal.

• GET_DEF solicitação deve relatar o campo dwMode definido como 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 (ALTERNANDO). dwValue deve ser definido como o nível de energia normalmente usado para o controle FaceAuth. dwValue é definido pelo fabricante.

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

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

A Tocha de IR deve emitir o atributo MF_CAPTURE_METADATA_FRAME_ILLUMINATION para cada quadro. Ele pode fornecer isso por meio de um Device MFT ou incluindo um atributo MetadataId_FrameIllumination no conteúdo de metadados da câmera. Consulte a seção 2.2.3.4.4.

A única finalidade deste metadados é indicar se um quadro está iluminado ou não. Esses são os mesmos metadados exigidos pela DDI KSPROPERTY_CAMERACONTROL_EXTENDED_FACEAUTH_MODE e pelo MSXU_FACE_AUTHENTICATION_CONTROL definidos na seção 2.2.2.6.

Controle de janela digital 2.2.2.11

A Janela Digital especifica o campo de exibição e o zoom da câmera enquanto a câmera está transmitindo. Esse controle é um substituto potencial para Pan, Tilt e Zoom. Esse controle só se aplica enquanto a câmera está transmitindo ativamente.

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

Esse controle permite que o software host consulte e controle a janela digital associada a uma câmera.

Esse é um controle global que afeta todos os endpoints em todas as interfaces de streaming de vídeo associadas ao controle de vídeo. Ele ajusta a origem dos dados de pixel usados pelo ISP. Isso inclui os pinos de captura do Método 2 e do Método 3.

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

O seguinte se aplica:

• GET_LEN solicitação deve relatar um valor de 16.

• A solicitação GET_INFO deve informar um valor de 3. Esse valor indica um controle síncrono que dá suporte a GET_CUR e SET_CUR.

• GET_MIN solicitação deve relatar o campo dwMode definido como 0, OriginX e OriginY definidos como 0.0 e WindowSize definido como 1.0. No momento, essa solicitação não foi utilizado.

• GET_RES solicitação deve relatar o campo dwMode definido como 0, OriginX e OriginY definidos como 0.0 e WindowSize definido como 1.0. No momento, esta solicitação não está sendo utilizada.

• GET_MAX solicitação deve relatar o campo dwMode definido com o bit D0 definido para identificar os recursos desse controle. Um valor de 0 indica que há suporte apenas para o modo manual. Um valor de 1 indica que há suporte para o modo de enquadramento facial automático. No entanto, o restante desses campos não é utilizado, recomendamos que OriginX e OriginY sejam definidos como 0.0 e WindowSize definido como 1.0.

• GET_DEF solicitação deve relatar o campo dwMode definido como 0, OriginX e OriginY definidos como 0.0 e WindowSize definido como 1.0. Essa é sempre a janela padrão.

• GET_CUR solicitação deve relatar o campo dwMode definido como o modo operacional atual e OriginX, OriginY e WindowSize descrevem a janela digital atual.

• Quando uma solicitação SET_CUR é recebida, a câmera ajusta seu campo de exibiçã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 o OriginX, OriginY e WindowSize passados são ignorados. Se nenhum rosto for encontrado, a janela padrão será usada.

• Todas as alterações na janela digital devem ser refletidas no conteúdo de metadados de cada exemplo.

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

2.2.2.12 Controle de Configuração de Janela Digital

O controle de Configuração de Capacidades da Janela Digital especifica os limites de dimensionamento da câmera, considerando 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 uma funcionalidade.

Devido às limitações de tamanho de um endpoint de controle, este controle pode descrever no máximo 1820 resoluções únicas.

Esse controle sempre deve estar disponível para relatar os recursos do controle 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.

O seguinte se aplica:

• GET_LEN solicitação deve relatar todo o tamanho da carga. O tamanho da carga deve ser um múltiplo de 36, pois cada definição de resolução tem 36 bytes de comprimento.

• A solicitação GET_INFO deve relatar '1'. Esse valor indica um controle síncrono que dá suporte apenas a GET_CUR.

• A solicitação GET_CUR deve indicar uma lista de capacidades. Os campos da estrutura de funcionalidade são definidos acima.

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

• não há suporte para solicitações SET_CUR.

2.2.2.13 Controle hdr de vídeo

Esse controle permite que o software host especifique se a câmera dá suporte ao HDR de vídeo. O suporte para esse controle implica que a câmera é capaz de realizar HDR de vídeo da melhor forma possível. Se a câmera não der suporte ao HDR de Vídeo, ela não deverá implementar esse controle.

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

O seguinte se aplica:

• GET_LEN solicitação deve relatar todo o tamanho da carga (por exemplo, 4 bytes).

• A solicitação GET_INFO deve informar um valor 3. Esse valor indica um controle síncrono que dá suporte a GET_CUR, SET_CUR.

• A solicitação GET_CUR deverá indicar o campo dwMode definido como o modo de operação atual.

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

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

• GET_MIN e GET_RES solicitações devem relatar 0.

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

2.2.2.14 Controle de limitação de taxa de quadros

Esse controle permite que o software host especifique se a câmera dá suporte à restrição de taxa de quadros.

Esse controle só se aplica enquanto a câmera está transmitindo ativamente. Ser streaming ativamente significa que um pin 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 esse seja um controle de escopo de filtro, o controle de taxa de quadros não deve afetar o pino de foto ou fluxos sem RGB, como IR/profundidade. Além disso, quando a limitação da taxa de quadros estiver em vigor, a duração da amostra também deverá ser ajustada adequadamente.

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

O seguinte se aplica:

• A requisição GET_LEN deve informar todo o tamanho do payload (por exemplo, 20 bytes). 

• A solicitação GET_INFO deverá relatar um valor 3. Esse valor indica um controle síncrono que dá suporte a GET_CUR, SET_CUR. 

• GET_CUR requisição deve relatar o campo dwMode ajustado para o modo operacional atual e scaleFactorPercentage ajustado para o valor atual de 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 passo definido como valor de passo padrão. Os valores de min e step devem ser definidos pelo fabricante, mas devem seguir as diretrizes mencionadas na tabela acima.

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

• GET_MIN e GET_RES solicitações devem relatar 0. 

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

2.2.2.15 Campo de Exibição 2 Controle de Configuração

O controle de configuração do Campo de Visão 2 especifica os valores de graus suportados do Campo de Visão diagonal como uma matriz de valores. Todos os valores com suporte devem estar no intervalo de mínimo teórico e máximo, de 1 grau a 360 graus.

Se o dispositivo quiser dar suporte a valores contínuos do Campo de Exibição, ele precisará relatar todos os valores com suporte. Por exemplo, se o dispositivo quiser dar suporte ao Campo de Exibição diagonal de 85 graus a 60 graus com tamanho de etapa de 1, esse controle precisará relatar matriz de valores [85, 84, 83, 82, ..., 62, 61, 60].

Esse controle deve estar disponível para informar as capacidades quando o controle Campo de Exibição 2 estiver presente.

Esse é um controle de nível de filtro síncrono.

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

O seguinte se aplica:

• GET_LEN solicitação deve relatar todo o tamanho da carga.

• A solicitação GET_INFO deve reportar o valor 1. Esse valor indica um controle síncrono que dá suporte apenas a GET_CUR.

• A solicitação GET_CUR deve informar dados que contêm o FoV padrão e o conjunto de valores FoV suportados em ordem decrescente. Os campos da estrutura são definidos acima.

• O comando GET_DEF deve retornar o mesmo resultado que GET_CUR.

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

• não há suporte para solicitações SET_CUR.

Os valores de campo de exibição devem estar em ordem decrescente, por exemplo, o campo de exibição mais largo é o primeiro e o mais estreito é o último.

Controle do Campo de Visão 2

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

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

Esse controle permite que o software host consulte e controle o campo de exibição associado a uma câmera.

Esse é um controle global que afeta todos os endpoints em todas as interfaces de streaming de vídeo associadas à interface de controle de vídeo. Ele ajusta a origem dos dados de pixel (ou sensor) usados pelo ISP (Processador de Sinal de Imagem). Isso inclui os pinos de captura do Método 2 e do Método 3.

Esse é um controle de nível de filtro síncrono.

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

O seguinte se aplica:

• GET_LEN solicitação deve relatar um valor de 4.

• Solicitação GET_INFO deve informar um valor 3. Esse valor indica um controle síncrono que dá suporte a GET_CUR e SET_CUR.

• GET_MIN requisição deve informar o campo dwValue definido como valor mínimo do Campo de Visão suportado.

• A solicitação GET_RES deve relatar o campo dwValue configurado como 0. No momento, esta solicitação não está sendo utilizada.

• GET_MAX solicitação deve informar o campo dwValue definido como o valor máximo de Campo de Visão com suporte.

• A solicitação GET_DEF deve relatar o campo dwValue definido como o valor padrão do Campo de Visão.

• A solicitação GET_CUR deve informar 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 exibição para corresponder ao dwValue especificado.

• Se a câmera implementar CT_ZOOM_RELATIVE_CONTROL e/ou CT_ZOOM_ABSOLUTE_CONTROL, esses controles serão redefinidos para seus valores padrão quando MSXU_CONTROL_FIELDOFVIEW2 SET_CUR for chamado.

Se a câmera implementar MSXU_CONTROL_DIGITALWINDOW, ela refletirá a alteração da janela quando um novo valor de Campo de Exibição for definido. E vice-versa, o Campo de Exibição deve refletir as alterações feitas por meio 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 do UVC do Windows 10. No Windows 10, os metadados personalizados têm suporte para UVC usando um INF personalizado para o driver de câmera (observação: o driver da câmera pode ser baseado no Windows USBVIDEO.SYS, mas um INF personalizado é necessário para o hardware específico para que os metadados sejam transmitidos corretamente). Se a entrada MetadataBufferSizeInKB<PinIndex> do Registro estiver presente e diferente de zero, então os metadados personalizados são compatíveis com aquele pino e o valor indica 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 (Sem suporte) para 0x1 (com suporte)

Essa chave do Registro será lida pelo DevProxy e informa ao driver UVC que os metadados estão no formato padrão, definindo o sinalizador KSSTREAM_METADATA_INFO_FLAG_STANDARDFORMAT no campo Flags da 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 definição de enumeração a seguir 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(Carga de Metadados).

2.2.3.2 Metadados em 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 quadro, o quadro de vídeo é empacotado em uma série de pacotes, cada um precedido por um Cabeçalho de Carga UVC. Cada cabeçalho de carga UVC é definido pela especificação de carga baseada em quadro do driver da classe de vídeo USB:

Cabeçalho de Payload

Veja a seguir uma descrição do formato de cabeçalho de conteúdo para formatos baseados em quadro.

Campo HLE (comprimento do cabeçalho)

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

Campo de cabeçalho do campo de bits

FID: Identificador de quadro

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

EOF: Fim do Quadro

• Esse bit indica o fim de um quadro de vídeo e é definido no último exemplo de vídeo que pertence 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 Data/Hora da Apresentação

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

SCR: Referência do relógio de origem

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

RES: Reservado.

• Definido como 0.

STI: Imagem parada

• Esse bit, quando definido, identifica um exemplo de vídeo como pertencente a uma imagem parada.

ERR: Bit de erro

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

EOH: fim do cabeçalho

• Esse bit, quando definido, indica o final dos campos BFH.

PTS: Carimbo de Data/Hora da Apresentação, Tamanho: 4 bytes, Valor: Número

• O campo PTS está presente quando o bit PTS é definido no campo BFH[0]. Consulte a Seção 2.4.3.3 "Cabeçalhos de Conteúdo de Imagem Estática e Vídeo" na Especificação da 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 conteúdo de vídeo e imagem estática na especificação de definição de classe de dispositivo USB para dispositivos de vídeo.

O campo HLE no driver UVC existente é fixo 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 o PTS/SCR estiver presente e o HLE for maior que 12 bytes, quaisquer dados adicionais após os primeiros 12 bytes do cabeçalho da carga útil serão coletados como metadados padrão específicos para o quadro de vídeo quando a entrada StandardFormatMetadata<PinIndex> INF for configurada.

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

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

O buffer de metadados fornecido ao componente de modo de usuário teria um item de metadados para carimbos de data/hora do UVC (gerados pelo driver UVC) seguidos por itens de metadados gerados por firmware, dispostos da seguinte maneira:

Formato de metadados 2.2.3.4 para identificadores de metadados padrão

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

2.2.3.4.1 MetadataId_CaptureStats

O formato de metadados desse 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 são preenchidos e têm dados válidos. O campo Sinalizadores não deve variar de quadro para quadro. Atualmente, os seguintes sinalizadores são definidos:

#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 no exemplo MF correspondente.

O campo ExposureCompensationFlags contém a etapa de compensação EV (exatamente um dos sinalizadores de etapa KSCAMERA_EXTENDEDPROP_EVCOMP_XXX devem ser definidos) usada para transmitir o valor de Compensação EV. O campo ExposureCompensationValue contém o valor de compensação de exposição (EV) em unidades do passo aplicado ao sensor quando o quadro foi capturado. Elas aparecem como o atributo MF_CAPTURE_METADATA_EXPOSURE_COMPENSATION no amostra MF correspondente.

O campo IsoSpeed contém o valor de velocidade ISO aplicado ao sensor quando o quadro foi capturado. Isso é sem unidade. O atributo MF_CAPTURE_METADATA_ISO_SPEED aparece no exemplo de MF correspondente.

O campo FocusState contém o estado de foco atual que pode levar um dos valores definidos na enumeração KSCAMERA_EXTENDEDPROP_FOCUSSTATE. Isso aparece como o 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 não possui unidade. Esse é o mesmo valor que pode ser consultado de KSPROPERTY_CAMERACONTROL_EXTENDED_FOCUS em uma chamada GET. Isso é exibido como o atributo MF_CAPTURE_METADATA_LENS_POSITION na amostra MF correspondente.

O campo WhiteBalance contém o saldo em 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 booliano com 1 que significa flash ativado e 0 significando flash off, quando o quadro foi capturado. Isso aparece como do atributo MF_CAPTURE_METADATA_FLASH no exemplo correspondente de MF.

O campo FlashPower contém a potência flash aplicada ao quadro capturado, que é um valor no intervalo de [0, 100]. Esse campo deverá ser omitido se o driver não oferecer suporte à energia ajustável para flash. Isso aparece como o atributo MF_CAPTURE_METADATA_FLASH_POWER no exemplo correspondente de MF.

O campo ZoomFactor contém o valor de zoom no formato Q16 aplicado ao quadro capturado. Isso aparece como o atributo MF_CAPTURE_METADATA_ZOOMFACTOR no exemplo 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. Isso é exibido como o atributo MF_CAPTURE_METADATA_SCENE_MODE na amostra correspondente de MF.

O campo SensorFramerate contém a taxa de leitura medida do sensor em hertz quando o quadro é capturado, que consiste em um valor numerador nos 32 bits superiores e um valor denominador nos 32 bits inferiores. Isso aparece como atributo MF_CAPTURE_METADATA_SENSORFRAMERATE no exemplo correspondente de MF.

2.2.3.4.2 MetadataId_CameraExtrinsics

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

2.2.3.4.3 MetadataId_CameraIntrinsics

O formato de metadados desse identificador envolve o KSCAMERA_METADATA_ITEMHEADER padrão seguido por uma carga de matriz de bytes. A carga útil deve estar alinhada à 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 devem ser definidos como 0.

2.2.3.4.4 MetadataId_FrameIllumination

O formato de metadados desse 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, os seguintes sinalizadores são definidos:

#define KSCAMERA_METADATA_FRAMEILLUMINATION_FLAG_ON 0x00000001

Se um quadro tiver sido capturado quando a iluminação estiver ativada, o sinalizador KSCAMERA_METADATA_FRAMEILLUMINATION_FLAG_ON deverá ser definido. Caso contrário, esse sinalizador não deverá ser definido.

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 ativada 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 de metadados desse identificador é definido por um KSCAMERA_METADATA_ITEMHEADER comum seguido por uma estrutura 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;

Os campos StartOfFrameTimestamp e EndOfFrameTimestamp são os carimbos de data/hora contidos nos cabeçalhos UVC nos primeiros e últimos pacotes UVC emitidos pela câmera para construir este quadro.

Este payload não deve ser enviado por um dispositivo.

Esse conteúdo de metadados é exclusivo, pois é o único conteúdo de metadados gerado diretamente pelo driver de classe de vídeo USB a partir de informações obtidas de cabeçalhos de conteúdo compatíveis com UVC.

Esse conteúdo é anexado ao buffer de metadados de cada quadro.

Se o dispositivo der suporte a metadados padronizados, ele deverá incluir o espaço necessário para armazenar esse conteúdo em seus requisitos de buffer, conforme relatado pelo controle de metadados definido na seção 2.2.2.9.