Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Importante
O método de correção automática discutido posteriormente neste tópico é a solução recomendada para a montagem de sensores de câmera sem orientação de referência. Isso é para garantir a compatibilidade do aplicativo, uma vez que a maioria dos aplicativos já escritos para usar feeds de câmera não sabe verificar, nem corrigir as informações de rotação. Por favor, revise cuidadosamente as informações na seção de correção automática abaixo.
À medida que diferentes dispositivos informáticos de formatos são introduzidos, algumas das restrições físicas resultam em sensores de câmara que são montados numa orientação não tradicional. Por causa disso, é necessário descrever corretamente para o sistema operacional e aplicação, como os sensores são montados para que o vídeo resultante possa ser renderizado / gravado corretamente.
A partir do Windows 10, versão 1607, todos os drivers de câmera são necessários para especificar explicitamente a orientação da câmera, independentemente de a câmera estar montada de acordo com os requisitos mínimos de hardware. Especificamente, um driver de câmera deve definir um campo recém-introduzido, Rotação, na estrutura de _PLD ACPI associada a uma interface de dispositivo de captura:
typedef struct _ACPI_PLD_V2_BUFFER {
UINT32 Revision:7;
UINT32 IgnoreColor:1;
UINT32 Color:24;
// …
UINT32 Panel:3; // Already supported by camera.
// …
UINT32 CardCageNumber:8;
UINT32 Reference:1;
UINT32 Rotation:4; // 0 – Rotate by 0° clockwise
// 1 – Rotate by 45° clockwise (N/A to camera)
// 2 – Rotate by 90° clockwise
// 3 – Rotate by 135° clockwise (N/A to camera)
// 4 – Rotate by 180° clockwise
// 5 – Rotate by 225° clockwise (N/A to camera)
// 6 – Rotate by 270° clockwise
UINT32 Order:5;
UINT32 Reserved:4;
//
// _PLD v2 definition fields.
//
USHORT VerticalOffset;
USHORT HorizontalOffset;
} ACPI_PLD_V2_BUFFER, *PACPI_PLD_V2_BUFFER;
Para a câmera, o campo Rotação em uma estrutura de _PLD ACPI especifica o número de graus ('0' para 0°, '2' para 90°, '4' para 180° e '6' para 270°) um quadro capturado é girado em relação à tela enquanto a tela está em sua orientação nativa.
Com base no valor no campo Rotação , um aplicativo pode executar rotação adicional, se necessário, para renderizar os quadros capturados corretamente.
Valores de rotação
Para os dispositivos cujas câmaras e monitores compartilham a mesma caixa (ou invólucro), é possível que estes periféricos sejam montados em superfícies diferentes, cada um deles podendo ser girado por um ângulo fixo, mas arbitrário no seu respetivo plano. Consequentemente, um aplicativo precisa de um mecanismo para descrever a relação espacial entre os dois periféricos, de modo que um quadro capturado possa ser transposto para a superfície de renderização na orientação correta.
Uma maneira de resolver o problema é usar a estrutura de _PLD ACPI que já tem os conceitos de superfície e graus de rotação definidos. Por exemplo, a estrutura _PLD já tem campo de painel que especifica a superfície na qual um periférico reside:
Definição do campo do Painel ACPI _PLD (Rev. 5.0a)
Os dois diagramas seguintes ilustram visualmente a definição de cada painel:
Definições de painel para PCs desktop e a maioria dos dispositivos
Definições de painel para dispositivos dobráveis
Na verdade, o conceito de um "painel" ACPI já é adotado pelo Windows onde:
Uma interface de dispositivo de câmera está associada a uma estrutura _PLD com o campo Painel sendo definido de acordo se um dispositivo de captura for montado estaticamente em um local fixo.
Um aplicativo pode recuperar o painel no qual um dispositivo de captura reside chamando a propriedade Windows.Devices.Enumeration.DeviceInformation.EnclosureLocation.Panel .
A estrutura _PLD ACPI também tem um campo Rotação definido da seguinte forma:
Definição do campo de rotação ACPI _PLD (Rev. 5.0a)
Em vez de usar a definição acima como está, refinamo-la ainda mais para evitar ambiguidade:
- Para a câmara, o campo Rotação numa estrutura _PLD ACPI especifica o número de graus ('0' para 0°, '2' para 90°, '4' para 180° e '6' para 270°) que um quadro capturado é rodado em relação ao ecrã, enquanto o ecrã está na sua orientação nativa.
Paisagem Primária vs Retrato Primário
No Windows, pode-se consultar a orientação de exibição nativa chamando a propriedade, Windows.Graphics.Display.DisplayInformation.NativeOrientation, que retorna Paisagem ou Retrato:
Não importa qual valor NativeOrientation retorna, o padrão de varredura de exibição lógica começa no canto superior esquerdo da tela, movendo-se da esquerda para a direita para baixo (consulte a Figura 5). Para aqueles dispositivos cuja orientação física padrão é inexplícita, essa propriedade não só implica a localização de um painel ACPI superior , mas também fornece a relação espacial entre um buffer de saída da câmera e a superfície de renderização.
Observe que, ao contrário da câmera, a propriedade NativeOrientation não é baseada em ACPI e, portanto, não tem uma estrutura _PLD. Isto é verdade mesmo se um ecrã estiver montado estaticamente num dispositivo.
Ao montar num dispositivo Primário em modo Retrato, os drivers da câmara devem estar cientes de que a maioria dos aplicativos tratará o dispositivo como se emitisse um buffer de saída da câmara em modo paisagem, independentemente da orientação real do buffer de saída da câmara. Por isso, recomendamos que os drivers da câmara produzam um buffer de câmara com uma orientação deslocada em 90 graus em relação à Orientação Nativa Retrato quando se trata de um dispositivo cujo modo primário é Retrato. Isso permitirá que os aplicativos que estão executando essa rotação adicional em dispositivos no modo retrato corrijam a rotação para a orientação esperada. Isso pode ser verificado usando o aplicativo de câmera com amostra de rotação.
Montagem offset
Os IHV/OEMs são fortemente encorajados a evitar a montagem do sensor com um deslocamento diferente de 0 graus para manter a compatibilidade da aplicação. Muitos aplicativos existentes e legados não estão programados para procurar a tabela PLD da ACPI, nem tentarão corrigir o desajuste de rotação de grau diferente de zero. Consequentemente, para tais aplicativos, o vídeo resultante será processado incorretamente.
Nos casos em que os IHV/OEMs não conseguem montar o sensor na orientação de 0 grau, conforme descrito acima, as seguintes etapas de mitigação são recomendadas na ordem de preferência:
Corrija automaticamente a orientação não-0 grau dentro do driver da câmera (no modo kernel com o driver de miniporta de fluxo AV ou no modo de usuário usando um plug-in, como Device MFT ou MFT0) para que os quadros de saída resultantes estejam na orientação de 0 grau.
Declare a orientação diferente de 0 grau por meio da tag FSSensorOrientation para que o Pipeline da câmera possa corrigir a imagem capturada.
Declare a orientação de grau não zero na tabela PLD da ACPI, conforme descrito acima.
Tipos de mídia compactados/codificados
Para tipos de mídia compactados e/ou codificados (como MJPG, JPEG, H264, HEVC), o pipeline "correct" não pode ser usado. Devido a isso, os tipos de mídia compactados/codificados serão filtrados se o FSSensorOrientation estiver definido como um valor diferente de zero.
No caso de tipos de mídia MJPG (como aqueles de uma câmera UVC), o pipeline do Frame Server fornece um tipo de mídia decodificada automaticamente (NV12 ou YUY2 para aplicativos baseados em DShow). O tipo de mídia auto-decodificado e corrigido será apresentado, mas o formato MJPG original não.
[! ATENÇÃO!] Se os tipos de mídia compactados/codificados precisarem ser expostos a aplicativos, IHV/ODMs não deverão utilizar a correção FSSensorOrientation. Em vez disso, a correção deve ser feita pelo driver da câmera (no modo kernel através do driver AV Stream ou no modo de usuário via DMFT / MFT0).
Auto-Correção via AV Stream Miniport/Device MFT/MFT0
O cenário recomendado, caso os sensores não possam ser montados com um deslocamento de 0 graus, é que o driver de miniporta AV Stream (ou os plug-ins em modo de utilizador na forma de DMFT ou MFT0) corrijam o quadro capturado resultante, para que seja apresentado ao pipeline com um deslocamento de 0 graus.
Ao corrigir o quadro de vídeo da miniporta AV Stream e/ou do plug-in MFT/MFT0 do dispositivo, a declaração de tipo de mídia resultante deve ser baseada no quadro corrigido. Se o sensor estiver montado em um deslocamento de 90 graus para que o vídeo resultante tenha uma proporção de 9:16 do sensor, mas o vídeo corrigido seria 16:9, o tipo de mídia deve declarar a proporção 16:9.
Isto inclui as informações do passo resultantes. Isso é necessário, pois o componente responsável por fazer a correção é controlado pelo IHV / OEM e o pipeline da câmera não tem visibilidade no quadro de vídeo, exceto depois de ter sido corrigido.
É fortemente recomendável que a correção seja feita no modo de usuário e o contrato de API entre o pipeline e o plugin de modo de usuário deve ser seguido. Especificamente, ao usar o DMFT ou MFT0, quando o IMFDeviceTransform::P rocessMessage ou IMFTransform::P rocessMessage é invocado com uma mensagem MFT_MESSAGE_SET_D3D_MANAGER, o plug-in de modo de usuário deve aderir à seguinte diretriz:
- Se nenhum gerenciador D3D for fornecido (o ulParam da mensagem é 0), o plug-in de modo de usuário NÃO deve invocar nenhuma operação de GPU para lidar com a correção de rotação. E o quadro resultante deve ser fornecido na memória do sistema.
- Se o gerenciador D3D for fornecido (o ulParam da mensagem é o IUnknown de um Gerenciador DXGI), esse Gerenciador DXGI deve ser usado para correção de rotação e o quadro resultante deve ser memória GPU.
- O plug-in de modo de usuário também deve manipular a mensagem do gerenciador D3D durante o tempo de execução. Quando a mensagem MFT_MESSAGE_SET_D3D_MANAGER é emitida, o próximo quadro produzido pelo plugin deve corresponder ao tipo de memória solicitado (ou seja, GPU se o DXGI Manager foi fornecido, CPU caso contrário).
- Quando o driver AV Stream (ou o plug-in de modo de usuário) lida com a correção de rotação, o campo Rotação da estrutura PLD da ACPI deve ser definido como 0.
Observação
Quando a Correção Automática é usada, OEMs e IHVs NÃO devem anunciar a orientação real do sensor através do campo Rotação _PLD. Neste caso, o campo Rotação deve indicar a orientação após a correção: 0 graus.
Declarar via FSSensorOrientation
; Defines the sensor mounting orientation offset angle in
; degrees clockwise.
FSSensorOrientation: REG_DWORD: 90, 180, 270
Ao declarar a orientação do sensor em um ângulo diferente de zero através da tag de registo FSSensorOrientation, o fluxo de processo da câmara pode corrigir o quadro capturado antes de o apresentar à aplicação.
O pipeline otimizará a lógica de rotação aproveitando os recursos da GPU ou da CPU com base no caso de uso e na solicitação/cenário do aplicativo.
Rotação ACPI PLD
O campo Rotação da estrutura PLD ACPI deve ser 0. Isto é para evitar aplicações confusas que podem usar as informações PLD para corrigir o quadro.
Informações sobre o tipo de mídia
O tipo de mídia apresentado pelo controlador deverá ser o tipo de mídia não corrigido. Ao informar o pipeline da câmera do deslocamento não-0 grau usando a entrada FSSensorOrientation, as informações de tipo de mídia apresentadas pelo sensor devem ser o tipo de mídia não corrigido. Por exemplo, se o sensor estiver montado 90 graus no sentido horário, o que faz com que, em vez da proporção de aspecto 16:9, o vídeo resultante tenha uma proporção de 9:16; o tipo de mídia com proporção de 9:16 deve ser apresentado ao fluxo da câmara.
Isso é necessário para garantir que o pipeline possa configurar corretamente o processo de rotação do contador: O pipeline precisa do tipo de mídia de entrada e do tipo de mídia de saída desejado do aplicativo.
Isso inclui as informações de passada. As informações sobre a largura de banda devem ser apresentadas para o tipo de média não corrigida no pipeline da câmera.
Subchave do Registo
A entrada do Registo FSSensorOrientation deve ser publicada no nó Interface de Dispositivo. A abordagem recomendada é definir isto como uma diretiva AddReg ao declarar a diretiva AddInterface no INF do driver da câmara.
Os dados apresentados no FSSensorOrientation devem ser uma REG_DWORD e os únicos valores válidos aceitos serão 90, 180 e 270. Qualquer outro valor será tratado como desvio de 0 graus (isto é, ignorado).
Cada valor representa a orientação do sensor em graus no sentido horário. O pipeline da câmera corrigirá o quadro de vídeo resultante girando o vídeo pela mesma quantidade no sentido anti-horário: ou seja, uma declaração de 90 graus no sentido horário resultará em uma rotação de 90 graus no sentido anti-horário para trazer o quadro de vídeo resultante de volta para 0 grau de deslocamento.
Descritor do MS OS 1.0
Para câmeras baseadas em USB, FSSensorOrientation também pode ser publicado através de descritores MSOS.
MS OS Descriptor 1.0 tem dois componentes:
- Uma seção de cabeçalho de comprimento fixo
- Uma ou mais seções de propriedades personalizadas de comprimento variável, que seguem a seção de cabeçalho
Seção de cabeçalho do MS OS DESCRIPTOR 1.0
A seção Header descreve uma única propriedade personalizada (Face Auth Profile).
| Compensação | Campo | Tamanho (bytes) | Valor | Descrição |
|---|---|---|---|---|
| 0 | dwComprimento | 4 | <> | |
| 4 | bcdVersão | 2 | 0x0100 | Versão 1.0 |
| 6 | wÍndice | 2 | 0x0005 | Descritor de SO de propriedade estendida |
| 8 | wContagem | 2 | 0x0001 | Uma propriedade personalizada |
Seção de propriedade personalizada do MS OS DESCRIPTOR 1.0
| Compensação | Campo | Tamanho (bytes) | Valor | Descrição |
|---|---|---|---|---|
| 0 | dwSize | 4 | 0x00000036 (54) | Tamanho total (em bytes) para esta propriedade. |
| 4 | dwPropertyDataType | 4 | 0x00000004 | REG_DWORD_LITTLE_ENDIAN |
| 8 | wPropertyNameLength | 2 | 0x00000024 (36) | Tamanho (em bytes) do nome da propriedade. |
| 10 | bNome da propriedade | 50 | UVC-FSSensorOrientation | String "UVC-FSSensorOrientation" em Unicode. |
| 60 | dwPropertyDataLength | 4 | 0x00000004 | 4 bytes para dados de propriedade (sizeof(DWORD)). |
| 64 | bPropertyData | 4 | Ângulo de deslocamento em graus no sentido horário. | Os valores válidos são 90, 180 e 270. |
Descritor do MS OS 2.0
MSOS Extended Descriptor 2.0 pode ser usado para definir os valores do Registro para adicionar suporte FSSensorOrientation. Isso é feito usando o Microsoft OS 2.0 Registry Property Descriptor.
Para a entrada de registo UVC-FSSensorOrientation, o seguinte mostra um conjunto de descritores MSOS 2.0 de exemplo:
UCHAR Example2_MSOS20DescriptorSet_UVCFSSensorOrientationForFutureWindows[0x3C] =
{
//
// Microsoft OS 2.0 Descriptor Set Header
//
0x0A, 0x00, // wLength - 10 bytes
0x00, 0x00, // MSOS20_SET_HEADER_DESCRIPTOR
0x00, 0x00, 0x0?, 0x06, // dwWindowsVersion – 0x060?0000 for future Windows version
0x4A, 0x00, // wTotalLength – 74 bytes
//
// Microsoft OS 2.0 Registry Value Feature Descriptor
//
0x40, 0x00, // wLength - 64 bytes
0x04, 0x00, // wDescriptorType – 4 for Registry Property
0x04, 0x00, // wPropertyDataType - 4 for REG_DWORD_LITTLE_ENDIAN
0x32, 0x00, // wPropertyNameLength – 50 bytes
0x55, 0x00, 0x56, 0x00, // Property Name - "UVC-FSSensorOrientation"
0x43, 0x00, 0x2D, 0x00,
0x46, 0x00, 0x53, 0x00,
0x53, 0x00, 0x65, 0x00,
0x6E, 0x00, 0x73, 0x00,
0x6F, 0x00, 0x72, 0x00,
0x4F, 0x00, 0x72, 0x00,
0x69, 0x00, 0x65, 0x00,
0x6E, 0x00, 0x74, 0x00,
0x61, 0x00, 0x74, 0x00,
0x69, 0x00, 0x6F, 0x00,
0x6E, 0x00, 0x00, 0x00,
0x00, 0x00,
0x04, 0x00, // wPropertyDataLength – 4 bytes
0x5A, 0x00, 0x00, 0x00 // PropertyData – 0x0000005A (90 degrees offset)
}
Declarar via ACPI PLD Information
Como uma opção de último recurso, as informações PLD podem ser aproveitadas conforme descrito acima para indicar ao aplicativo que o quadro de vídeo deve ser corrigido antes de ser renderizado/codificado. No entanto, como dito, muitos aplicativos existentes não usam as informações do PLD nem lidam com a rotação do quadro, portanto, haverá cenários em que os aplicativos podem não ser capazes de renderizar o vídeo resultante corretamente.
As figuras seguintes ilustram os valores do campo _PLD Rotação para cada configuração de hardware.
Rotação: 0 graus no sentido horário
Na figura acima:
A imagem à esquerda ilustra a cena a capturar.
A imagem no meio mostra como uma cena é vista por um sensor CMOS cuja ordem de leitura física começa no canto inferior esquerdo movendo-se da esquerda para a direita para cima.
A imagem à direita representa a saída do controlador da câmera. Neste exemplo, o conteúdo do buffer de mídia pode ser renderizado diretamente, enquanto a exibição está na sua orientação nativa sem rotação adicional. Consequentemente, o campo ACPI _PLD Rotação tem um valor de 0.
Rotação: 90 graus no sentido horário
Neste caso, o conteúdo do buffer de mídia é girado em 90 graus no sentido horário em comparação com a cena original. Como resultado, o campo ACPI _PLD Rotação tem um valor de 2.
Rotação: 180 graus no sentido horário
Neste caso, o conteúdo do buffer de mídia é girado em 180 graus no sentido horário em comparação com a cena original. Como resultado, o campo ACPI _PLD Rotação tem um valor de 4.
Rotação: 270 graus no sentido horário
Neste caso, o conteúdo do buffer de mídia é girado em 270 graus no sentido horário em comparação com a cena original. Como resultado, o campo ACPI _PLD Rotação tem um valor de 6.