Guides et dépannage FAQ connexes

1 Contenu

2 Présentation

3 Problèmes courants

3.1 Problèmes de connexion réseau

3.1.1 Échec de la connexion

3.1.2 Erreur DNS

3.1.3 Chemin invalide

3.1.4 Non autorisé

3.1.5 Flux arrêté

3.1.6 Connexion terminée

3.1.7 Fin du flux

3.1.8 Connexion invalide

3.2 Problèmes de décodage

3.2.1 Flux non pris en charge

3.2.2 Flux invalide

3.3 Bégaiement et corruption vidéo

4 Dépannage avancé

4.1 Activation de la journalisation

4.2 Récupération des journaux

4.3 Détection de la perte de paquets et de la gigue

4.4 Problèmes de multidiffusion IGMP

5 Annexes

5.1 Types de journalisation

5.1.1 Journalisation SQX

5.1.2 Journalisation GStreamer

5.1.3 Journalisation des pipelines

5.1.4 Journalisation des paquets

2 Présentation

Ce document décrit la fonctionnalité orientée support qui a été implémentée dans la carte ActiveSXQ et le processus qui Datapath suivra, en utilisant ces fonctionnalités, pour enquêter et remédier rapidement à tout problème pouvant survenir lors du déploiement d'ActiveSQX.

Le document décrit les étapes à suivre lorsqu'une source de flux IP ne fonctionne pas avec la carte ActiveSQX. Un flux IP peut traverser un ensemble diversifié de composants matériels et logiciels et il existe un nombre tout aussi important de raisons pour lesquelles le flux peut ne pas fonctionner. Le document couvre les problèmes potentiels du plus courant au moins courant. Les problèmes courants peuvent être diagnostiqués par l'utilisateur final ou par l'assistance de première ligne sans trop de problèmes, mais certains des problèmes les moins courants devront être signalés à Datapath pour une enquête plus approfondie et les processus impliqués dans cela sont également décrits.

3 Problèmes courants

Lorsqu'une fenêtre est ouverte pour la première fois pour afficher un flux IP, « Connexion » apparaîtra dans la fenêtre. Cela indique que la carte ActiveSQX tente d'établir une connexion à la source du flux IP. Cela peut prendre entre une fraction de seconde et une demi-minute selon la qualité du réseau et de la source.

En cas de problèmes de réseau, une erreur peut s'afficher immédiatement dans la fenêtre ou le logiciel peut expirer après environ 30 secondes, puis afficher un message d'erreur dans la fenêtre.

Les différents types de problèmes de réseau sont décrits dans la section 3.1. En supposant que la connexion réseau puisse être établie correctement, divers problèmes de décodage, tels que la tentative de décodage d'un flux qui utilise un format de codage ou une fonctionnalité spécifique de ce format que ActiveSQX ne prend pas en charge, peuvent survenir. Ceux-ci sont décrits dans la section 3.2.

3.1 Problèmes de connexion réseau

S'il y a des problèmes avec le réseau, l'une des erreurs suivantes peut apparaître :

3.1.1 Échec de la connexion

Cela signifie qu'ActiveSQX n'a ​​pas pu établir de connexion avec l'adresse IP et le port source. Dans certains cas, il se peut que la source ait rejeté la connexion en raison d'un nom d'utilisateur et d'un mot de passe invalides (voir la section 3.1.4) ou que l'adresse IP source ait atteint son nombre maximum de connexions prises en charge.

3.1.1.1 Vérifier la connexion physique

Assurez-vous qu'un câble Ethernet est connecté à ActiveSQX et se trouve sur un réseau ayant un accès physique à l'adresse IP de la source.

3.1.1.2 Vérifier l'adresse IP

Si DHCP est utilisé, assurez-vous que l'ActiveSQX a obtenu une adresse IP, vérifiez-la en ouvrant le gestionnaire de périphériques et en double-cliquant sur la carte ActiveSQX sous « Contrôleurs son, vidéo et jeu ». Accédez à l'onglet « Configuration » et recherchez une adresse IP dans le champ d'adresse IP grisé, comme indiqué dans la figure 1. Si l'onglet « Configuration » n'est pas présent, ActiveSQX n'a ​​pas réussi à établir une connexion avec la machine hôte. Si tel est le cas, essayez d'éteindre et de rallumer l'appareil. Si l'onglet n'apparaît toujours pas, soit la carte est défectueuse, soit elle a été placée sur une machine hôte non prise en charge.

Figure 1 Configuration du gestionnaire de périphériques ActiveSQX

Le champ d'adresse IP ne sera mis à jour que lorsque la boîte de dialogue est ouverte pour la première fois, donc si un câble Ethernet est ensuite branché sur ActiveSQX, la boîte de dialogue doit être fermée et rouverte pour qu'elle soit actualisée. Si une adresse IP n'apparaît pas dans la boîte de dialogue, vérifiez que le serveur DHCP fonctionne correctement. Si nécessaire, utilisez un renifleur de paquets tel que Wireshark sur une autre machine connectée au même réseau pour vérifier que les paquets DHCP sont en cours de transmission. Si le serveur DHCP ne fonctionne pas correctement, essayez plutôt d'attribuer une adresse IP statique. Cependant, si une adresse IP statique est attribuée, assurez-vous de ne pas choisir une adresse dans la plage réservée à DHCP pour éviter les conflits d'adresses IP.

3.1.1.3 Ping des adresses IP

Une fois que l'ActiveSQX dispose d'une adresse IP, vérifiez qu'il répond aux requêtes ping d'une autre machine du réseau en tapant « ping xxxx » à l'aide d'une invite de commande, en remplaçant xxxx par l'adresse IP de l'ActiveSQX. Vérifiez également que la source répond aux requêtes ping adressées à son adresse IP. Si les requêtes ping réussissent, vérifiez que le numéro de port saisi pour l'adresse source est correct. Vérifiez également que le flux est accessible depuis une autre machine du même réseau à l'aide d'un logiciel de lecteur multimédia tel que VLC.

3.1.2 Erreur DNS

Si un nom de domaine, plutôt qu'une adresse IP, est saisi pour la source IP et que sa résolution n'a pas réussi, cette erreur s'affichera. Vérifiez que le nom de domaine est correct et qu'il est accessible à l'aide de la commande ping. Sinon, cela peut être dû au fait qu'ActiveSQX ne parvient pas à se connecter au serveur de noms de domaine. L'adresse de 1 ou 2 serveurs DNS peut être explicitement spécifiée via la page de propriétés ActiveSQX dans le gestionnaire de périphériques si le DNS ne peut pas être établi automatiquement via DHCP.

3.1.3 Chemin invalide

Cette erreur se produit lorsque la connexion à la source IP a été établie mais que la source a rejeté le chemin indiqué. Vérifiez le chemin dans Wall Control en ouvrant la boîte de dialogue « Configuration de la caméra IP » et en sélectionnant l'onglet « Modèles de caméra ». Sélectionnez le cameraCliquez ensuite sur « Modifier… » et vérifiez que le chemin d’accès est correct.

3.1.4 Non autorisé

Cette erreur indique que la source IP a rejeté la connexion. Cela peut être dû à un nom d'utilisateur ou un mot de passe non valide. Vérifiez le nom d'utilisateur et le mot de passe dans Wall Control en ouvrant la boîte de dialogue « Configuration de la caméra IP » et en sélectionnant l'onglet « Caméras ». Sélectionnez la caméra concernée. camera, cliquez sur « Modifier… », sélectionnez l’option « Nom d’utilisateur » et saisissez vos identifiants de connexion.

3.1.5 Flux arrêté

Cette erreur indique qu'aucune image vidéo n'a été décodée au cours de la dernière seconde. Cela peut être dû à un problème de réseau temporaire, tel qu'un câble débranché, et peut se rétablir à condition que la connexion réseau soit rétablie avant l'expiration de la connexion. Cela peut également se produire si la capacité maximale de décodage de l'ActiveSQX est dépassée, veuillez vous référer à la fiche technique pour les limites.

3.1.6 Connexion terminée

Cette erreur se produira dans les situations où la connexion est perdue pendant une période prolongée (c'est-à-dire environ 30 secondes). Cela peut être dû à plusieurs raisons différentes :

• Un câble déconnecté quelque part entre la source et l'ActiveSQX
• La source peut avoir arrêté la diffusion si elle était éteinte par exemple
• Si la source était multidiffusion, cela peut être dû à une mauvaise configuration dans les paramètres réseau IGMP sur
  les interrupteurs (voir section 4.3 pour plus de détails)

3.1.7 Fin du flux

Ce n'est pas réellement une erreur, cela indique simplement que le flux IP source est terminé. Généralement, ce message ne s'affichera que si la source était un fichier vidéo d'une durée fixe plutôt qu'un flux en direct sans fin.

3.1.8 Connexion invalide

Cette erreur indique qu'une erreur réseau générique s'est produite. Des investigations plus approfondies sont nécessaires, comme décrit dans la section 4.

3.2 Problèmes de décodage

S'il y a des problèmes lors du décodage du flux IP source, l'une des erreurs suivantes peut s'afficher :

3.2.1 Flux non pris en charge

Cette erreur indique généralement que le format de codage du flux IP source n'est pas pris en charge ou peut également indiquer un protocole de transport non pris en charge. Veuillez vous référer à la fiche technique ActiveSQX pour une liste des formats pris en charge. Dans certains cas, il peut être possible de résoudre le problème en configurant le flux IP source dans un format compatible. Si le format d'encodage de la source est inconnu, il peut être vérifié à l'aide d'un logiciel de lecteur multimédia tel que VLC.

3.2.2 Flux invalide

Cette erreur indique qu'une erreur de flux générique s'est produite. Des investigations plus approfondies sont nécessaires, comme décrit dans la section 4.

3.3 Bégaiement et corruption vidéo

Dans certains cas, un certain nombre de cadres teintés en vert peuvent être visibles lors de la première connexion, qui se corrigeront ensuite après un certain temps. Dans le cas d'une vidéo codée H264, cela est dû au fait que vous n'avez pas reçu de trame I de la source IP lors de la première connexion. La source IP doit envoyer une I-Frame lors de la connexion, mais toutes les sources IP ne le font pas. Malheureusement, ActiveSQX ne peut rien y faire.

Un autre problème courant avec les flux IP est le bégaiement vidéo et/ou les artefacts de décodage. Étant donné que le décodage des images repose souvent sur la réussite du décodage des images qui les précèdent, les flux IP sont très sensibles à toute perturbation, ce qui se manifeste souvent par une corruption vidéo.

Les artefacts de décodage sont généralement causés par la perte de paquets réseau. Pour confirmer que c'est le cas, il est préférable d'essayer de rendre le chemin depuis la source vers ActiveSQX aussi court que possible. Si un accès physique au réseau est disponible, essayez de connecter la source et l'ActiveSQX directement sur le même commutateur et déconnectez tous les autres ports inutiles pour voir si les problèmes persistent. L'interrupteur ou le câblage peut également être défectueux, essayez si possible d'utiliser plusieurs interrupteurs et câbles différents. Si cela échoue toujours, la source est peut-être défectueuse, essayez d'utiliser différentes sources IP. Si l'accès physique au réseau n'est pas disponible, essayez de mesurer la perte de paquets à l'aide des techniques de journalisation décrites dans la section 4.

Le bégaiement vidéo peut également être causé par une perte de paquets réseau, mais il est généralement également associé à des artefacts de décodage. Si le bégaiement vidéo est présent sans artefacts, cela peut être dû au fait que les paquets prennent des durées différentes pour être transmis du flux IP source à l'ActiveSQX. Par défaut, l'ActiveSQX mettra en cache les paquets pendant 200 millisecondes avant de les décoder, ce qui permettra une lecture fluide même si les paquets ne sont pas reçus à un rythme régulier, à condition que la différence de temps de transit entre le paquet le plus lent et le plus rapide ne dépasse pas 200 ms. Cette valeur est configurable dans Wall Control en ouvrant la boîte de dialogue « Configuration de la caméra IP », en sélectionnant l'option cameraCliquez sur « Modifier… », puis sur « Avancé » et modifiez la valeur de mise en cache. Augmentez-la progressivement jusqu'à ce que les saccades disparaissent. Attention : augmenter cette valeur introduira un délai entre la source en direct et la vidéo affichée. Si le problème persiste, il peut provenir de la source IP. Essayez de décoder cette même source avec un lecteur multimédia comme VLC pour vérifier si le problème se reproduit.

4 Dépannage avancé

Dans les cas où le problème ne peut pas être identifié à partir de la section 3, il sera nécessaire d'utiliser la fonctionnalité de journalisation intégrée d'ActiveSQX. Par défaut, la journalisation est désactivée pour des raisons de performances, de durabilité et de sécurité, mais elle est inestimable pour déboguer des problèmes complexes.

La journalisation doit être activée, puis le problème doit être reproduit en ouvrant le flux IP problématique (ou en effectuant toutes les étapes nécessaires). Les fichiers journaux peuvent ensuite être analysés pour déterminer la cause du problème ou renvoyés à Datapath pour une analyse plus approfondie si nécessaire.

4.1 Activation de la journalisation

La journalisation peut être activée à l'aide de l'outil de ligne de commande cmd183.exe à partir d'une invite de commande. Pour commencer, les avertissements et les erreurs de journalisation SQX avec la journalisation au niveau GStreamer INFO et le vidage du pipeline doivent être activés à l'aide de la ligne de commande suivante :

fichier setlog cmd183.exe –s 2 –g 4 –p

Ces journaux ne contiendront aucune information sensible et sont assez légers. Pour plus de détails sur les différents types de journalisation et comment utiliser l'outil cmd183, voir la section 5.1.

4.2 Récupération des journaux

Les journaux sont également récupérés à l'aide de l'outil de ligne de commande cmd183.exe. Créez d'abord un dossier sur la machine hôte dans lequel les journaux doivent être stockés. Exécutez ensuite « cmd183.exe getlogs » où est remplacé l’emplacement du dossier créé. Une fois les journaux récupérés avec succès, ils seront effacés de la ou des cartes ActiveSQX. Tous les fichiers journaux ont une date et une heure ajoutées au nom de fichier ainsi qu'un ID de sorte que chaque fenêtre client possède son propre fichier journal unique. Le contenu du dossier peut ensuite être compressé et renvoyé à Datapath pour une analyse plus approfondie. En fonction du résultat Datapath peut demander une journalisation supplémentaire avec différentes options à effectuer afin de réduire le problème.

4.3 Détection de la perte de paquets et de la gigue

Si le réseau semble souffrir de perte de paquets et/ou de gigue parce que la vidéo affiche des artefacts de décodage, activez la journalisation suivante :

fichier setlog cmd183.exe –g rtpsource:5

Ouvrez le flux IP et laissez-le fonctionner pendant environ une minute, puis récupérez les journaux à l'aide de la commande getlogs. Dans sqx-client-child_xxx.log, recherchez les lignes qui ressemblent à ceci :

rtp_source_get_new_rb : fraction 0, perdu 1, extseq 120132, gigue 98

fraction indique le nombre de paquets perdus dans la plage de 0 à 256, à convertir en pourcentage divisé par 2.56. perdu indique le nombre de paquets perdus depuis le dernier rapport. Malheureusement, même de petites pertes de paquets peuvent entraîner d'importants artefacts de décodage. Prenons par exemple une vidéo codée H264 transmise à l'aide de paquets RTP à un débit binaire de 8 Mbit/s à 30 images par seconde avec une taille GOP de 30. De nombreuses sources IP coderont des images entières dans une seule unité H264 NAL, de sorte que chaque image sera soit donc en moyenne environ 34 Ko. La taille maximale de transmission d'un paquet est généralement d'environ 1.5 Ko, une trame doit donc être divisée en environ 23 paquets RTP. En raison du fonctionnement du protocole RTP, si l'un de ces 23 paquets disparaît, tous doivent être rejetés. Ainsi, un seul paquet perdu peut en fait entraîner la suppression de 23 paquets dans cet exemple. Dès qu'une image disparaît, toutes les images suivantes souffriront d'artefacts de décodage jusqu'à l'arrivée de la prochaine image I, qui pourrait atteindre 29 images dans cet exemple. Une simple perte de paquets de 0.1 % peut entraîner la corruption de trames jusqu'à 66 % (0.1 * 23 * 29). Ainsi, afin d'obtenir une lecture vidéo fluide et sans artefacts, il est important de minimiser autant que possible la perte de paquets, idéalement de l'éliminer complètement.

gigue est la variation du retard des paquets reçus dans le flux en unités de fréquence d'horloge. Elle est mesurée en comparant l'intervalle d'envoi des paquets RTP à l'intervalle auquel ils ont été reçus. Par exemple, si le paquet n°1 et le paquet n°2 sont espacés de 50 millisecondes et arrivent à 60 millisecondes d'intervalle, alors la gigue est de 10 millisecondes. Plus la valeur de gigue est faible, plus les valeurs de gigue élevées indiquent que les paquets n'arrivent pas à intervalles réguliers et qu'une mise en cache plus importante est nécessaire pour obtenir une lecture fluide. La gigue est généralement moins problématique que la perte de paquets car elle peut être compensée par ActiveSQX en augmentant la mise en cache.

4.4 Problèmes de multidiffusion IGMP

Si un flux IP de multidiffusion s'interrompt après un certain temps, de quelques minutes à quelques heures, voire plusieurs jours, cela peut être dû à un problème de configuration avec les commutateurs utilisés pour transmettre les paquets de multidiffusion. Si tel est le cas, une erreur « Connexion terminée » apparaîtra dans la fenêtre, nous pouvons vérifier que les paquets RTP ne sont plus reçus en activant la journalisation suivante :

fichier setlog cmd183.exe –s 2 –g rtpsource:5 –n igmp

Ouvrez le flux IP et laissez-le fonctionner jusqu'à ce que le flux s'arrête, puis récupérez les journaux à l'aide de la commande getlogs. Dans sqx-client-child_xxx.log, recherchez les lignes « Aucune trame transférée pendant plus d'une seconde » et « Traiter la fin du flux comme un délai d'attente », entre celles-ci, le nombre de paquets RTP reçus peut être vu. Si ce nombre n'a pas augmenté entre la dernière trame décodée et le délai d'attente, cela signifie qu'aucun nouveau paquet RTP n'arrive et pourrait indiquer qu'un commutateur filtre les paquets.

En supposant que les paquets se soient arrêtés, nous pouvons examiner les paquets IGMP pour voir s'ils se comportent comme prévu. Ouvrez sqx-client_xxx.pcap avec Wireshark et recherchez les paquets « Membership Query, general » provenant du commutateur. Assurez-vous que chaque requête reçoit une réponse par un « rapport d'adhésion » dans le délai de réponse maximum indiqué par le paquet de requête pour l'adresse de multidiffusion connectée. Si un autre périphérique répond avec un rapport avant l'ActiveSQX, celui-ci n'enverra pas non plus de réponse (cela fait partie de la norme du protocole IGMP). Dans certains cas, ActiveSQX peut recevoir un rapport d'un autre périphérique indiquant qu'il ne devrait pas, cela indique un problème avec la configuration réseau.

5 Annexes

5.1 Types de journalisation

Les fichiers journaux peuvent être stockés sur ActiveSQX ou envoyés en direct à la machine hôte au fur et à mesure qu'ils sont générés et visualisés à l'aide de DebugView ou d'un débogueur de noyau. L'écriture dans des fichiers sur ActiveSQX a tendance à être plus rapide et n'interfère pas autant avec le processus de décodage, mais ActiveSQX dispose d'un espace limité pour la journalisation (environ 1.4 Go). À l'inverse, l'affichage des journaux dans DebugView n'est pas limité par l'espace disque d'ActiveSQX mais peut avoir un impact important sur les performances si une journalisation très détaillée est activée.

Il existe différents types de journalisation qui peuvent être activés :

• SQX : enregistrer les messages provenant de Datapathle code propriétaire de.
• GStreamer : journalise les messages provenant du code open source GStreamer.
• Pipeline GStreamer : représentation graphique du pipeline GStreamer.
• Capture de paquets réseau : captures de paquets réseau bruts qui peuvent être visualisées dans Wireshark.

En fonction de la nature du problème, n'importe quel nombre de ces journaux peut être activé à la fois, en gardant à l'esprit les limitations d'espace disque et l'impact sur les performances. La meilleure approche consiste à commencer avec un niveau de journalisation assez léger et à y rechercher les erreurs et les avertissements. Ensuite, à mesure que la source du problème devient plus apparente, des niveaux de journalisation plus élevés peuvent être activés.

5.1.1 Journalisation SQX

La journalisation SQX se décline en 4 niveaux : 0 à 3. 0 représente aucune journalisation, 1 correspond uniquement aux erreurs, 2 correspond aux erreurs et aux avertissements et 3 correspond à toute la journalisation. Le niveau de journalisation 2 est un bon niveau pour commencer car il ne doit pas remplir le disque trop rapidement. Exemple : fichier setlog cmd183.exe –s 2

5.1.2 Journalisation GStreamer

La journalisation GStreamer est plus compliquée, elle comprend 10 niveaux de journalisation 0 à 9. En plus du niveau de journalisation, GStreamer dispose d'un certain nombre de catégories de débogage différentes pour différents composants de l'architecture GStreamer. Il est possible par exemple d'activer le niveau de débogage 9 spécifiquement pour la catégorie rtpsource tout en laissant toutes les autres catégories désactivées. Pour plus d'informations, reportez-vous à la variable GST_DEBUG sous http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html. Le niveau 4 dans toutes les catégories est généralement un bon point de départ car il établit un équilibre entre fournir suffisamment d'informations et ne pas remplir l'espace disque trop rapidement. Exemple : fichier setlog cmd183.exe –g 4 ou fichier setlog cmd183.exe –g rtpsource:5

5.1.3 Journalisation des pipelines

GStreamer a également la capacité de générer le pipeline dans un fichier .dot qui, une fois traité par graphviz, donne une représentation graphique du pipeline qui donne une bonne indication des formats d'encodage et des protocoles de transport utilisés par une source IP donnée. Exemple : cmd183.exe fichier setlog -p

5.1.4 Journalisation des paquets

Si le problème ne peut pas être diagnostiqué uniquement à l'aide des fichiers journaux, il peut être nécessaire de capturer les paquets réseau bruts et de les analyser dans Wireshark. Pour les problèmes intermittents, cela peut également constituer un moyen pratique de reproduire des problèmes rarement rencontrés. Cependant, il convient de noter que si tous les paquets sont capturés, l'espace disque peut être rempli très rapidement. Pour aider à atténuer ce problème et fournir un niveau de confidentialité aux clients, il est possible de filtrer les paquets capturés en fonction de critères donnés. Tcpdump est utilisé pour la capture de paquets et la syntaxe du filtre est décrite en détail ici http://www.tcpdump.org/manpages/pcap-filter.7.html. Exemple : fichier setlog cmd183.exe –n « src 10.20.0.1 » ou fichier setlog cmd183.exe –n « » pour aucun filtrage.

Le mode promiscuité est désactivé pour éviter de capturer le trafic réseau général non destiné à ActiveSQX. Cependant, comme la capture de paquets fonctionne à un faible niveau, elle peut capturer des informations potentiellement sensibles en fonction des informations envoyées sur le réseau si elles ne sont pas explicitement filtrées. Il est également possible de relire la vidéo à partir des captures de paquets et les clients doivent en être informés avant de leur demander de renvoyer les captures de paquets à Datapath. Pour ces raisons, la capture de paquets doit généralement être utilisée en dernier recours pour les problèmes de débogage.