Relatando partes e estatísticas de codificação miracast sobre Windows 8.1

Observação

A partir do Windows 10 (WDDM 2.0), o sistema operacional é fornecido com uma pilha Miracast interna que pode funcionar em qualquer GPU. Para obter informações sobre a pilha microsoft Miracast e os requisitos de drivers e hardware para dar suporte a exibições miracast a partir de Windows 10, consulte a seguinte documentação:

Os desenvolvedores de driver não devem mais implementar uma pilha Miracast personalizada. A Microsoft pode remover o suporte para pilhas Miracast personalizadas em uma versão futura do Windows.

Em Windows 8.1, o hardware de exibição pode processar cada quadro de vídeo enviado por um link de vídeo sem fio Miracast dividindo o quadro em várias partes ou codificando partes. Cada parte tem uma ID de parte exclusiva gerada com base no número do quadro e no número da parte do quadro (ou fatia). Cada parte relacionada à mesma atualização de quadro da área de trabalho deve receber o mesmo número de quadro.

Processamento de partes de relatório

Um driver pode codificar um quadro a ser enviado por um link sem fio Miracast em várias etapas de processamento, por exemplo, separando a conversão de cores da codificação, ou em uma única etapa. Cada etapa de processamento deve receber um número de parte de quadro exclusivo dentro do quadro.

O driver de modo de usuário miracast ou o driver de miniporta de exibição devem notificar o sistema operacional sempre que:

  • O hardware concluiu uma etapa de processamento para um quadro.
  • Imediatamente antes de cada parte do quadro ser enviada para a rede.

Presume-se que o tempo de uma determinada etapa de processamento relatado seja a hora em que o evento foi relatado ao sistema operacional, portanto, é importante relatar os estágios o mais rápido possível.

O sistema operacional não executa nenhuma ação além de registrar esses eventos usando o recurso de rastreamento no nível do kernel do ETW (Rastreamento de Eventos para Windows). No entanto, essas informações são importantes para medir e investigar problemas de desempenho.

Um driver pode fornecer a notificação usando uma das seguintes maneiras possíveis:

  • O driver de modo de usuário miracast chama a função de retorno de chamada ReportStatistic para relatar detalhes com o tipo de MIRACAST_STATISTIC_TYPE_CHUNK_PROCESSING_COMPLETE ou com MIRACAST_STATISTIC_TYPE_CHUNK_SENT para indicar que a parte está prestes a ser enviada para a pilha de rede para transmissão.
  • O driver de miniporta de exibição relata detalhes do processamento de partes com o tipo de interrupção DXGK_INTERRUPT_MICACAST_CHUNK_PROCESSING_COMPLETE , embora esse relatório só possa ser feito no momento da interrupção. Além de registrar em log as informações da parte, um pacote de partes é criado e enfileirado para que o driver de modo de usuário miracast possa recuperá-lo chamando a função de retorno de chamada GetNextChunkData .
  • O driver de miniporto de exibição chama a função de retorno de chamada DxgkCbReportChunkInfo em qualquer nível IRQL. Essa função registra apenas as informações da parte e não enfileira nenhum pacote de partes.

O mesmo número de quadro e números de parte devem ser usados se a imagem da área de trabalho não for atualizada, mas o driver precisar codificar a imagem da área de trabalho novamente para melhorar a qualidade. As ferramentas de desempenho disparam o segundo evento de codificação completa para o mesmo quadro e número de parte, indicando que uma segunda codificação do mesmo quadro foi executada.

A última fatia de cada quadro deve ter um número de parte de quadro igual a zero, o que indica a última fatia do quadro para as ferramentas de desempenho.

Para garantir a sincronização correta da superfície primária, se o pipeline de pixel executar a codificação, qualquer operação de inversão solicitada em um intervalo VSync não deverá ser relatada antes que a codificação termine de acessar a superfície primária. Esse comportamento impede que o apresentador renderize para a superfície primária enquanto o mecanismo de codificação está lendo a partir dele.

O driver de modo de usuário miracast deve informar o sistema operacional em cada um dos vários estágios de processamento do quadro:

  • Quadro inicial, tipo de parte MIRACAST_CHUNK_TYPE_FRAME_START

    Representa o ponto em que o sistema operacional solicita que o driver exiba o novo quadro da área de trabalho. Embora tecnicamente o driver de modo de usuário Miracast possa relatar esse estágio, o início do processamento de um novo quadro sempre envolve o driver de miniporta de exibição e, portanto, deve ser relatado por esse driver.

  • Conversão de cores concluída, tipo de parte MIRACAST_CHUNK_TYPE_COLOR_CONVERT_COMPLETE

    Algumas soluções têm estágios separados de conversão e codificação de cores. Nessas soluções, o evento de processamento completo de conversão de cores deve ser relatado assim que possível e o driver deve usar o DXGK_MIRACAST_CHUNK_INFO. Membro ProcessingTime para relatar o tempo necessário para o hardware executar a operação. Se o quadro inteiro for convertido de uma só vez em vez de em fatias, o número da parte deverá ser zero.

  • Codificar completo, tipo de parte MIRACAST_CHUNK_TYPE_ENCODE_COMPLETE

    Indica que a codificação H.264 foi concluída. Os membros ProcessingTime e EncodeRate da estrutura DXGK_MIRACAST_CHUNK_INFO devem ser concluídos.

  • Envio de quadro, chamando ReportStatistic usando MIRACAST_STATISTIC_TYPE_CHUNK_SENT

    Indica que o driver de modo de usuário miracast está prestes a enviar o pacote de dados para esse número de quadro/parte para a API de rede para transmissão. Se os dados desse quadro/parte forem enviados usando várias chamadas para a API de rede, eles só deverão ser registrados logo antes do primeiro pacote ser enviado. A chamada deve ser feita pouco antes de chamar a API de rede. Esse tempo é importante porque, se a API de rede bloquear chamadas, não queremos que esse tempo bloqueado conte com o processamento do quadro na pilha de gráficos.

  • Quadro descartado, tipo de bloco MIRACAST_CHUNK_TYPE_FRAME_DROPPED

    Se a qualquer momento o driver decidir que não concluirá o processamento do quadro/parte e o enviará para o coletor, ele deverá relatar o quadro descartado. Nesse contexto, um quadro só será considerado descartado se o driver realmente começou a processá-lo registrando MIRACAST_CHUNK_TYPE_FRAME_START. Se um driver calcular que vai ignorar esse quadro sem nenhum processamento, ele poderá registrar MIRACAST_CHUNK_TYPE_FRAME_DROPPED sem registrar MIRACAST_CHUNK_TYPE_FRAME_START.

  • Tipo de parte definido pelo driver MIRACAST_CHUNK_TYPE_ENCODE_DRIVER_DEFINED_1 ou _2

    Esses tipos de partes estão disponíveis para ajudá-lo a entender o desempenho de um cenário. Alguns exemplos incluem:

    • O driver usa esses tipos para indicar que um I-Frame foi criado para esse quadro.
    • O driver registra outro pacote depois que a última fatia do quadro foi enviada para APIs de rede que continham o tamanho total do quadro codificado.

Exemplos de conversão de cor de quadro

Os exemplos a seguir mostram como a cor do quadro é convertida e como o driver de miniporta de exibição relata a conclusão da conversão de cores.

As referências de tabela aos membros da estrutura MIRACAST_CHUNK_INFO são:

  • ChunkType é um valor MIRACAST_CHUNK_TYPE_XXX .

  • FrameNumber e PartNumber são membros da união ChunkId .

  • ProcessingTime é o tempo em microssegundos.

  • EncodeRate está em quilobits por segundo.

MIRACAST_STATISTIC_TYPE_CHUNK_SENT é usado em estágios de processamento envolvendo chamadas para ReportStatistic.

Relatar um único quadro sem usar fatias

Estágio de processamento ChunkType FrameNumber PartNumber ProcessingTime EncodeRate
Iniciar o processamento do quadro FRAME_START 101 0 0 0
A conversão de cores foi concluída COLOR_CONVERT_COMPLETE 101 0 950 0
A codificação foi concluída ENCODE_COMPLETE 101 0 1042 15000
Logo antes da chamada para enviar dados para a chamada ReportStatistic de rede n/d 101 (valor de ChunkSent.ChunkId.FrameNumber) 0 (valor de ChunkSent.ChunkId.PartNumber) n/d n/d

Relatar um único quadro, processado usando fatias

Estágio de processamento ChunkType FrameNumber PartNumber ProcessingTime Taxa de Codificação
Iniciar o quadro de processamento FRAME_START 101 0 0 0
A conversão de cores foi concluída COLOR_CONVERT_COMPLETE 101 0 950 0
A codificação da fatia 1 foi concluída ENCODE_COMPLETE 101 1 1042 15000
A codificação da fatia 2 foi concluída ENCODE_COMPLETE 101 0 400 15000
Pouco antes da chamada para enviar dados de fatia 1 para a chamada ReportStatistic de rede n/d 101 (valor de ChunkSent.ChunkId.FrameNumber para a fatia 1) 1 (valor de ChunkSent.ChunkId.PartNumber para a fatia 1) n/d n/d
Pouco antes da chamada para enviar dados de fatia 2 para a chamada ReportStatistic de rede n/d 101 (valor de ChunkSent.ChunkId.FrameNumber para a fatia 2) 0 (valor de ChunkSent.ChunkId.FrameNumber para a fatia 2) n/d n/d

Relatar um quadro original, processado e recodificado sem usar fatias

Estágio de processamento ChunkType FrameNumber PartNumber ProcessingTime Taxa de Codificação
Iniciar o quadro de processamento FRAME_START 101 0 0 0
A conversão de cores foi concluída COLOR_CONVERT_COMPLETE 101 0 950 0
A codificação foi concluída ENCODE_COMPLETE 101 0 1042 15000
Pouco antes da chamada para enviar dados para o quadro original para a chamada ReportStatistic de rede n/d 101 (valor de ChunkSent.ChunkId.FrameNumber) 0 (valor de ChunkSent.ChunkId.PartNumber) n/d n/d
A recodificação foi concluída ENCODE_COMPLETE 101 0 500 15000
Pouco antes da chamada para enviar dados para o quadro recodificado para a rede ReportStatistic n/d 101 (valor de ChunkSent.ChunkId.FrameNumber) 0 (valor de ChunkSent.ChunkId.PartNumber) n/d n/d

Eventos de protocolo de relatório

Quando o driver do modo de usuário miracast relata eventos de protocolo chamando a função ReportStatistic com MIRACAST_STATISTIC_DATA. StatisticType definido como MIRACAST_STATISTIC_TYPE_EVENT, o sistema operacional registra o evento, mas não executa nenhuma outra ação. No entanto, esses eventos são valiosos para diagnóstico e investigação de desempenho.

A enumeração MIRACAST_PROTOCOL_EVENT inclui possíveis tipos de evento de protocolo que podem ser relatados.

Relatar erros de protocolo

Enquanto uma sessão conectada do Miracast estiver em andamento, se um driver de modo de usuário miracast descobrir um erro, ele deverá chamar a função de retorno de chamada ReportSessionStatus com o erro de MIRACAST_STATUS apropriado status informações no parâmetro MiracastStatus. A sessão operacional sempre destrói a sessão quando um erro é relatado.

Embora o sistema operacional apenas registre o parâmetro ReportSessionStatusStatus para diagnóstico e não execute nenhuma ação com base em seu valor, o driver deve usar esse parâmetro para diferenciar as diferentes causas do erro.