Partager via

Résolution des problèmes de test Device.Streaming

  • Article

Pour résoudre les problèmes qui se produisent avec les tests Device.Streaming, procédez comme suit :

  1. Passez en revue les rubriques suivantes du Kit de laboratoire matériel Windows (Windows HLK) :
  2. Consultez les notes de publication de Windows HLK pour connaître les problèmes de test actuels.
  3. En cas d’échec de test, recherchez des informations utilisables dans le journal des tests Windows HLK Studio. Si vous trouvez des informations utilisables, résolvez le problème et réexécutez le test.
  4. Utilisez le fournisseur TraceLogging Microsoft.Windows.CameraDebug pour prendre des journaux afin de résoudre les erreurs du pilote au pipeline de caméra.

Informations spécifiques sur les tests HMFT

Les tests de décodage et d’encodage HMFT (Hardware Media Foundation Transform) nécessitent les éléments suivants :

  • Contenu supplémentaire pour les tests Windows HLK pour les tests multimédias HMFT : téléchargez et installez le contenu supplémentaire pour les tests Windows HLK pour les tests multimédias HMFT à partir du Centre de développement Windows. Pour plus d’informations sur l’installation et la configuration du contenu supplémentaire, consultez Conditions préalables de test HMFT.

  • Fichiers de contenu standard inclus avec windows HLK.

Si le contenu supplémentaire n’est pas disponible sur les ordinateurs clients, vérifiez que le paramètre ContentSource se configure correctement lors de l’exécution des tests HMFT.

Résolution des problèmes de captures vidéo de webcam

Error Description Solution/solution de contournement

Pendant l’installation, le test ne trouve pas la région d’intérêt (ROI).

Le test recherche des marqueurs de retour sur investissement (cercles noirs et blancs) à des emplacements connus sur le test. Si le test ne peut pas identifier les marqueurs de retour sur investissement, le test ne peut pas s’exécuter correctement. L’échec de la détection du retour sur investissement peut être dû à une caméra mal dirigée ou à une capture vidéo inutilisable à partir de l’appareil photo (par exemple, la pièce est trop sombre).

Repositionnez la caméra selon la procédure de test et assurez-vous que la caméra fournit une image utilisable dans des conditions d’éclairage de test.

Pendant la configuration, le retour sur investissement ne s’intègre pas dans la vue de l’appareil photo.

Le test recherche des marqueurs de retour sur investissement (cercles noirs et blancs) à des emplacements connus sur le test. Si le test ne peut pas identifier les marqueurs de retour sur investissement, le test ne peut pas s’exécuter correctement. Les caméras de plus petit champ d’affichage (par exemple, les caméras orientées vers l’arrière) peuvent devoir être positionnées à plus de 0,5 m de la cible de test pour capturer le retour sur investissement requis.

Repositionnez la caméra et vérifiez que la caméra fournit une image utilisable dans des conditions d’éclairage de test. Pour éviter une mesure inexacte de l’exigence de champ de vue, entrez la nouvelle distance dans l’application de test si vous ajustez la position.

Causes racines potentielles de l’échec et recommandations pour l’amélioration des captures vidéo de webcam

Acuité de l’image

Résolution spatiale

La résolution spatiale est mesurée à l’aide de la fonction de transfert de module (réponse de fréquence spatiale). Plus précisément, la métrique MTF30 est utilisée, c’est-à-dire le nombre de cycles/pixels par lequel un MTF=0,3 est obtenu.

Lorsque le MTF30 est inférieur à 0,3, l’image est trop molle ou floue. Bien que ce problème puisse être dû à une optique de mauvaise qualité, il est généralement dû à un traitement médiocre du signal d’image (mise à l’échelle d’image, démosaïquement, etc.). Lorsque le MTF30 est supérieur à 0,8, l’image peut être trop aliasée. Ce problème est souvent dû au traitement du signal d’image de mauvaise qualité, en particulier à la mise à l’échelle (par exemple, l’interpolation voisine la plus proche au lieu d’une interpolation bi-cubique avec anti-aliasing).

Plage de focus (profondeur de champ)

La plage de focus est requise pour que l’appareil photo se concentre sur des objets à une distance de 0,3 m à l’infini, que l’autofocus soit utilisé ou non. La métrique de résolution spatiale MTF30 détermine la plage de focus. Si cette métrique échoue sur une caméra de mise au point manuelle, un problème de conception peut en être la cause ; par exemple, la profondeur théorique de champ est de 0,3 m à l’infini quand il est > concentré sur une distance cible de 0,5 m pour les notebooks/tablettes, ou de 0,7 m pour les tout-en-un. Si la distance cible est correcte, vous devrez peut-être modifier l’optique pour obtenir la profondeur de champ correcte.

Si un objectif de mise au point automatique est utilisé et échoue à cette métrique, un problème dans l’algorithme d’autofocus est la cause la plus probable.

Parasite

Rapport signal spatial/bruit

Le bruit spatial mesure la variation spatiale dans une seule image à l’aide d’un patch gris neutre (densité 0,7) dans le graphique de test. Si cette métrique échoue, c’est probablement en raison d’un capteur de mauvaise qualité (sensibilité insuffisante) ou d’une suppression insuffisante de la noisation de l’image. Les capteurs d’image doivent être sélectionnés qui ont un SNR10 (le niveau de lux requis pour obtenir un SNR=10 sur un correctif de densité de 0,7 sans dé-noisation) de < 50 lux. Un certain niveau de désagrément d’image est acceptable, mais ne devrait pas dégrader significativement l’acutance de texture. Une méthode de mesure de l’acutance de texture (indépendamment de Windows HLK) est fournie dans la spécification Lync Logo Video Capture (Rev G). Pour plus d’informations sur les spécifications du logo Lync, consultez Périphériques USB et spécifications de test des PC Lync.

Rapport signal/bruit temporel

Le bruit temporel mesure la variation temporelle dans deux images à l’aide d’un patch gris neutre (densité de 0,7) dans le graphique de test. Si cette métrique échoue, c’est probablement en raison d’un capteur de mauvaise qualité (sensibilité insuffisante), d’un gain automatique médiocre (AGC) et d’un contrôle automatique de l’exposition (AEC), d’un mauvais contrôle de la fréquence de la ligne d’alimentation ou d’une suppression insuffisante de l’image. Un contrôle AEC/AGC instable peut provoquer un scintillement visible. Le contrôle de fréquence de la ligne électrique est utilisé pour détecter l’éclairage de 50/60 Hz. Ajuster l’exposition ; si cela ne fonctionne pas bien, le scintillement (à l’aide du scintillement roulant) est apparent dans la vidéo.

Qualité des couleurs

Luminance pour un patch gris neutre (densité 0,7)

Le contrôle automatique du gain et de l’exposition doit produire une image afin que la tache grise neutre du graphique de test ait une luminance de 128 +/- 40 niveaux de gris. Si cela échoue et que la luminance est < de 88, cela est dû à un AEC/AGC médiocre ou à un capteur d’image qui a une faible sensibilité. Dans la plupart des cas, vous pouvez résoudre le problème en paramétrant AEC/AGC. Si la luminance est > 168, un problème existe également avec AEC/AGC.

Précision des couleurs

La précision des couleurs est mesurée à l’aide de la valeur maximale et moyenne ΔC₀₀ par rapport aux couleurs connues dans le graphique de test ColorChecker. En cas d’échec de cette métrique, il peut s’agir d’un problème d’équilibrage des blancs ou d’homogénéité des couleurs, qui peuvent être améliorés en réglant le traitement du signal d’image.

Gamma

Gamma mesure l’opération non linéaire utilisée pour coder des valeurs de luminance ou de tristimulus dans des images vidéo ou fixes. Lorsque la valeur gamma est > de 0,75, les images peuvent paraître trop saturées; lorsque gamma est < de 0,4, les images peuvent paraître sous-saturées. Les deux problèmes peuvent être résolus en ajustant le traitement gamma dans le traitement du signal d’image.

Géométrie

Champ de vue vertical

L’exigence de champ de vue vertical pour les caméras orientées utilisateur est ≥ 35INVALID USE OF SYMBOLS et pour les caméras arrière, elle est ≥ 25INVALID USE OF SYMBOLS. Lorsque ce test échoue, cela peut être dû au rognage d’image (sans utiliser le capteur d’image entier), qui peut être résolu dans le traitement du signal d’image. Cependant, le problème est probablement dû à la conception de l’objectif. Dans ce cas, une lentille nouvelle ou modifiée est requise.

Minutage

Fréquence d’images

La fréquence d’images vidéo doit être ≥ 14 FPS dans 20 lux de lumière et ≥ 29 FPS dans 80 lux de lumière. Si la fréquence d’images est inférieure à ces exigences, vous pouvez généralement la corriger en réglant l’exposition automatique et en prenant le contrôle.

Latence

La latence vidéo mesure le temps d’entrée des photons dans l’appareil photo pour les photons hors de l’écran. La latence vidéo requise est ≤ 80 ms pour les caméras MIPI et ≤ 120 ms pour les caméras USB ; cette défaillance est souvent due à de faibles fréquences d’images ou à un traitement du signal d’image qui utilise une ou plusieurs mémoires tampons d’images. Vous pouvez résoudre ces deux problèmes en améliorant le traitement du signal d’image de la caméra.

Synchronisation audio/vidéo

La synchronisation audio/vidéo mesure la différence de temps entre l’audio capturé et la vidéo capturée. L’échec de cette métrique est souvent dû à une défaillance de la latence vidéo ou audio. Pour plus d’informations, consultez Test de fidélité audio des communications (système, manuel).

Temps de capture et de remise du premier cadre photo ou vidéo

Les premiers cadres vidéo et photo doivent être capturés dans les 500 ms suivant le démarrage de la vidéo ou la prise d’une photo. La raison la plus courante de l’échec de cette exigence est l’exposition automatique lente et la convergence de contrôle de gain, que vous pouvez améliorer en paramétrant AEC/AGC.

Délai de remise d’une photo dans les demandes suivantes (état stable)

Les images photo suivantes doivent être capturées dans les 250 ms (sans flash) et 500 ms (avec flash). Une raison courante de ne pas respecter cette exigence est l’exposition automatique lente et la convergence de contrôle de gain, que vous pouvez améliorer en paramétrant AEC/AGC.

Délai de modification des résolutions (n’importe quel type de média)

La durée de modification des résolutions (par exemple, 720p à 360p) doit être ≤ 250 ms. Une raison courante de ne pas respecter cette exigence est l’exposition automatique lente et la convergence de contrôle de gain, que vous pouvez améliorer en paramétrant AEC/AGC.

Temps nécessaire pour changer de caméras

Le temps nécessaire pour changer les caméras (par exemple, de la caméra avant à la caméra arrière) doit être ≤ 750 ms. Une raison courante de ne pas respecter cette exigence est l’exposition automatique lente et la convergence de contrôle de gain, que vous pouvez améliorer en paramétrant AEC/AGC.

Glitch free/jitter

La vidéo est exempte de problèmes si elle a un temps d’inter-images maximal ≤ 133 ms à 20 lux, une durée maximale entre les images ≤ 66 ms à 80 lux et une gigue ≤ 7 ms (mesurée sur le convertisseur vidéo). La cause la plus courante de l’échec du nombre maximal de temps entre images et de gigue est de ne pas atteindre les fréquences d’images cibles. Par exemple, une caméra vidéo à 24 FPS ne répond pas aux exigences relatives au temps d’exécution maximal et à la gigue. Dans ce cas, vous devez ajuster la fréquence d’images pour cibler 15 FPS à 20 lux et 30 FPS à 80 lux.

Autres

Utilisation du processeur

Lorsque le système capture et rend des vidéos, l’utilisation du processeur doit être ≤ 5 %. Une cause courante d’échec est lorsque le processeur est utilisé pour le traitement du signal d’image. Tous les FAI critiques doivent être déchargés pour ne pas utiliser le processeur ou optimisés pour utiliser ≤ 5 %.

Solution anti-scintillement

L’imagerie dans un éclairage de 50 ou 60 Hz avec une mauvaise exposition (fréquence powerline) peut entraîner un scintillement qui dégrade considérablement la SNR. Le contrôle manuel de la fréquence de la ligne d’alimentation est requis et testé. La défaillance la plus courante ne prend pas en charge le contrôle manuel de la fréquence de la ligne d’alimentation.

Microsoft.Windows.CameraDebug TraceLogging

  • Nom :
    • Microsoft.Windows.CameraDebug
  • GUID :
    • {9EE22E19-9672-4625-A9FF-C2B711AD923F}
  • Événements :
    • DriverCriticalError
    • DriverError

Actuellement, ce fournisseur est utilisé uniquement pour enregistrer les erreurs critiques pendant les transitions de broches de caméra. Le tableau suivant récapitule la structure et le contenu des événements.

Composant ErrorCode ProcessId ThreadId OsErrorCode
(facultatif)

Explication de la fonctionnalité à l’origine de cet événement, String.
Les valeurs possibles sont les suivantes :
- Driver::Active
- Driver::P ause
- Driver::InActive

Erreur signalée par le pilote d’origine, HRESULT

ID de processus où l’erreur s’est produite

ID de thread où l’erreur s’est produite

Si l’erreur signalée par le pilote est traduite en erreur différente, HRESULT

Enregistrement et affichage d’événements

Pour obtenir des conseils supplémentaires, consultez Enregistrer et afficher les événements traceLogging.

L’exemple suivant est un fichier .wprp pour capturer les événements du fournisseur TraceLogging Microsoft.Windows.CameraDebug :

<?xml version="1.0" encoding="utf-8"?>
<WindowsPerformanceRecorder Version="1.0" Author="Microsoft Corporation" Copyright="Microsoft Corporation" Company="Microsoft Corporation">
  <Profiles>
    <EventCollector Id="EventCollector_WindowsCameraDebugTraceLoggingProvider" Name="WindowsCameraDebugTraceLoggingProvider">
      <BufferSize Value="64" />
      <Buffers Value="4" />
    </EventCollector>

    <EventProvider Id="EventProvider_WindowsCameraDebugTraceLoggingProvider" Name="9EE22E19-9672-4625-A9FF-C2B711AD923F" />

    <Profile Id="WindowsCameraDebugTraceLoggingProvider.Verbose.File" Name="WindowsCameraDebugTraceLoggingProvider" Description="WindowsCameraDebugTraceLoggingProvider" LoggingMode="File" DetailLevel="Verbose">
      <Collectors>
        <EventCollectorId Value="EventCollector_WindowsCameraDebugTraceLoggingProvider">
          <EventProviders>
            <EventProviderId Value="EventProvider_WindowsCameraDebugTraceLoggingProvider" />
          </EventProviders>
        </EventCollectorId>
      </Collectors>
    </Profile>

    <Profile Id="WindowsCameraDebugTraceLoggingProvider.Light.File" Name="WindowsCameraDebugTraceLoggingProvider" Description="WindowsCameraDebugTraceLoggingProvider" Base="WindowsCameraDebugTraceLoggingProvider.Verbose.File" LoggingMode="File" DetailLevel="Light" />
    <Profile Id="WindowsCameraDebugTraceLoggingProvider.Verbose.Memory" Name="WindowsCameraDebugTraceLoggingProvider" Description="WindowsCameraDebugTraceLoggingProvider" Base="WindowsCameraDebugTraceLoggingProvider.Verbose.File" LoggingMode="Memory" DetailLevel="Verbose" />
    <Profile Id="WindowsCameraDebugTraceLoggingProvider.Light.Memory" Name="WindowsCameraDebugTraceLoggingProvider" Description="WindowsCameraDebugTraceLoggingProvider" Base="WindowsCameraDebugTraceLoggingProvider.Verbose.File" LoggingMode="Memory" DetailLevel="Light" />

  </Profiles>
</WindowsPerformanceRecorder>

Device.Streaming Tests

Résolution des problèmes de Windows HLK