Création de rapports Miracast encodent des segments et des statistiques sur Windows 8.1
Remarque
À 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 :
Création de solutions de projection sans fil de classe optimales avec Windows 10
Documentation WHLK pertinente sur Device.Graphics.WDDM13.DisplayRender.WirelessDisplay
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 sur un lien d’affichage sans fil Miracast en fractionnant l’image en plusieurs parties ou encodez des blocs. Chaque bloc a un ID de bloc unique généré à partir du numéro d’image et du numéro de partie d’image (ou de tranche). Chaque bloc lié à la même mise à jour de trame de bureau doit être affecté au même numéro d’image.
Traitement de bloc de création de rapports
Un pilote peut encoder un frame à envoyer sur 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 être affectée à un numéro de partie d’image unique dans le cadre.
Le pilote en mode utilisateur Miracast ou le pilote miniport d’affichage doivent notifier le système d’exploitation chaque fois que :
- Le matériel a effectué une étape de traitement pour une trame.
- Juste avant que chaque partie de l’image soit envoyée au réseau.
L’heure d’une étape de traitement signalée particulière est supposée être le moment où 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 action autre que de consigner ces événements à l’aide de la fonctionnalité de suivi d’événements pour Windows (ETW) au niveau du noyau. Ces informations sont néanmoins importantes pour mesurer et examiner les problèmes de performances.
Un pilote peut fournir la notification à l’aide de 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 la transmission.
- Le pilote miniport d’affichage signale les détails du traitement de 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. Outre la journalisation des 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 à tout 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 d’image et les numéros de partie doivent être utilisés si l’image de bureau n’est pas mise à jour, mais que le pilote doit à nouveau encoder 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 partie, indiquant qu’un deuxième encodage du même frame a été effectué.
La dernière tranche de chaque image doit avoir un numéro de partie d’image égal à zéro, ce qui indique la dernière tranche de l’image aux outils de performances.
Pour garantir la 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 n’ait terminé d’accéder à la surface primaire. Ce comportement empêche le présentateur de s’afficher sur la surface principale pendant que le moteur d’encodage lisent à partir de celui-ci.
Le pilote en mode utilisateur Miracast doit informer le système d’exploitation à chacune des étapes de traitement de l’image :
Cadre de démarrage, type de segment 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 segment MIRACAST_CHUNK_TYPE_COLOR_CONVERT_COMPLETE
Certaines solutions ont des étapes de conversion de couleur et d’encodage 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 signale le temps nécessaire pour que le matériel effectue l’opération. Si l’intégralité du cadre est convertie en une seule fois plutôt que dans des tranches, le numéro de partie doit être égal à zéro.
Encoder le type complet, le type de segment MIRACAST_CHUNK_TYPE_ENCODE_COMPLETE
Indique que le code H.264 a été terminé. Les membres ProcessingTime et EncodeRate de la structure DXGK_MIRACAST_CHUNK_INFO doivent être terminés.
Envoi d’images, 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 pour ce numéro de trame/partie à l’API réseau pour la transmission. Si les données de cette trame/partie sont envoyées à l’aide de plusieurs appels à l’API réseau, elles ne doivent être enregistrées que juste 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 le 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, à tout moment, le pilote décide qu’il ne termine pas le traitement de l’image/partie et l’envoie au récepteur, il doit signaler l’image supprimée. Dans ce contexte, une trame est considérée comme supprimée uniquement si le pilote a réellement commencé à le traiter en journalisant MIRACAST_CHUNK_TYPE_FRAME_START. Si un pilote calcule qu’il va ignorer cette trame sans traitement, il peut journaliser MIRACAST_CHUNK_TYPE_FRAME_DROPPED sans journalisation MIRACAST_CHUNK_TYPE_FRAME_START.
Type de segment défini par le pilote MIRACAST_CHUNK_TYPE_ENCODE_DRIVER_DEFINED_1 ou _2
Ces types de segments 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 cette trame.
- Le pilote enregistre un autre paquet après que la dernière tranche de l’image a été envoyée aux API réseau qui contenaient la taille totale de l’image encodée.
Exemples de conversion de couleur de cadre
Les exemples suivants montrent comment la couleur du cadre est convertie et comment le pilote 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 l’heure en microsecondes.
EncodeRate est en kilobits par seconde.
MIRACAST_STATISTIC_TYPE_CHUNK_SENT est utilisé dans les phases de traitement impliquant des appels à ReportStatistic.
Création de rapports d’une trame unique sans utiliser de tranches
Phase de traitement | ChunkType | FrameNumber | PartNumber | ProcessingTime | EncodeRate |
---|---|---|---|---|---|
Démarrer le traitement du frame | FRAME_START | 101 | 0 | 0 | 0 |
La conversion de couleur 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 à un appel ReportStatistic réseau | n/a | 101 (valeur de ChunkSent.ChunkId.FrameNumber) | 0 (valeur de ChunkSent.ChunkId.PartNumber) | n/a | n/a |
Création de rapports sur une seule image, traitée à l’aide de tranches
Phase de traitement | ChunkType | FrameNumber | PartNumber | ProcessingTime | EncodeRate |
---|---|---|---|---|---|
Démarrer le traitement du frame | FRAME_START | 101 | 0 | 0 | 0 |
La conversion de couleur 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 ReportStatistic réseau | 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 des données de tranche 2 à un appel ReportStatistic réseau | 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
Phase de traitement | ChunkType | FrameNumber | PartNumber | ProcessingTime | EncodeRate |
---|---|---|---|---|---|
Démarrer le traitement du frame | FRAME_START | 101 | 0 | 0 | 0 |
La conversion de couleur 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 l’image d’origine à l’appel ReportStatistic réseau | n/a | 101 (valeur de ChunkSent.ChunkId.FrameNumber) | 0 (valeur de ChunkSent.ChunkId.PartNumber) | n/a | n/a |
Le recodage est terminé | ENCODE_COMPLETE | 101 | 0 | 500 | 15000 |
Juste avant d’appeler pour envoyer des données pour une trame réencodée au réseau ReportStatistic | n/a | 101 (valeur de ChunkSent.ChunkId.FrameNumber) | 0 (valeur de ChunkSent.ChunkId.PartNumber) | n/a | n/a |
Événements de protocole de création de rapports
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 utiles pour les diagnostics et l’investigation 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
Si 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 les informations d’état d’erreur appropriées MIRACAST_STATUS 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 ReportSessionStatus Status pour les 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.