Publier : Diagnostics
Ce guide explique comment obtenir des diagnostics pour les éditeurs et résoudre les problèmes les plus courants.
Obtenir des statistiques sur le flux d'un éditeur
Le SDK Video de Vonage expose des mesures détaillées de la qualité du flux par le biais d'une API de statistiques de haut niveau - recommandée pour la plupart des cas d'utilisation - qui fournit des statistiques audio, vidéo, réseau et côté expéditeur sous une forme unifiée et consciente de la session, qui reste stable lors des transitions de connexion entre pairs. Pour le débogage avancé, le SDK permet également d'accéder au rapport de statistiques WebRTC brut, qui reflète les données de connexion entre pairs non traitées.
Se référer à le guide du développeur de l'observabilité du client pour obtenir des informations détaillées.
Flux d'essai
Vous pouvez publier un flux de test et vérifier ses statistiques audio et vidéo afin de déterminer le type de flux (haute résolution ou audio uniquement) pris en charge par votre connexion.
Pour obtenir des statistiques sur un flux publié par le client local, vous devez utiliser une session qui utilise le routeur de médias (sessions dont le mode média est défini sur routé) et vous devez définir l'attribut testNetwork à la propriété true dans le options que vous passez dans l'objet Session.subscribe() méthode. Vous pouvez alors utiliser la méthode getStats() de l'objet Subscriber pour obtenir des statistiques audio et vidéo pour le flux que vous publiez.
Vous pouvez utiliser le SubscriberKit.setAudioStatsListener(AudioStatsListener listener) et SubscriberKit.setVideoStatsListener(VideoStatsListener listener) de l'objet Subscriber pour obtenir des statistiques audio et vidéo pour le flux que vous publiez.
Voir ce sujet pour plus d'informations.
Vous pouvez utiliser le networkStatsDelegate de l'objet OTSubscriberKit pour obtenir des statistiques audio et vidéo pour le flux que vous publiez.
Les vonage-video-api-network-test-samples comprend un exemple de code montrant comment utiliser les statistiques d'un flux de test avant de le publier dans une session.
Vous pouvez utiliser le networkStatsDelegate de l'objet OTSubscriberKit pour obtenir des statistiques audio et vidéo pour le flux que vous publiez.
Les vonage-video-api-network-test-samples comprend un exemple de code montrant comment utiliser les statistiques d'un flux de test avant de le publier dans une session.
Vous pouvez ensuite vous abonner au flux et utiliser la fonction Subscriber.AudioStatsUpdated et Subscriber.VideoStatsUpdated pour obtenir des statistiques audio et vidéo pour le flux que vous publiez.
Bonnes pratiques de publication
Cette section contient des conseils pour publier des flux avec succès.
Autoriser l'accès aux appareils
La meilleure pratique consiste à informer vos utilisateurs qu'ils devront autoriser l'accès à leur caméra et à leur microphone.
Nous constatons que le plus grand nombre d'échecs de publication est dû au fait que les utilisateurs ont cliqué sur le bouton "refuser" ou n'ont pas du tout cliqué sur le bouton "autoriser". Nous vous fournissons tous les événements dont vous avez besoin pour guider vos utilisateurs tout au long de ce processus :
publisher.on({
accessDialogOpened: function (event) {
// Show allow camera message
pleaseAllowCamera.style.display = 'block';
},
accessDialogClosed: function (event) {
// Hide allow camera message
pleaseAllowCamera.style.display = 'none';
}
});
C'est également une bonne idée d'utiliser le protocole SSL pour votre site web. En effet, Chrome ne demande aux utilisateurs de cliquer sur l'autorisation d'accès aux appareils qu'une seule fois par domaine si ce dernier est desservi par SSL. Cela signifie que vos utilisateurs (s'ils utilisent Chrome) n'ont pas à faire face à cette boîte de dialogue d'autorisation ou de refus à chaque fois qu'ils chargent la page.
Séparer OT.initPublisher() et Session.publish()
Nous recommandons également de diviser le OT.initPublisher() et Session.publish() étapes. Cela accélère le temps de connexion initial car vous vous connectez à la session en attendant que l'utilisateur clique sur le bouton d'autorisation. Ainsi, au lieu de :
session.connect(token, function (err) {
{... your error handling code ...}
if (!err) {
var publisher = OT.initPublisher();
session.publish(publisher);
}
});
Déplacer le OT.initPublisher() avant de vous connecter, comme dans l'exemple suivant :
var publisher = OT.initPublisher();
session.connect(token, function (err) {
{... your error handling code ...}
if (!err) {
session.publish(publisher);
}
});
Résolution et fréquence d'images
Vous pouvez définir la résolution et la fréquence d'images de l'éditeur lorsque vous l'initialisez :
OT.initPublisher(divId, {
resolution: '320x240',
frameRate: 15
});
Par défaut, la résolution d'un éditeur est de 640x480, mais vous pouvez également la régler sur 1920x1080, 1280x720 ou 320x240. Il est préférable d'essayer de faire correspondre la résolution à la taille d'affichage de la vidéo. Si vous n'affichez la vidéo qu'à 320x240 pixels, il est inutile de la diffuser à 1280x720 ou 1920x1080. La réduction de la résolution permet d'économiser de la bande passante et de réduire les encombrements et les interruptions de connexion.
Par défaut, la fréquence d'images de la vidéo est de 30 images par seconde, mais vous pouvez également la régler sur 15, 7 ou 1. La réduction de la fréquence d'images permet de réduire la bande passante requise. Les vidéos à faible résolution peuvent avoir une fréquence d'images plus faible sans que l'utilisateur perçoive une différence notable. Par conséquent, si vous utilisez une faible résolution, vous pouvez également envisager d'utiliser une faible fréquence d'images.
Dépannage
Suivez les conseils de cette section pour éviter les problèmes de connectivité lors de la publication. Pour des informations générales sur le dépannage, voir Débogage - Web.
Traitement des erreurs
Il existe des méthodes de rappel pour les deux Session.publish() et OT.initPublisher(). Nous recommandons de gérer les réponses d'erreur à ces deux méthodes. Comme nous l'avons déjà mentionné, il est préférable de séparer ces étapes et d'appeler OT.initPublisher() avant d'avoir commencé à vous connecter à votre session. Il est également plus facile de gérer les erreurs si vous n'appelez pas ces deux méthodes en même temps. En effet, les deux gestionnaires d'erreurs se déclenchent en cas de publication d'une erreur. Il est préférable d'attendre que OT.initPublisher() à compléter et Session.connect() et appeler ensuite Session.publish(). De cette façon, vous pouvez traiter tous les problèmes liés au matériel dans l'espace de travail. OT.initPublisher() et tous les problèmes liés au réseau dans le Session.publish() rappel.
var connected = false,
publisherInitialized = false;
var publisher = OT.initPublisher(function(err) {
if (err) {
// handle error
} else {
publisherInitialized = true;
publish();
}
});
var publish = function() {
if (connected && publisherInitialized) {
session.publish(publisher);
}
};
session.connect(token, function(err) {
if (err) {
// handle error
} else {
connected = true;
publish();
}
});
Accès refusé
Le plus grand nombre d'échecs de OT.initPublisher() sont dues au fait que l'utilisateur final refuse l'accès à la caméra et au microphone. Il est possible d'y remédier en écoutant le message accessDenied ou en écoutant une réponse d'erreur à la méthode OT.initPublisher() avec une valeur de code fixée à 1500 et un message avec la valeur "Publisher Access Denied :". Nous vous recommandons de traiter ce cas et d'envoyer un message à l'utilisateur pour lui indiquer qu'il doit réessayer de publier et autoriser l'accès à la caméra.
publisher.on({
'accessDenied': function() {
showMessage('Please allow access to the Camera and Microphone and try publishing again.');
}
});
Accès au dispositif
Une autre raison pour OT.initPublisher() L'échec d'OpenTok est dû au fait qu'il ne peut pas accéder à une caméra ou à un microphone. Cela peut se produire s'il n'y a pas de caméra ou de microphone attaché à la machine, s'il y a un problème avec le pilote de la caméra ou du microphone, ou si une autre application utilise la caméra ou le microphone (cela ne se produit que sous Windows). Vous pouvez essayer de minimiser l'occurrence de ces problèmes en utilisant notre composant de configuration du matériel ou en appelant la fonction OT.getDevices() directement. Cependant, vous devez également gérer toute erreur lors de l'appel de la méthode OT.initPublisher() car un problème peut toujours survenir. Par exemple, l'utilisateur peut avoir refusé l'accès à la caméra ou au microphone. Dans ce cas, le error.name est fixée à "OT_USER_MEDIA_ACCESS_DENIED":
publisher = OT.initPublisher('publisher', {}, function (err) {
if (err) {
if (err.name === 'OT_USER_MEDIA_ACCESS_DENIED') {
// Access denied can also be handled by the accessDenied event
showMessage('Please allow access to the Camera and Microphone and try publishing again.');
} else {
showMessage('Failed to get access to your camera or microphone. Please check that your webcam'
+ ' is connected and not being used by another application and try again.');
}
publisher.destroy();
publisher = null;
}
});
Erreurs de réseau
Les autres raisons des échecs de publication sont généralement dues à une défaillance du réseau. Nous les gérons dans le rappel à Session.publish(). Si l'utilisateur n'est pas connecté au réseau, la fonction de rappel reçoit un objet d'erreur avec la valeur name est définie comme étant la propriété "OT_NOT_CONNECTED". Si l'utilisateur dispose d'une connexion réseau très restrictive qui n'autorise pas les connexions WebRTC, l'éditeur ne parvient pas à se connecter et l'élément Publisher affiche une roue qui tourne. Cette erreur a une name est définie comme étant la propriété "OT_CREATE_PEER_CONNECTION_FAILED". Dans ce cas, nous vous recommandons d'envoyer un message à l'utilisateur pour lui indiquer qu'il n'a pas réussi à publier et qu'il doit vérifier sa connexion réseau. La gestion de ces erreurs se fait de la manière suivante :
session.publish(publisher, function(err) {
if (err) {
switch (err.name) {
case "OT_NOT_CONNECTED":
showMessage("Publishing your video failed. You are not connected to the internet.");
break;
case "OT_CREATE_PEER_CONNECTION_FAILED":
showMessage("Publishing your video failed. This could be due to a restrictive firewall.");
break;
default:
showMessage("An unknown error occurred while trying to publish your video. Please try again later.");
}
publisher.destroy();
publisher = null;
}
});
Perte de connectivité
Votre éditeur peut également perdre sa connexion après avoir réussi à se connecter. Le plus souvent, la Session perd également sa connexion, mais ce n'est pas toujours le cas. Vous pouvez gérer la déconnexion de l'éditeur en écoutant la commande streamDestroyed avec un reason à "networkDisconnected" comme suit :
publisher.on({
streamDestroyed: function (event) {
if (event.reason === 'networkDisconnected') {
showMessage('Your publisher lost its connection. Please check your internet connection and try publishing again.');
}
}
});