Vidéo évolutive

La vidéo adaptative est une fonctionnalité destinée aux sessions acheminées qui améliore la qualité vidéo lors des sessions multipartites en permettant à chaque abonné de bénéficier d'une qualité vidéo adaptée à ses conditions réseau du moment, indépendamment des autres abonnés.

Sans la fonctionnalité « Scalable Video », le routeur multimédia OpenTok transmet la même qualité vidéo à tous les abonnés d'un flux. Lorsque la connexion d'un abonné se détériore, le routeur utilise une estimation de la bande passante pour demander à l'éditeur de réduire son débit binaire, ce qui diminue la qualité pour tous les abonnés de ce flux. Lorsque la vidéo évolutive est activée, le routeur sélectionne en temps réel et de manière indépendante la couche de qualité la plus appropriée pour chaque abonné, sans affecter ce que reçoivent les autres abonnés.

La vidéo évolutive nécessite une session acheminée (une session utilisant le routeur multimédia OpenTok). Cette fonctionnalité n'est pas disponible dans les sessions relayées et n'y serait d'ailleurs d'aucune utilité, puisque les flux circulent directement entre les clients sans passer par un routeur capable de sélectionner ou de basculer entre les niveaux de qualité. Voir Le routeur multimédia OpenTok et les modes multimédias.

La vidéo adaptative est activée par défaut. Le paramètre au niveau du projet est défini par défaut sur Auto, ce qui signifie que le routeur multimédia OpenTok active automatiquement la vidéo évolutive lorsqu'une session compte plus de deux clients et que toutes les autres conditions sont remplies. Vous pouvez également le configurer pour Sur (toujours active) ou Arrêt. Pour la plupart des applications, aucune modification du code n'est nécessaire.

Codecs et modèles d'évolutivité

Le fonctionnement de la vidéo évolutive dépend du codec négocié par l'éditeur. Comprendre les différences vous permet de choisir le codec adapté à votre cas d'utilisation, par exemple lorsque vous devez optimiser l'utilisation de l'unité centrale de l'éditeur, la bande passante en amont ou l'adaptation de la qualité du côté de l'abonné.

VP8 : Simulcast

Avec VP8La vidéo évolutive est mise en œuvre grâce à diffusion simultanée. L'éditeur encode et transmet plusieurs flux binaires distincts, chacun avec une résolution et une fréquence d'images différentes. Par exemple : 1080p, 540p et 270p, chacun disposant de ses propres couches temporelles (fréquence d'images). Chaque flux est autonome et peut être décodé séparément.

Chaque flux étant indépendant, le routeur multimédia OpenTok peut basculer n'importe quel abonné vers un autre niveau de qualité sans recodage. Cela garantit une grande résilience face aux variations des conditions réseau.

VP9 : codage vidéo évolutif (SVC)

Avec VP9Utilisation de la vidéo évolutive Codage vidéo évolutif (SVC). L'éditeur encode un flux binaire unique dans lequel sont intégrées plusieurs couches spatiales (résolution) et temporelles (fréquence d'images). Chaque couche supérieure dépend des couches inférieures ; ainsi, un décodeur ne recevant que la couche de base obtient une qualité médiocre, tandis que celui qui reçoit toutes les couches bénéficie d'une qualité optimale, le tout à partir du même flux binaire.

Le coût en ressources CPU pour l'encodage SVC est plus élevé que pour l'encodage d'un flux unique ; il est à peu près comparable à celui du simulcast VP8, mais le SVC nécessite moins de bande passante en amont, car il n'y a qu'un seul flux binaire à télécharger au lieu de plusieurs flux indépendants. À partir de ce flux unique encodé, le routeur multimédia OpenTok peut extraire et transmettre le sous-ensemble de couches adapté à chaque abonné, offrant ainsi une adaptation de la qualité à la fois efficace et flexible, qui est également plus résistante à la perte de paquets.

Le SVC nécessite que le point de terminaison de l'éditeur et le routeur multimédia OpenTok prennent tous deux en charge le VP9 SVC. Firefox supporte VP9 mais pas SVC. Un éditeur Firefox transmet du contenu au format VP9 sans couches, ce qui empêche le routeur multimédia OpenTok d'adapter la qualité de ce flux.

Pour une explication complète des couches SVC, des modes d'extensibilité (L1T3, L2T3, L3T3), le comportement en matière d'archivage et la prise en charge des appareils, voir Codage vidéo évolutif VP9 pour les sessions acheminées.

La différence clé en un coup d'œil

H.264 : Vidéo évolutive non prise en charge

Le codec H.264 est entièrement pris en charge dans la Video API de Vonage pour la publication et l'abonnement, mais la vidéo évolutive n'est pas disponible pour les flux H.264. Le routeur multimédia OpenTok ne permet pas de changer de niveau de qualité pour les flux H.264, et les paramètres de vidéo évolutive n'ont aucun effet lorsque le format H.264 est négocié. Si votre application nécessite la vidéo évolutive, utilisez plutôt VP8 ou VP9. Voir Codecs vidéo.

Support vidéo évolutif

La vidéo évolutive est prise en charge pour la diffusion simultanée VP8 et le SVC VP9. Elle n'est pas prise en charge pour Flux H.264. Il n'est disponible qu'en sessions acheminées.

Les clients suivants prennent en charge la vidéo évolutive :

• SDK Web - Chrome, Firefox, Safari, Samsung Internet, WebView sur Android, WebView sur iOS et Edge (basé sur Chromium). Remarque : Firefox prend en charge la diffusion simultanée VP8, mais pas le VP9 SVC.
• SDK Android sur les appareils pris en charge
• SDK iOS sur les appareils pris en charge
• SDK Windows
• SDK Linux
• SDK macOS
• SDK React Native sur les appareils pris en charge

Pour plus de détails sur la compatibilité des appareils et des navigateurs avec le VP9 SVC, voir Codage vidéo évolutif VP9 pour les sessions acheminées.

Comment utiliser la vidéo évolutive

Paramètres au niveau du projet

La vidéo adaptative propose trois modes que vous pouvez configurer pour un projet dans votre Video API Account:

1. Accédez à votre Video API Account et sélectionnez le projet dans la liste des projets dans le menu de gauche.
2. Sous Paramètres du projet, trouver Vidéo évolutive puis sélectionnez les paramètres du projet :
   • Auto (recommandé) - Le routeur multimédia OpenTok permet une diffusion vidéo évolutive lorsqu'une session compte plus de deux clients. Laissez cette option sélectionnée, sauf si vous avez une raison particulière de la désactiver.
   • Sur - La vidéo adaptative est toujours activée (dans les clients compatibles) pour toutes les sessions de ce projet.
   • Arrêt - La vidéo adaptative est désactivée pour toutes les sessions de ce projet. Utilisez cette option pour verrouiller la résolution et la fréquence d'images, ou pour réduire la charge sur le processeur et la consommation de bande passante de l'éditeur.
3. Cliquez sur Économiser.

Flux de partage d'écran évolutifs

Par défaut, la vidéo évolutive est handicapé pour les flux de partage d'écran et activée pour les flux provenant d'une caméra et d'une source vidéo personnalisée. Le contenu partagé via le partage d'écran change généralement moins souvent que la vidéo provenant d'une caméra ; le surcoût d'encodage lié à la vidéo évolutive est donc souvent inutile. Cependant, l'activer peut s'avérer utile lors de sessions où les participants au partage d'écran sont soumis à des conditions réseau variables. Vous pouvez remplacer la valeur par défaut pour chaque éditeur :

Comment l'indication de contenu affecte les calques de partage d'écran

Lorsque la vidéo adaptative est activée pour un flux de partage d'écran au format VP8 dans une session acheminée, le Astuce concernant le contenu vidéo Le paramètre que vous définissez pour l'éditeur détermine la manière dont celui-ci structure les couches de diffusion simultanée qu'il envoie. C'est pourquoi le nombre de flux (SSRC) que vous observez pour un éditeur de partage d'écran dans un outil tel que chrome://webrtc-internals Cela dépend de l'indication de contenu :

• detail ou text — L'éditeur optimise l'affichage afin de préserver les détails fins et la lisibilité (texte, dessins au trait, contenu statique). Il envoie deux flux ayant la même résolution spatiale et ne différant que par leur fréquence d'images: un flux en pleine résolution à la fréquence d'images normale, et un deuxième flux en pleine résolution à une fréquence d'images inférieure. Cela permet de conserver la netteté et la lisibilité du contenu partagé, tout en offrant au routeur multimédia OpenTok une couche à débit binaire réduit sur laquelle se rabattre en cas de dégradation du réseau d’un abonné — ainsi, la dégradation réduit la fréquence d’images plutôt que de rendre les détails flous. Ces deux couches en pleine résolution offrent un bon équilibre entre la résilience en cas de dégradation et le maintien de la résolution détaillée d’origine.

• motion — Le lecteur optimise la fluidité des mouvements (par exemple, lors de la lecture d'une vidéo partagée). Il fonctionne comme une diffusion simultanée par caméra, en envoyant plusieurs flux à différentes résolutions spatiales, ce qui permet au routeur multimédia OpenTok de faire passer un abonné à une résolution inférieure afin de garantir la fluidité des mouvements lorsque les conditions réseau sont limitées.

Choisissez l'indication de contenu qui correspond à votre contenu partagé : detail ou text privilégie la netteté des détails (en réduisant d'abord la fréquence d'images), tandis que motion privilégie la fluidité des mouvements (en réduisant d'abord la résolution).

Réglage de la fréquence d'images et de la résolution préférées de l'abonné

Lorsqu'un flux est diffusé avec la technologie « Scalable Video », les abonnés peuvent indiquer leur qualité préférée au routeur multimédia OpenTok. Le routeur multimédia OpenTok sélectionne alors la couche disponible la plus proche qui correspond aux conditions réseau réelles de l'abonné.

Comment vérifier que la vidéo évolutive fonctionne ?

Il n'y a pas d'indicateur unique "vidéo évolutive active" dans le SDK, mais vous pouvez confirmer qu'il fonctionne à l'aide des approches suivantes.

Inspecteur vidéo

Les Inspecteur vidéo L'outil du module « Indicateurs de qualité » affiche le codec, la résolution et la fréquence d'images. Passez la souris sur n'importe quel point d'une ligne tracée pour afficher le codec actuellement utilisé. Lorsque la vidéo adaptative est activée, la résolution et/ou la fréquence d'images d'un ou plusieurs abonnés peuvent s'ajuster dynamiquement en fonction de l'évolution des conditions du réseau.

Statistiques WebRTC

Chaque SDK expose le rapport de statistiques WebRTC sous-jacent. Du côté de l'éditeur, inspectez RTCOutboundRtpStreamStats:

• Avec Diffusion simultanée VP8, vous verrez de multiples ssrc avec des entrées différentes frameWidth et frameHeight valeurs, une par couche de diffusion simultanée.
• Avec VP9 SVC, vous verrez un seul ssrc avec un scalabilityMode ensemble de propriétés, par exemple L3T3.

Méthodes SDK pour accéder au rapport de statistiques :

• SDK Web - Publisher.getRtcStatsReport() et Subscriber.getRtcStatsReport()
• Linux - voir Obtenir des statistiques sur les flux

Liste de contrôle : Conditions requises pour que la vidéo évolutive soit active

Si vous n'observez pas de comportement adaptatif en matière de qualité, vérifiez les points suivants :

• La session est acheminé, non retransmis.
• La vidéo évolutive n'est pas réglée sur Arrêt au niveau du projet.
• Le codec négocié est VP8 ou VP9, et non H.264.
• L'éditeur fonctionne sur un client pris en charge.

Configuration du mode d'évolutivité cible

Vous pouvez définir explicitement le mode d'évolutivité d'un éditeur, afin de contrôler le nombre de niveaux spatiaux (résolution) et temporels (fréquence d'images) encodés par WebRTC. Cela vous permet de gérer avec précision le compromis entre l'adaptabilité de la qualité vidéo et l'utilisation des ressources.

Comment cela fonctionne-t-il ?

Le mode d'évolutivité cible s'applique au chemin multimédia du routeur multimédia (éditeur → routeur multimédia). Il peut être défini ou modifié à tout moment : il n'est pas nécessaire que la négociation du chemin multimédia soit terminée, et vous pouvez le mettre à jour à la volée pendant une session active, alors que l'encodeur est déjà en cours d'exécution. Si vous appelez la méthode `set` avant que le chemin multimédia ne soit établi, le SDK conserve la valeur et l'applique une fois la négociation du codec terminée. Dans Routage adaptatif des médias Dans les sessions (AMR), ce mode ne s'applique qu'au chemin multimédia passant par le routeur multimédia (éditeur → routeur multimédia), car les modes d'évolutivité ne sont pas utilisés lorsque le routeur multimédia est contourné dans le chemin multimédia.

Ce que contrôle la cible

Le mode d'évolutivité cible indique à l'encodeur le nombre de couches spatiales (résolution) et temporelles (fréquence d'images) à générer. Cela détermine directement les options de qualité dont dispose le Media Router lors de la transmission de la vidéo à chaque abonné :

• Autres couches spatiales — Le Media Router peut réduire la résolution pour les abonnés disposant d’une bande passante limitée tout en conservant la pleine résolution pour les autres. Par exemple, L3T3 propose trois niveaux de résolution parmi lesquels le routeur peut choisir.
• D'autres couches temporelles — Le Media Router peut réduire la fréquence d'images pour les abonnés dont la connexion est limitée, sans pour autant diminuer la résolution. Par exemple, L1T3 conserve en permanence la pleine résolution, mais offre au routeur trois niveaux de fréquence d'images parmi lesquels choisir — cette option est particulièrement adaptée aux contenus où le niveau de détail est essentiel, comme les diapositives ou les documents.
• Moins de couches — réduit la consommation de CPU et de bande passante de l'éditeur, mais limite la capacité du Media Router à adapter la qualité en fonction de chaque abonné.

Lorsque la cible risque de ne pas être entièrement appliquée

La cible correspond à une préférence : l'encodeur l'applique lorsque les conditions le permettent. Le mode effectivement appliqué peut différer de votre cible dans les cas suivants :

• Limites des codecs — Si le codec négocié ne prend pas en charge les couches demandées, le mode est adapté. Par exemple, en définissant L2T3 avec VP8, on obtient L1T3 est appliquée car le format VP8 ne prend pas en charge l'évolutivité spatiale. Voir Solution de repli en fonction du codec.
• Résolution trop faible pour les couches spatiales demandées — Chaque étape de la couche spatiale utilise un rapport de résolution de 2:1. Si la résolution de capture de l'éditeur est trop faible pour permettre une subdivision significative (par exemple, une publication en 320×240 avec L3T3 (si demandé), l'encodeur peut générer moins de couches spatiales que demandé, car la couche la plus basse serait trop petite pour être utile.
• Contraintes matérielles ou liées aux ressources — Sur les appareils aux ressources limitées, l'encodeur peut ne pas générer toutes les couches demandées si cela entraîne un dépassement des limites allouées au processeur ou à la bande passante.

Vérification du mode sélectionné

La méthode get renvoie votre cible (ce que vous avez défini), et pas forcément ce qui a été appliqué. Pour vérifier les couches d'évolutivité réellement générées par l'encodeur, utilisez le rapport de statistiques WebRTC — plus précisément la section RTCOutboundRtpStreamStats — via getRtcStatsReport(). Pour plus d'informations sur l'accès aux statistiques sur les différentes plateformes, consultez Comment vérifier que la vidéo évolutive fonctionne ? et Observabilité du client.

Modes d'évolutivité valides

Les modes suivants sont pris en charge :

Le format suit les Spécification SVC du W3C WebRTC: L<spatial>T<temporal>, où le nombre qui suit L correspond au nombre de couches spatiales et le nombre qui suit T correspond au nombre de couches temporelles.

Toute valeur ne figurant pas dans cette liste est rejetée et génère une erreur. Si vous n'avez jamais appelé la méthode `set` (par exemple, setTargetScalabilityMode() sur le Web/Android ou sur l'application targetScalabilityMode propriété sous iOS/Windows), la méthode get correspondante renvoie une valeur vide ou nulle (selon la plateforme) — cela s'explique par le fait que le mode d'évolutivité est un cible Il s'agit uniquement d'une préférence, et non d'une valeur par défaut gérée en interne. Le SDK ne définit pas de cible par défaut à votre place ; par conséquent, tant que vous n'en avez pas défini une explicitement, aucune valeur ne peut être renvoyée.

Solution de repli en fonction du codec

Le mode qui est en fait appliqué Cela dépend du codec négocié sur le chemin multimédia du routeur multimédia :

• Codecs prenant en charge la technologie SVC (VP9) — le mode demandé est appliqué tel quel. Ces codecs prennent en charge nativement les couches d'évolutivité tant spatiales que temporelles.
• VP8 — Le format VP8 ne prend en charge que l'évolutivité temporelle, sans couches spatiales ; les caractéristiques spatiales sont gérées par la publication de plusieurs flux à différentes résolutions (diffusion simultanée). Le mode le plus proche est obtenu en conservant la dimension temporelle et en fixant les couches spatiales à 1. Par exemple, si vous définissez L2T2 et si le VP8 est négocié, L1T2 est appliquée.
• H.264 — La vidéo adaptative n'est pas prise en charge pour le format H.264 dans cette API ; par conséquent, le comportement de repli décrit ci-dessus ne s'applique pas aux flux H.264.

La méthode `get` renvoie toujours la valeur que vous avez explicitement définie (votre intention), quelle que soit la valeur effectivement appliquée après le recours à une solution de secours dépendante du codec. Par exemple, si vous définissez L2T3 et si le profil VP8 est négocié, le routeur multimédia applique L1T3 (puisque VP8 ne comporte pas de couches spatiales), mais la méthode get renvoie tout de même L2T3 — en fonction de votre cible initiale, et non du mode effectif.

Interaction avec la résolution et la fréquence d'images préférées de l'abonné

La logique de sélection de couche du routeur multimédia pour Subscriber.setPreferredResolution() et Subscriber.setPreferredFrameRate() est conçu autour de la structure par défaut des couches d'évolutivité. Lorsqu'un éditeur définit un mode d'évolutivité cible différent de celui par défaut, les couches spatiales et/ou temporelles effectivement générées par l'encodeur ne correspondent plus à ce que le Media Router considère comme disponible, et la couche que le routeur transmet à un abonné peut ne pas correspondre à la résolution ou à la fréquence d'images demandée par cet abonné.

Utilisation des API spécifiques à chaque plateforme

Android

Les PublisherKit La classe comprend setTargetScalabilityMode() et getTargetScalabilityMode() des méthodes.

Configuration du mode d'évolutivité cible

Appeler setTargetScalabilityMode() sur une instance PublisherKit pour définir le mode d'évolutivité cible :

publisher.setTargetScalabilityMode("L3T3");

Cette méthode peut être appelée à tout moment ; il n'est pas nécessaire que la négociation du chemin multimédia soit terminée. Le mode sera appliqué dès que le chemin multimédia du Media Router sera établi.

La méthode lève une OpenTokException si le mode demandé n'est pas valide (c'est-à-dire s'il ne fait pas partie de L1T1, L1T2, L1T3, L2T1, L2T2, L2T3, L3T1, L3T2, L3T3) :

try {
    publisher.setTargetScalabilityMode("L3T3");
} catch (OpenTokException e) {
    Log.e(TAG, "Invalid scalability mode: " + e.getMessage());
}

Détermination du mode d'évolutivité cible

Appeler getTargetScalabilityMode() pour récupérer la valeur qui a été explicitement définie. Elle renvoie null si la méthode `setter` n'a jamais été appelée :

String mode = publisher.getTargetScalabilityMode();
// "L3T3" or null

Web (JavaScript)

L'objet Publisher comprend setTargetScalabilityMode() et getTargetScalabilityMode() des méthodes.

Configuration du mode d'évolutivité cible

Appeler setTargetScalabilityMode() sur un objet Publisher pour définir le mode d'évolutivité cible. La méthode accepte une chaîne de caractères identifiant le mode souhaité :

publisher.setTargetScalabilityMode('L3T3');

Cette méthode peut être appelée à tout moment ; il n'est pas nécessaire que la négociation du chemin multimédia soit terminée. Le mode sera appliqué dès que le chemin multimédia du Media Router sera établi.

La méthode génère une erreur si le mode demandé n'est pas valide (c'est-à-dire s'il ne fait pas partie de L1T1, L1T2, L1T3, L2T1, L2T2, L2T3, L3T1, L3T2, L3T3) :

try {
  publisher.setTargetScalabilityMode('L3T3');
} catch (err) {
  console.error('Invalid scalability mode:', err.message);
}

Détermination du mode d'évolutivité cible

Appeler getTargetScalabilityMode() pour récupérer la valeur qui a été explicitement définie. Elle renvoie undefined si la méthode `setter` n'a jamais été appelée :

const mode = publisher.getTargetScalabilityMode();
console.log(mode); // 'L3T3' or undefined

Linux

Le SDK C comprend otc_publisher_set_target_scalability_mode() et otc_publisher_get_target_scalability_mode() fonctions.

Configuration du mode d'évolutivité cible

Appeler otc_publisher_set_target_scalability_mode() Pour définir le mode d'évolutivité cible d'un éditeur :

otc_status status = otc_publisher_set_target_scalability_mode(publisher, "L3T3");
if (status != OTC_SUCCESS) {
    printf("Failed to set scalability mode\n");
}

Cette méthode peut être appelée à tout moment ; il n'est pas nécessaire que la négociation du chemin multimédia soit terminée. Le mode sera appliqué dès que le chemin multimédia du Media Router sera établi.

La fonction renvoie OTC_INVALID_PARAM si :

• Le pointeur d'éditeur est NULL
• La chaîne de caractères du mode d'évolutivité est : NULL
• Le mode demandé n'est pas valide (c'est-à-dire qu'il ne fait pas partie de L1T1, L1T2, L1T3, L2T1, L2T2, L2T3, L3T1, L3T2, L3T3)

Détermination du mode d'évolutivité cible

Appeler otc_publisher_get_target_scalability_mode() pour récupérer la valeur qui a été explicitement définie. Elle renvoie NULL si la méthode `setter` n'a jamais été appelée :

const char* mode = otc_publisher_get_target_scalability_mode(publisher);
if (mode != NULL) {
    printf("Target scalability mode: %s\n", mode);
}

iOS (Objective-C)

Les OTPublisherKit La classe comprend le targetScalabilityMode propriété.

Configuration du mode d'évolutivité cible

Régler le targetScalabilityMode propriété d'une instance OTPublisherKit permettant de définir le mode d'évolutivité cible :

NSError *error = nil;
[publisher setTargetScalabilityMode:@"L3T3" error:&error];

Le « setter » peut être appelé à tout moment ; il n’est pas nécessaire que la négociation du chemin multimédia soit terminée. Le mode sera appliqué dès que le chemin multimédia du routeur multimédia sera établi.

Le passeur effectue un OTError si le mode demandé n'est pas valide (c'est-à-dire s'il ne fait pas partie de L1T1, L1T2, L1T3, L2T1, L2T2, L2T3, L3T1, L3T2, L3T3).

Détermination du mode d'évolutivité cible

Lire le targetScalabilityMode propriété permettant de récupérer la valeur qui a été explicitement définie. Elle renvoie nil si la méthode `setter` n'a jamais été appelée :

NSString *mode = publisher.targetScalabilityMode;
// @"L3T3" or nil

iOS (Swift)

Les OTPublisherKit La classe comprend le targetScalabilityMode propriété.

Configuration du mode d'évolutivité cible

Régler le targetScalabilityMode propriété d'une instance OTPublisherKit permettant de définir le mode d'évolutivité cible :

try publisher.setTargetScalabilityMode("L3T3")

Le « setter » peut être appelé à tout moment ; il n’est pas nécessaire que la négociation du chemin multimédia soit terminée. Le mode sera appliqué dès que le chemin multimédia du routeur multimédia sera établi.

Le passeur effectue un OTError si le mode demandé n'est pas valide (c'est-à-dire s'il ne fait pas partie de L1T1, L1T2, L1T3, L2T1, L2T2, L2T3, L3T1, L3T2, L3T3).

Détermination du mode d'évolutivité cible

Lire le targetScalabilityMode propriété permettant de récupérer la valeur qui a été explicitement définie. Elle renvoie nil si la méthode `setter` n'a jamais été appelée :

let mode = publisher.targetScalabilityMode
// "L3T3" or nil

Fenêtres

Les Publisher La classe comprend le TargetScalabilityMode propriété.

Configuration du mode d'évolutivité cible

Régler le TargetScalabilityMode propriété d'une instance Publisher permettant de définir le mode d'évolutivité cible :

publisher.TargetScalabilityMode = "L3T3";

Le « setter » peut être appelé à tout moment ; il n’est pas nécessaire que la négociation du chemin multimédia soit terminée. Le mode sera appliqué dès que le chemin multimédia du routeur multimédia sera établi.

Le passeur effectue un OpenTokException si le mode demandé n'est pas valide (c'est-à-dire s'il ne fait pas partie de L1T1, L1T2, L1T3, L2T1, L2T2, L2T3, L3T1, L3T2, L3T3) :

try
{
    publisher.TargetScalabilityMode = "L3T3";
}
catch (OpenTokException e)
{
    Console.WriteLine("Invalid scalability mode: " + e.Message);
}

Détermination du mode d'évolutivité cible

Lire le TargetScalabilityMode propriété permettant de récupérer la valeur qui a été explicitement définie. Elle renvoie null si la méthode `setter` n'a jamais été appelée :

string mode = publisher.TargetScalabilityMode;
// "L3T3" or null

Idées reçues et FAQ

La vidéo évolutive est-elle la même chose que le VP9 SVC ?

Non. « Scalable video » est le nom de la fonctionnalité de la Video API vonage. Le mécanisme technique dépend du codec :

• VP8 met en œuvre la vidéo évolutive par le biais de diffusion simultanée. L'éditeur diffuse plusieurs flux indépendants.
• VP9 met en œuvre la vidéo évolutive par le biais de SVC. L'éditeur envoie un flux contenant des couches intégrées.

Ces deux mécanismes permettent à OpenTok Media Router d'adapter la qualité de la vidéo fournie à chaque abonné. Lorsque la documentation évoque la « vidéo évolutive » sans préciser de codec, elle fait référence à la fonctionnalité dans son ensemble.

La définition d'un codec préféré force-t-elle l'activation de la vidéo évolutive ?

Non. Le choix d'un codec préféré est indépendant de la vidéo évolutive. L'activation de la vidéo évolutive dépend de l'ensemble des éléments suivants :

1. Paramètre du projet de vidéo adaptative (Activé, Désactivé ou Auto).
2. La session en cours d'acheminement.
3. Le codec négocié prenant en charge la vidéo évolutive (VP8 ou VP9, et non H.264).
4. Le client ou le navigateur de l'éditeur prenant en charge la vidéo évolutive.

Pourquoi la Subscriber.setPreferredResolution() Ne pas adapter la qualité ?

Le côté abonné setPreferredResolution() et setPreferredFrameRate() Il s'agit d'indications destinées au routeur multimédia OpenTok, et non de commandes directes adressées à l'encodeur de l'éditeur. Le routeur multimédia OpenTok ne peut tenir compte de ces indications que lorsqu'il est en train de sélectionner activement l'une des couches vidéo évolutives pour cet abonné. Si l'une des conditions suivantes est remplie, il n'y a pas de couches parmi lesquelles choisir et les indications n'ont aucun effet :

• La vidéo adaptative est désactivée au niveau du projet ou sur le flux de publication.
• Le codec retenu est le H.264, qui ne prend pas en charge la vidéo évolutive.
• Le client de l'éditeur ne génère pas de couches évolutives. Par exemple, un éditeur Firefox qui envoie du VP9 sans couches SVC.
• L'éditeur a une contrainte de CPU ou de bande passante et n'envoie pas de couches supérieures pour que le routeur puisse faire son choix.
• L'éditeur a défini un mode d'évolutivité non par défaut via setTargetScalabilityMode() — La sélection des couches du Media Router s'appuie sur la configuration par défaut ; il se peut donc que les préférences de l'abonné ne correspondent pas à la couche à laquelle il s'attend.
• La session est relayée. Dans une session relayée, le routeur multimédia OpenTok ne transfère pas les flux ; la sélection de couche ne peut donc pas avoir lieu. Notez que dans les sessions relayées (P2P), l'encodeur de l'éditeur adapte directement son flux de sortie en fonction des conditions réseau de l'abonné, mais cela ne correspond pas à la sélection de couche vidéo évolutive.

Puis-je mélanger des éditeurs évolutifs et non évolutifs dans la même session ?

Oui. La vidéo évolutive est définie par flux, et non par session. Une même session peut regrouper simultanément des éditeurs utilisant la vidéo évolutive et d'autres qui ne l'utilisent pas, par exemple des éditeurs H.264, ou des clients diffusant avec la vidéo évolutive désactivée. Le routeur multimédia OpenTok gère chaque flux de manière indépendante.

La vidéo évolutive a-t-elle une incidence sur l'archivage ?

Pour Diffusion simultanée VP8l'archiveur enregistre en utilisant la couche de qualité la plus élevée disponible.

Pour VP9 SVCLes archives composées sont toujours transcodées en H.264/AAC MP4, quel que soit le codec de la session. Les archives composées sont toujours transcodées en H.264/AAC MP4, quel que soit le codec de la session.

La lecture des fichiers WebM VP9 SVC peut ne pas fonctionner dans tous les lecteurs multimédias. Pour les instructions de lecture et les commandes de transcodage, voir Notes sur l'archivage des vidéos VP9 dans le guide VP9.

Pour plus d'informations, voir cet article de soutien.