Création de rapports sur les segments et statistiques d’encodage Miracast sur Windows 8.1

  • Article

Notes

À compter de Windows 10 (WDDM 2.0), le système d’exploitation est fourni avec une pile Miracast intégrée qui peut fonctionner sur n’importe quel GPU. Pour plus d’informations sur la pile Microsoft Miracast et la configuration requise des pilotes et du matériel pour prendre en charge les affichages Miracast à partir de Windows 10, consultez la documentation suivante :

Les développeurs de pilotes ne doivent plus implémenter une pile Miracast personnalisée. Microsoft peut supprimer la prise en charge des piles Miracast personnalisées dans une version ultérieure de Windows.

Sur Windows 8.1, le matériel d’affichage peut traiter chaque image vidéo envoyée via un lien d’affichage sans fil Miracast en fractionnant l’image en plusieurs parties ou encodant des blocs. Chaque bloc a un ID de bloc unique généré à partir du numéro de trame et du numéro de la partie (ou de la tranche) de l’image. Chaque bloc lié à la même mise à jour de trame de bureau doit se voir attribuer le même numéro de trame.

Traitement des blocs de rapports

Un pilote peut encoder un frame à envoyer via une liaison sans fil Miracast en plusieurs étapes de traitement (par exemple en séparant la conversion de couleur de l’encodage) ou en une seule étape. Chaque étape de traitement doit se voir attribuer un numéro de référence unique dans le cadre.

Le pilote en mode utilisateur Miracast ou le pilote miniport d’affichage doivent avertir le système d’exploitation chaque fois que :

  • Le matériel a terminé une étape de traitement pour un frame.
  • Immédiatement avant l’envoi de chaque partie de la trame au réseau.

L’heure d’une étape de traitement signalée particulière est supposée être l’heure à laquelle l’événement a été signalé au système d’exploitation. Il est donc important de signaler les étapes aussi rapidement que possible.

Le système d’exploitation n’effectue aucune autre action que de journaliser ces événements à l’aide de la fonctionnalité de suivi au niveau du noyau EtW (Event Tracing for Windows). Ces informations sont néanmoins importantes pour mesurer et examiner les problèmes de performances.

Un pilote peut fournir la notification en utilisant l’une des méthodes possibles suivantes :

  • Le pilote en mode utilisateur Miracast appelle la fonction de rappel ReportStatistic pour signaler les détails avec le type MIRACAST_STATISTIC_TYPE_CHUNK_PROCESSING_COMPLETE ou avec MIRACAST_STATISTIC_TYPE_CHUNK_SENT pour indiquer que le bloc est sur le point d’être envoyé à la pile réseau pour transmission.
  • Le pilote miniport d’affichage indique les détails du traitement du bloc avec le type d’interruption DXGK_INTERRUPT_MICACAST_CHUNK_PROCESSING_COMPLETE , bien que ce rapport ne puisse être effectué qu’au moment de l’interruption. En plus de journaliser les informations de bloc, un paquet de blocs est créé et mis en file d’attente afin que le pilote en mode utilisateur Miracast puisse le récupérer en appelant la fonction de rappel GetNextChunkData .
  • Le pilote miniport d’affichage appelle la fonction de rappel DxgkCbReportChunkInfo à n’importe quel niveau IRQL. Cette fonction journalise uniquement les informations de bloc et ne met pas en file d’attente les paquets de blocs.

Le même numéro de trame et les mêmes numéros de référence doivent être utilisés si l’image de bureau n’est pas mise à jour, mais que le pilote doit encoder à nouveau l’image de bureau pour améliorer la qualité. Les outils de performances déclenchent le deuxième événement d’encodage complet pour le même frame et le même numéro de référence, ce qui indique qu’un deuxième encodage de la même image a été effectué.

La dernière tranche de chaque image doit avoir un numéro de partie de frame égal à zéro, ce qui indique la dernière tranche de l’image aux outils de performance.

Pour garantir une synchronisation correcte de la surface primaire, si le pipeline de pixels effectue l’encodage, toute opération de retournement demandée à un intervalle VSync ne doit pas être signalée avant que l’encodage ait terminé d’accéder à la surface primaire. Ce comportement empêche le présentateur de s’afficher sur la surface primaire pendant que le moteur d’encodage est en cours de lecture à partir de celui-ci.

Le pilote en mode utilisateur Miracast doit informer le système d’exploitation à chacune des différentes étapes du traitement du frame :

  • Cadre de démarrage, type de bloc MIRACAST_CHUNK_TYPE_FRAME_START

    Représente le point où le système d’exploitation demande au pilote d’afficher le nouveau cadre de bureau. Bien que techniquement le pilote en mode utilisateur Miracast puisse signaler cette étape, le début du traitement d’une nouvelle image implique toujours le pilote miniport d’affichage, et doit donc être signalé par ce pilote.

  • Conversion de couleur terminée, type de bloc MIRACAST_CHUNK_TYPE_COLOR_CONVERT_COMPLETE

    Certaines solutions ont des étapes de conversion et d’encodage de couleur distinctes. Dans ces solutions, l’événement de traitement complet de conversion de couleur doit être signalé dès que possible, et le pilote doit utiliser le DXGK_MIRACAST_CHUNK_INFO. Le membre ProcessingTime pour signaler le temps nécessaire au matériel pour effectuer l’opération. Si le cadre entier est converti en couleur à la fois plutôt qu’en tranches, le numéro de référence doit être égal à zéro.

  • Encodage complet, type de bloc MIRACAST_CHUNK_TYPE_ENCODE_COMPLETE

    Indique que l’encodage H.264 a été terminé. Les membres ProcessingTime et EncodeRate de la structure DXGK_MIRACAST_CHUNK_INFO doivent être terminés.

  • Envoi de frame, appel de ReportStatistic à l’aide de MIRACAST_STATISTIC_TYPE_CHUNK_SENT

    Indique que le pilote en mode utilisateur Miracast est sur le point d’envoyer le paquet de données de ce numéro de trame/de référence à l’API réseau pour transmission. Si les données de cette trame/partie sont envoyées à l’aide de plusieurs appels à l’API de mise en réseau, elles ne doivent être enregistrées qu’avant l’envoi du premier paquet. L’appel doit être effectué juste avant d’appeler l’API réseau. Ce minutage est important, car si l’API réseau bloque les appels, nous ne voulons pas que ce temps bloqué soit comptabilisé par rapport au traitement de l’image dans la pile graphique.

  • Cadre supprimé, type de bloc MIRACAST_CHUNK_TYPE_FRAME_DROPPED

    Si, à un moment donné, le pilote décide qu’il ne terminera pas le traitement de l’image/de la partie et ne l’enverra pas au récepteur, il doit signaler le frame supprimé. Dans ce contexte, un frame n’est considéré comme supprimé que si le pilote a réellement commencé à le traiter en journalisant MIRACAST_CHUNK_TYPE_FRAME_START. Si un pilote calcule qu’il va ignorer ce frame sans traitement, il peut journaliser MIRACAST_CHUNK_TYPE_FRAME_DROPPED sans journaliser MIRACAST_CHUNK_TYPE_FRAME_START.

  • Type de bloc défini par le pilote MIRACAST_CHUNK_TYPE_ENCODE_DRIVER_DEFINED_1 ou _2

    Ces types de blocs sont disponibles pour vous aider à comprendre les performances d’un scénario. Voici quelques exemples :

    • Le pilote utilise ces types pour indiquer qu’un I-Frame a été créé pour ce frame.
    • Le pilote enregistre un autre paquet après l’envoi de la dernière tranche de la trame aux API réseau qui contenaient la taille totale du frame codé.

Exemples de conversion de couleur de cadre

Les exemples suivants montrent comment la couleur du cadre est convertie et comment le pilote de miniport d’affichage signale l’achèvement de la conversion de couleur.

Les références de table aux membres de la structure MIRACAST_CHUNK_INFO sont les suivantes :

  • ChunkType est une valeur MIRACAST_CHUNK_TYPE_XXX .

  • FrameNumber et PartNumber sont membres de l’union ChunkId .

  • ProcessingTime est le temps en microsecondes.

  • EncodeRate est en kilobits par seconde.

MIRACAST_STATISTIC_TYPE_CHUNK_SENT est utilisé dans les étapes de traitement impliquant des appels à ReportStatistic.

Signalement d’une trame unique sans utiliser de tranches

Étape de traitement ChunkType FrameNumber PartNumber ProcessingTime EncodeRate
Démarrer le traitement du frame FRAME_START 101 0 0 0
La conversion des couleurs est terminée COLOR_CONVERT_COMPLETE 101 0 950 0
L’encodage est terminé ENCODE_COMPLETE 101 0 1042 15000
Juste avant l’appel pour envoyer des données au réseau ReportStatistic appel n/a 101 (valeur de ChunkSent.ChunkId.FrameNumber) 0 (valeur de ChunkSent.ChunkId.PartNumber) n/a n/a

Signalement d’une trame unique, traitée à l’aide de tranches

Étape de traitement ChunkType FrameNumber PartNumber ProcessingTime EncodeRate
Démarrer le traitement du frame FRAME_START 101 0 0 0
La conversion des couleurs est terminée COLOR_CONVERT_COMPLETE 101 0 950 0
L’encodage de la tranche 1 est terminé ENCODE_COMPLETE 101 1 1042 15000
L’encodage de la tranche 2 est terminé ENCODE_COMPLETE 101 0 400 15000
Juste avant l’appel pour envoyer des données de tranche 1 à un appel réseau ReportStatistic n/a 101 (valeur de ChunkSent.ChunkId.FrameNumber pour la tranche 1) 1 (valeur de ChunkSent.ChunkId.PartNumber pour la tranche 1) n/a n/a
Juste avant l’appel pour envoyer les données de la tranche 2 au réseau ReportStatistic appel n/a 101 (valeur de ChunkSent.ChunkId.FrameNumber pour la tranche 2) 0 (valeur de ChunkSent.ChunkId.FrameNumber pour la tranche 2) n/a n/a

Création de rapports sur une trame d’origine, traitée, puis réencodée sans utiliser de tranches

Étape de traitement ChunkType FrameNumber PartNumber ProcessingTime EncodeRate
Démarrer le traitement du frame FRAME_START 101 0 0 0
La conversion des couleurs est terminée COLOR_CONVERT_COMPLETE 101 0 950 0
L’encodage est terminé ENCODE_COMPLETE 101 0 1042 15000
Juste avant l’appel pour envoyer des données pour la trame d’origine à l’appel réseau ReportStatistic n/a 101 (valeur de ChunkSent.ChunkId.FrameNumber) 0 (valeur de ChunkSent.ChunkId.PartNumber) n/a n/a
Le réencodage est terminé ENCODE_COMPLETE 101 0 500 15000
Juste avant d’appeler pour envoyer des données pour une trame réencodée sur le réseau ReportStatistic n/a 101 (valeur de ChunkSent.ChunkId.FrameNumber) 0 (valeur de ChunkSent.ChunkId.PartNumber) n/a n/a

Rapports d’événements de protocole

Lorsque le pilote en mode utilisateur Miracast signale des événements de protocole en appelant la fonction ReportStatistic avec MIRACAST_STATISTIC_DATA. StatisticType défini sur MIRACAST_STATISTIC_TYPE_EVENT, le système d’exploitation enregistre l’événement, mais n’effectue aucune autre action. Ces événements sont néanmoins précieux pour diagnostics et l’examen des performances.

L’énumération MIRACAST_PROTOCOL_EVENT inclut les types d’événements de protocole possibles qui peuvent être signalés.

Signaler des erreurs de protocole

Pendant qu’une session connectée à Miracast est en cours, si un pilote en mode utilisateur Miracast détecte une erreur, il doit appeler la fonction de rappel ReportSessionStatus avec l’erreur MIRACAST_STATUS appropriée status informations dans le paramètre MiracastStatus. La session d’exploitation détruit toujours la session lorsqu’une erreur est signalée.

Bien que le système d’exploitation enregistre simplement le paramètre ReportSessionStatusStatus pour diagnostics et n’effectue aucune action en fonction de sa valeur, le pilote doit utiliser ce paramètre pour différencier les différentes causes de l’erreur.