Generación de informes de Miracast codifica fragmentos y estadísticas en Windows 8.1
Nota:
A partir de Windows 10 (WDDM 2.0), el sistema operativo se incluye con una pila de Miracast integrada que puede funcionar en cualquier GPU. Para obtener información sobre la pila de Microsoft Miracast y los requisitos de controladores y hardware para admitir pantallas de Miracast a partir de Windows 10, consulte la siguiente documentación:
Creación de soluciones de proyección inalámbrica de primera clase con Windows 10
La documentación pertinente de WHLK en Device.Graphics.WDDM13.DisplayRender.WirelessDisplay
Los desarrolladores de controladores ya no deben implementar una pila personalizada de Miracast. Microsoft podría quitar la compatibilidad con pilas de Miracast personalizadas en una versión futura de Windows.
En Windows 8.1, el hardware de pantalla puede procesar cada fotograma de vídeo enviado a través de un vínculo de pantalla inalámbrica miracast dividiendo el marco en varias partes o codificar fragmentos. Cada fragmento tiene un identificador de fragmento único que se genera a partir del número de fotograma y el número de parte de marco (o segmento). A cada fragmento relacionado con la misma actualización de fotogramas de escritorio se le debe asignar el mismo número de fotograma.
Procesamiento de fragmentos de informes
Un controlador puede codificar un marco que se enviará a través de un vínculo inalámbrico miracast en varios pasos de procesamiento (por ejemplo, separar la conversión de color de la codificación) o en un solo paso. A cada paso de procesamiento se le debe asignar un número de pieza de marco único dentro del marco.
El controlador del modo de usuario de Miracast o el controlador de minipuerto de pantalla deben notificar al sistema operativo cada vez que:
- El hardware ha completado un paso de procesamiento para un fotograma.
- Inmediatamente antes de que se envíe cada parte del marco a la red.
Se supone que el tiempo de un paso de procesamiento notificado determinado es el momento en que se informó del evento al sistema operativo, por lo que es importante notificar las fases lo antes posible.
El sistema operativo no realiza ninguna acción distinta de registrar estos eventos mediante la instalación de seguimiento de eventos para Windows (ETW). Sin embargo, esta información es importante para medir e investigar los problemas de rendimiento.
Un controlador puede proporcionar la notificación mediante una de las siguientes maneras posibles:
- El controlador del modo de usuario de Miracast llama a la función de devolución de llamada ReportStatistic para informar de los detalles con el tipo de MIRACAST_STATISTIC_TYPE_CHUNK_PROCESSING_COMPLETE o con MIRACAST_STATISTIC_TYPE_CHUNK_SENT para indicar que el fragmento está a punto de enviarse a la pila de red para la transmisión.
- El controlador de miniporte de pantalla informa de los detalles del procesamiento de fragmentos con el tipo de interrupción DXGK_INTERRUPT_MICACAST_CHUNK_PROCESSING_COMPLETE , aunque este informe solo se puede realizar en tiempo de interrupción. Además de registrar la información del fragmento, se crea y pone en cola un paquete de fragmentos para que el controlador del modo de usuario de Miracast pueda recuperarlo llamando a la función de devolución de llamada GetNextChunkData.
- El controlador de minipuerto de pantalla llama a la función de devolución de llamada DxgkCbReportChunkInfo en cualquier nivel IRQL. Esta función registra solo la información del fragmento y no pone en cola ningún paquete de fragmentos.
Se deben usar el mismo número de fotograma y números de pieza si la imagen de escritorio no se actualiza, pero el controlador debe volver a codificar la imagen de escritorio para mejorar la calidad. Las herramientas de rendimiento desencadenan el segundo evento completo de codificación para el mismo fotograma y número de pieza, lo que indica que se realizó una segunda codificación del mismo fotograma.
El último segmento de cada fotograma debe tener un número de pieza de fotograma de cero, que indica el último segmento del marco para las herramientas de rendimiento.
Para garantizar la sincronización correcta de la superficie principal, si la canalización de píxeles realiza la codificación, no se debe notificar ninguna operación de volteo solicitada en un intervalo de VSync antes de que la codificación haya terminado de acceder a la superficie principal. Este comportamiento impide que el moderador se representa en la superficie principal mientras el motor de codificación lo lee.
El controlador del modo de usuario de Miracast debe informar al sistema operativo en cada una de varias fases de procesamiento del marco:
Iniciar marco, tipo de fragmento MIRACAST_CHUNK_TYPE_FRAME_START
Representa el punto en el que el sistema operativo pide al controlador que muestre el nuevo marco de escritorio. Aunque técnicamente el controlador del modo de usuario de Miracast podría notificar esta fase, el inicio del procesamiento de un nuevo marco siempre implica el controlador de miniporte de pantalla y, por lo tanto, debe ser notificado por ese controlador.
Conversión de color completa, tipo de fragmento MIRACAST_CHUNK_TYPE_COLOR_CONVERT_COMPLETE
Algunas soluciones tienen fases de conversión y codificación de colores independientes. En estas soluciones, el evento de procesamiento completo de conversión de color se debe notificar lo antes posible y el controlador debe usar el DXGK_MIRACAST_CHUNK_INFO.Miembro ProcessingTime para informar del tiempo que tardó el hardware en realizar la operación. Si el marco completo se convierte todo a la vez en lugar de en segmentos, el número de pieza debe ser cero.
Codificación completa, tipo de fragmento MIRACAST_CHUNK_TYPE_ENCODE_COMPLETE
Indica que se ha completado la codificación H.264. Los miembros ProcessingTime y EncodeRate de la estructura DXGK_MIRACAST_CHUNK_INFO deben completarse.
Envío de fotogramas, llamada a ReportStatistic mediante MIRACAST_STATISTIC_TYPE_CHUNK_SENT
Indica que el controlador del modo de usuario de Miracast está a punto de enviar el paquete de datos de este número de fotograma o pieza a la API de red para la transmisión. Si los datos de este marco o elemento se envían mediante varias llamadas a la API de red, solo se debe registrar justo antes de enviar el primer paquete. La llamada debe realizarse justo antes de llamar a la API de red. Este tiempo es importante porque si la API de red bloquea las llamadas, no queremos que ese tiempo bloqueado cuente con el procesamiento del fotograma en la pila de gráficos.
Marco quitado, tipo de fragmento MIRACAST_CHUNK_TYPE_FRAME_DROPPED
Si en cualquier momento el controlador decide que no completará el procesamiento del marco o pieza y lo enviará al receptor, debe notificar el marco descartado. En este contexto, solo se considera que se quita un fotograma si el controlador realmente lo ha iniciado a procesar mediante el registro de MIRACAST_CHUNK_TYPE_FRAME_START. Si un controlador calcula que va a omitir este fotograma sin ningún procesamiento, puede registrar MIRACAST_CHUNK_TYPE_FRAME_DROPPED sin registrar MIRACAST_CHUNK_TYPE_FRAME_START.
Tipo de fragmento definido por el controlador MIRACAST_CHUNK_TYPE_ENCODE_DRIVER_DEFINED_1 o _2
Estos tipos de fragmentos están disponibles para ayudarle a comprender el rendimiento de un escenario. Estos son algunos ejemplos:
- El controlador usa estos tipos para indicar que se creó un I-Frame para este fotograma.
- El controlador registra otro paquete después del último segmento del marco se ha enviado a las API de red que contenían el tamaño total del marco codificado.
Ejemplos de conversión de color de marco
En los ejemplos siguientes se muestra cómo se convierte el color del marco y cómo el controlador de miniportar muestra la finalización de la conversión de color.
Las referencias de tabla a los miembros de la estructura MIRACAST_CHUNK_INFO son:
ChunkType es un valor MIRACAST_CHUNK_TYPE_XXX .
FrameNumber y PartNumber son miembros de la unión ChunkId .
ProcessingTime es el tiempo en microsegundos.
EncodeRate está en kilobits por segundo.
MIRACAST_STATISTIC_TYPE_CHUNK_SENT se usa en fases de procesamiento que implican llamadas a ReportStatistic.
Generación de informes de un solo fotograma sin usar segmentos
| Fase de procesamiento | ChunkType | FrameNumber | PartNumber | ProcessingTime | EncodeRate |
|---|---|---|---|---|---|
| Iniciar el marco de procesamiento | FRAME_START | 101 | 0 | 0 | 0 |
| La conversión de color está completa | COLOR_CONVERT_COMPLETE | 101 | 0 | 950 | 0 |
| La codificación está completa | ENCODE_COMPLETE | 101 | 0 | 1042 | 15000 |
| Justo antes de llamar a para enviar datos a la llamada ReportStatistic de red | N/D | 101 (valor de ChunkSent.ChunkId.FrameNumber) | 0 (valor de ChunkSent.ChunkId.PartNumber) | N/D | N/D |
Generación de informes de un solo fotograma, procesado mediante segmentos
| Fase de procesamiento | ChunkType | FrameNumber | PartNumber | ProcessingTime | EncodeRate |
|---|---|---|---|---|---|
| Iniciar el marco de procesamiento | FRAME_START | 101 | 0 | 0 | 0 |
| La conversión de color está completa | COLOR_CONVERT_COMPLETE | 101 | 0 | 950 | 0 |
| La codificación del segmento 1 está completa | ENCODE_COMPLETE | 101 | 1 | 1042 | 15000 |
| La codificación del segmento 2 está completa | ENCODE_COMPLETE | 101 | 0 | 400 | 15000 |
| Justo antes de llamar a para enviar datos de segmento 1 a la llamada ReportStatistic de red | N/D | 101 (valor de ChunkSent.ChunkId.FrameNumber para el segmento 1) | 1 (valor de ChunkSent.ChunkId.PartNumber para el segmento 1) | N/D | N/D |
| Justo antes de llamar a para enviar datos de segmento 2 a la llamada ReportStatistic de red | N/D | 101 (valor de ChunkSent.ChunkId.FrameNumber para el segmento 2) | 0 (valor de ChunkSent.ChunkId.FrameNumber para el segmento 2) | N/D | N/D |
Generación de informes de un marco original, procesado y luego vuelto a codificar sin usar segmentos
| Fase de procesamiento | ChunkType | FrameNumber | PartNumber | ProcessingTime | EncodeRate |
|---|---|---|---|---|---|
| Iniciar el marco de procesamiento | FRAME_START | 101 | 0 | 0 | 0 |
| La conversión de color está completa | COLOR_CONVERT_COMPLETE | 101 | 0 | 950 | 0 |
| La codificación está completa | ENCODE_COMPLETE | 101 | 0 | 1042 | 15000 |
| Justo antes de llamar a para enviar datos del marco original a la llamada ReportStatistic de red | N/D | 101 (valor de ChunkSent.ChunkId.FrameNumber) | 0 (valor de ChunkSent.ChunkId.PartNumber) | N/D | N/D |
| Se ha completado la recodificación | ENCODE_COMPLETE | 101 | 0 | 500 | 15000 |
| Justo antes de llamar a para enviar datos para volver a codificar el marco a la red ReportStatistic | N/D | 101 (valor de ChunkSent.ChunkId.FrameNumber) | 0 (valor de ChunkSent.ChunkId.PartNumber) | N/D | N/D |
Informes de eventos de protocolo
Cuando el controlador en modo de usuario miracast notifica eventos de protocolo llamando a la función ReportStatistic con MIRACAST_STATISTIC_DATA. StatisticType se establece en MIRACAST_STATISTIC_TYPE_EVENT, el sistema operativo registra el evento, pero no realiza ninguna otra acción. Sin embargo, estos eventos son valiosos para la investigación de diagnósticos y rendimiento.
La enumeración MIRACAST_PROTOCOL_EVENT incluye posibles tipos de eventos de protocolo que se pueden notificar.
Informes de errores de protocolo
Mientras una sesión conectada a Miracast está en curso, si un controlador en modo de usuario de Miracast detecta un error, debe llamar a la función de devolución de llamada ReportSessionStatus con la información de estado de error adecuada MIRACAST_STATUS en el parámetro MiracastStatus. La sesión operativa siempre destruye la sesión cuando se notifica un error.
Aunque el sistema operativo simplemente registra el parámetro ReportSessionStatus Status para diagnósticos y no realiza ninguna acción en función de su valor, el controlador debe usar este parámetro para diferenciar entre diferentes causas del error.