Didacticiel sur la qualité de service (QOS) de la vidéo

Introduction

Ce document passe en revue le sujet de la qualité des appels vidéo et fournit un didacticiel sur les éléments à garder à l'esprit pendant que la qualité de service (QoS) est configurée sur une passerelle Cisco Unified Border Element(CUBE) ou Time-Division Multiplexing (TDM).

Contribué par Baktha Muralidharan, ingénieur TAC Cisco, édité par Anoop Kumar.

Conditions préalables

Conditions requises

Ce document est particulièrement utile pour les ingénieurs qui connaissent la voix sur IP (VoIP), bien que d'autres puissent le trouver utile.

Components Used

Aucun matériel ou logiciel spécifique n'est utilisé pour écrire ce document.

Informations générales

L'audio numérisé sous sa forme la plus simple est un ensemble d'échantillons audio, chaque échantillon décrivant la pression sonore pendant cette période.  Le son de conversation peut être capturé et reproduit avec une grande précision, avec seulement 8000 échantillons par seconde[1].  Cela signifie que tant que le réseau est en mesure de transporter les échantillons sans délai excessif, gigue et perte de paquets, le son peut être fidèlement reproduit à l'autre extrémité.

En revanche, la présentation, le traitement et le transport de la vidéo sont beaucoup plus complexes. La luminosité, le contraste, la saturation des couleurs, la réactivité (au mouvement) et la synchronisation labiale sont quelques-uns des attributs qui déterminent la qualité de la vidéo. Les échantillons vidéo nécessitent généralement un espace beaucoup plus grand. Sans surprise, la vidéo place une demande beaucoup plus importante sur la bande passante du réseau, sur le réseau de transport. La qualité audio est déterminée par : Haut-parleur microphone du codec casque - la qualité des appels vidéo du réseau de transport par compression est affectée par : Périphérique d'affichage de la caméra Codec vidéo Compatibilité/interopérabilité du réseau de transport

Remarque : il est important de comprendre que contrairement à l'audio, un certain nombre de points de terminaison vidéo se produisent lorsqu'il s'agit de régler la qualité.

Objectif

La QoS en général est un sujet vaste et complexe qui nécessite de prendre en compte les exigences globales du trafic (plutôt que le seul trafic que vous souhaitez améliorer) et doit être vérifié sur chaque composant réseau le long du chemin du flux multimédia. La qualité de la vidéo dans une vidéoconférence est encore plus complexe car elle implique en plus des composants réseau, l'examen et l'examen de la configuration et du réglage des points d'extrémité. En général, la qualité de la vidéo implique :

• Réglage des points de terminaison : optimisation de la configuration des points de terminaison (résolution, trame par seconde, par exemple)
• Optimisation du transport - Optimisation du réseau pour le transport du trafic vidéo par SLA réseau.
• Considérations relatives à l'interopérabilité : les appels vidéo impliquent souvent des terminaux de fonctionnalités variées. Concevoir et configurer les systèmes pour optimiser l'interopérabilité peut avoir un impact sur la qualité vidéo.

Ce document met l'accent sur les considérations de QoS sur la passerelle IOS ou CUBE lors du traitement des appels vidéo.

Le réglage des points d'extrémité implique l'ajustement d'un ensemble de paramètres sur les points d'extrémité vidéo. Cela dépend bien sûr du produit, mais voici quelques boutons “ généraux ” :

• Résolution (taille de l'image)
• Fréquence de trame (c.-à-d. sensibilité au mouvement/réalité)
• Étiquetage (marquage ToS)

Régler le réseau pour la vidéo implique généralement les opérations suivantes :

• Comprendre la composition du trafic traversant le CUBE, par exemple le volume de pointe [appel], etc.
• Examen de la capacité des liaisons/canaux réseau
• Concevoir des politiques QoS appropriées pour s'assurer que le SLA est respecté pour chaque classe de trafic

L'interopérabilité intervient lorsque des systèmes hétérogènes (téléphonie vidéo et téléprésence) participent à une conférence téléphonique. L'expérience fournie par un système de téléphonie à paires torsadées blindées et vidéo est fondamentalement différente. L'interopérabilité entre eux est généralement obtenue en les reliant à l'aide d'un processus appelé cascade.

Ce que cela ne couvre pas

Il ne s'agit pas d'un document de conception ni d'un document de qualité de service vidéo complet. Plus précisément, ce document ne couvre pas les sujets suivants :

• Signalisation [protocoles] d'appels vidéo, au-delà de ce qui est nécessaire pour illustrer des aspects liés à la qualité de service.
• Configuration/configuration des terminaux vidéo
• Étude complète des mécanismes QoS, notamment la réglementation, la mise en file d'attente, le formatage et la rafale
• Examen de la configuration QoS sur les commutateurs de couche 2 ou considérations de limites de confiance.

Caractéristiques du trafic réseau de la vidéo

La vidéo, comme l'audio, est en temps réel.  Les transmissions audio sont à débit constant (CBR). En revanche, le trafic vidéo tend à être en rafale et est appelé débit variable (VBR). Par conséquent, le débit binaire pour la transmission vidéo ne sera pas nécessairement constant si nous devons maintenir une certaine qualité[2].

Image 1

La détermination de la bande passante et de l'éclatement requis pour la vidéo est également plus importante. Cette question est traitée plus loin dans ce document.

• Le trafic vidéo est dense.
• Les paquets vidéo peuvent être assez volumineux.
• Le son est toujours CBR. La vidéo est généralement VBR. 

Pourquoi la vidéo est-elle en rafale ?

La réponse réside dans la manière dont la vidéo est compressée. N'oubliez pas que la vidéo est une séquence d'images (images) jouées pour fournir un effet de mouvement visuel. Les techniques de compression utilisées par les codecs vidéo utilisent une approche appelée codage Delta [3], qui fonctionne en stockant les valeurs d'octets comme différences (deltas) entre les valeurs séquentielles (échantillons) plutôt que les valeurs elles-mêmes. En conséquence, la vidéo est codée (et transmise) comme des images consécutives transportant uniquement les pièces “ en mouvement ” plutôt que des images entières.

Vous vous demandez sans doute pourquoi le son change progressivement également ? Eh bien, c’est vrai, mais “ ” de mouvement (ou dynamique) n’a pas autant d’impact sur l’audio que sur la vidéo. Les échantillons audio de 8 bits ne se compressent pas mieux lorsque les échantillons vidéo (trames) codés en delta le font. La variation relative de l'échantillon (image à image) à l'échantillon est beaucoup plus petite que celle de l'audio. Selon la nature et le degré de mouvement, les échantillons vidéo peuvent varier considérablement en taille. L'image 2 illustre la compression vidéo :

Image 2

Une I-frame est une image Intra-codée, en fait une image entièrement spécifiée, comme un fichier d'image statique classique.

Une image P (image prédite) ne contient que les modifications de l'image du cadre précédent. L'encodeur n'a pas besoin de stocker les pixels d'arrière-plan immuables dans la trame P, ce qui permet d'économiser de l'espace. Les trames P sont également appelées trames delta.

Une trame B (image prédictive bidimensionnelle) économise encore plus d'espace en utilisant les différences entre la trame actuelle et les trames précédentes et suivantes pour spécifier son contenu.

Mesure de la qualité vidéo

Les équipements vidéo Cisco ne mesurent pas la qualité vidéo en tant que telle, et la qualité vidéo est donc perçue plutôt que mesurée. Il existe des algorithmes normalisés qui mesurent la qualité au moyen d'un MOS (Mean Opinion Score). Cependant, si les problèmes signalés sur la qualité audio sont une indication, les cas de qualité vidéo (TAC) sont plus susceptibles d'être ouverts parce que les utilisateurs perçoivent les problèmes de qualité plutôt que des rapports par un outil.

Contrôles aux points d'extrémité

Les facteurs qui affectent la qualité de la vidéo sont les suivants :

• le codec vidéo (MPEG4, H261, H263, H264 et H265)
• taille (1/8e écran, 1/4 écran, plein écran)
• cadence d’images (1 à 30 images par seconde, 6 par défaut)
• le paramètre de qualité de compression (faible, moyen, élevé)

Généralement, chacun des éléments ci-dessus est sélectionnable/contrôlable aux points d'extrémité.

Artefacts visibles

Câblage, Combing & Banding s'habituent à ces termes, qui font partie de la taxonomie de la vidéo. Reportez-vous à ce document pour plus de détails sur les handicaps vidéo courants :

Réf : 

http://www.estadistica.cl/public_disk/Programas/DeTodo/Manejo y pegado de subtitulaires/VirtualDub-1.6.14/help/p-artifacts.html

  

SLA de réseau de transport pour la qualité vidéo

Le SLA réseau recommandé pour la vidéo[4] est le suivant :

• Latence ≤ 150-300 ms
• Jitter ≤ 10 ms-50 ms
• Perte ≤ 0,5 %

Par ailleurs, les SLA réseau recommandés pour le transport audio sont les suivants :

• Latence ≤ 150-300 ms
• Jitter ≤ 20 ms-50 ms
• Perte ≤ 1 %

Remarque : la vidéo est clairement plus sensible à la perte de paquets que la voix.  Cela devrait être attendu une fois que vous avez compris que les intertrames nécessitent des informations des trames précédentes, ce qui signifie que la perte d'intertrames peut être dévastatrice pour le processus de reconstruction de l'image vidéo.

Contrôles dans le réseau de transport

En règle générale, le SLA pour le transport vidéo peut être fourni à l'aide de politiques de QoS très similaires à celles utilisées pour le transport audio. Il y a cependant quelques différences en raison de la nature du trafic vidéo.

  

Remarque : bien que la portée de ce document soit limitée au composant CUBE, n'oubliez pas que la QoS est de bout en bout.

Variétés vidéo

Toutes les vidéos sont-elles identiques ? Pas tout à fait. Les variations de la vidéo en tant que support incluent :

• Téléphonie vidéo/vidéoconférence
• Interactif en temps réel
• Bande passante relativement faible. Jusqu'à 1 Mbit/s
• Téléprésence
• Interactif en temps réel
• Expérience immersive
• Nécessite une bande passante très élevée
• Diffusion en continu
• En temps réel, unidirectionnel
• Peut être monodiffusion ou multidiffusion
• Bande passante élevée
• Non sensible au délai (la vidéo peut prendre plusieurs secondes pour mettre la file d'attente en attente)
• Insensible à la gigue (en raison de la mise en mémoire tampon des applications)
• La perte ne doit pas dépasser 5 %.
• La latence ne doit pas dépasser 4 à 5 secondes (selon les capacités de mise en mémoire tampon de l'application vidéo)
• Certaines vidéos (par exemple des divertissements) peuvent être prises en compte pour le service Scavenger.

Note : Par souci de concision, les illustrations ne sont pas fournies en détail pour chaque type de vidéo mentionné ci-dessus.

Codecs de trafic vidéo

• • Le H.261- Codec a été conçu à l'origine pour la transmission sur des lignes RNIS. Avec l'utilisation de la liaison vidéo, les débits vidéo sont des multiples de 64 Kbits/s.
  • H.263 - Codec est utilisé dans les vidéoconférences IP ainsi que dans les réseaux RNIS. La norme H.263 nécessite la moitié de la bande passante pour obtenir la même qualité vidéo que la norme H.261. En conséquence, H.263 a largement remplacé H.261. La norme H.263 a été optimisée pour une large gamme de débits binaires et pas seulement 64 K bits/s comme avec la norme H.261.
  • H.264/MPEG-4 - Cs est actuellement l'un des formats les plus utilisés et utilise la moitié ou moins du débit binaire de MPEG-2, H.263 ou MPEG-4 Part 2.
  • H265 - Un des nombreux successeurs potentiels du H.264 largement utilisé et basé sur l'extension des mêmes concepts. Il prend en charge des résolutions allant jusqu'à 8 192×4 320, y compris un disque dur UHD de 8 000 tr/min.

Remarque : la vidéo, tout comme l'audio, est transportée dans le protocole RTP (Realtime Protocol).

Mécanismes QoS pour la vidéo

En principe, les mécanismes QoS utilisés pour fournir les SLA pour un réseau de transport vidéo sont essentiellement les mêmes que ceux pour l'audio. Il y a cependant quelques différences, principalement en raison de la nature enflammée de la vidéo et de la transmission VBR.

Il existe deux approches à la qualité de service : les services intégrés (intserv) et les services différenciés (diffserv).

Considérez Intserv comme fonctionnant au niveau de la signalisation et Diffserv au niveau du support. En d'autres termes, le modèle intserv assure la qualité en opérant au plan de contrôle ; Diffserv vise à garantir la qualité en opérant au niveau du plan de date.

Dans l'architecture IntServ, les périphériques réseau demandent des réservations de bande passante statique et maintiennent l'état de tous les flux réservés lors de la classification, du marquage et de la mise en file d'attente de ces flux ; l'architecture IntServ fonctionne et s'intègre à la fois au plan de contrôle et au plan de données, et a donc été largement abandonnée en raison de limitations inhérentes à l'évolutivité. Le protocole utilisé pour effectuer les réservations de bande passante est RSVP (Resource ServerVation Protocol).

Il y a aussi IntServ/DiffServ Model, qui est une sorte de mélange. Ce modèle sépare les opérations du plan de contrôle des opérations du plan de données. Le fonctionnement du RSVP est limité au contrôle d'admission uniquement ; avec les mécanismes DiffServ gérant les opérations de classification, de marquage, de réglementation et de planification. Ainsi, le modèle IntServ/DiffServ est hautement évolutif et flexible.

Remarque : ce document se concentre uniquement sur l'approche diffserv (schéma de hiérarchisation viz-a-viz, LLQ).

Garantie de bande passante

La bande passante est évidemment le paramètre qos le plus fondamental.  Cela dépend de plusieurs paramètres, notamment :

• Codec utilisé
• Débit de trame
• Taille de l'image
• Volume d'appels (pic et moyenne)

Le vieux truc de jeter de la bande passante sur le problème n'est pas toujours la solution. Ceci est particulièrement vrai pour la qualité vidéo. Par exemple, avec CUVA (Cisco Unified Video Advantage), il n'existe aucun mécanisme de synchronisation entre les deux périphériques (téléphone et PC) concernés. Par conséquent, la QoS doit être configurée pour minimiser la gigue, la latence, les paquets fragmentés et les paquets hors service.

Remarque : la vidéo interactive a les mêmes exigences de niveau de service que la VoIP, car un appel vocal est intégré dans le flux vidéo.La vidéo en continu présente des exigences beaucoup plus laxistes, en raison de la grande quantité de mise en mémoire tampon qui a été intégrée aux applications.

Enfin, il est important de comprendre que contrairement à la VoIP, il n'existe pas de formule propre pour calculer la bande passante incrémentielle requise. En effet, les tailles et les débits des paquets vidéo varient considérablement et dépendent largement du degré de mouvement des images vidéo transmises. Plus d'informations plus tard.

mise en file d’attente

La mise en file d'attente à faible latence (LLQ) est la stratégie de mise en file d'attente préférée pour le son VoIP. Étant donné les exigences strictes de TP en matière de délai/gigue et la nécessité de synchroniser l'audio et la vidéo pour CUVA, la mise en file d'attente LLQ (Priority Queuing) est également recommandée pour tout le trafic vidéo. Notez que, pour la vidéo, la bande passante prioritaire est généralement brouillée de 20 % pour tenir compte de la surcharge.

Compression d'en-tête

Non recommandé pour la vidéo.

Fragmentation et entrelacement des liaisons

LFI est un mécanisme populaire qui permet de s'assurer que la gigue n'échappe pas à tout contrôle sur les liaisons lentes, où les délais de sérialisation peuvent être élevés.

Mais là encore, Interactive-Video n'est pas recommandé pour les liaisons lentes. En effet, la LLQ à laquelle le trafic vidéo est affecté n'est pas soumise à fragmentation. Cela signifie que les paquets vidéo interactifs volumineux (tels que les trames I-Frames pleine circulation de 1 500 octets) peuvent entraîner des retards de sérialisation pour les paquets vidéo interactifs plus petits.

Élimination des encombrements

Rejet sélectif basé sur RTCP

Éclatement

Ce mécanisme QoS est important pour le trafic vidéo, qui, comme mentionné précédemment, est en rafale.

Le paramètre de rafale facultatif peut être configuré dans le cadre de la commande priority [6].

Avec H.264, la pire rafale serait le plein écran de la vidéo (compressée dans l'espace). D'après des tests approfondis sur des systèmes TP, il s'agit de 64 Ko. Par conséquent, le paramètre de rafale LLQ doit être configuré pour autoriser jusqu'à 64 Ko de rafale par trame par écran. Ainsi, le système CTS-1000 fonctionnant à 1080p-Best (avec la prise en charge optionnelle d'un flux vidéo auxiliaire[7]) serait configuré avec une LLQ avec un paramètre de rafale optimal de 128 (2x64) Ko.

Quelle est la bande passante ?

Quelle bande passante est donc nécessaire pour transporter un appel vidéo fidèlement ? Avant de passer aux calculs, il est important de comprendre les concepts suivants, qui sont propres à la vidéo.

Résolution

Cela fait référence à la taille de l'image.  D'autres termes couramment utilisés pour cela incluent le format vidéo et la taille d'écran.  Les formats vidéo les plus courants sont présentés ci-dessous.

Format	Résolution vidéo (pixels)
SQCIF	128 x 96
QCIF	176 x 144
SCIF	256 x 192
SIF	352 x 240
CIF	352 x 288
DCIF	528 x 384
4CIF	704 x 576
16 CIF	1 408 x 1 152

La grande majorité des équipements de vidéoconférence fonctionnent au format CIF ou 4CIF.

Réf : http://en.wikipedia.org/wiki/Common_Intermediate_Format

Remarque : il n'y a pas d'équivalence pour la résolution (vidéo) dans le monde audio

Débit de trame

Il s'agit du taux auquel un appareil d'imagerie produit des images consécutives uniques appelées images. Le débit de trame est exprimé en trames par seconde (ips).

Remarque : la métrique équivalente dans le monde audio est le temps d'échantillonnage. Par exemple, 8000 pour g.711ulaw.

Calcul de la bande passante

Les calculs de bande passante pour les systèmes de téléphonie vidéo et autres systèmes de vidéoconférence traditionnels ont tendance à être plus simples.

Prenons l'exemple d'un appel TP avec une résolution de 1 080 x 1 920.  La bande passante requise est calculée comme suit :

     2 073 600 pixels par trame

        x3 couleurs par pixel

        x1 octet (8 bits) par couleur

        x 30 images par seconde

        = 1,5 Gbit/s par écran. Non compressé !

Avec la compression, une bande passante de 4 Mbits/s par écran ( > 99 % compressé) suffit pour transporter la trame ci-dessus !

Le tableau suivant répertorie certaines combinaisons.

Image format	Luminosité pixels	Luminosité lignes	Non compressé débit binaire (Mbit/s)
			10 trames/s		30 trames/s
			Gris	Couleur	Gris	Couleur
SQCIF	128	96	1.0	1.5	3.0	4.4
QCIF	176	144	2.0	3.0	6.1	9.1
CIF	352	288	8.1	12.2	24.3	36.5
4CIF	704	576	32.4	48.7	97.3	146.0
16 CIF	1408	1152	129.8	194.6	389.3	583.9

Notez que les calculs ci-dessus concernent un seul écran. Un appel TP peut impliquer plusieurs écrans, de sorte que la bande passante totale de l'appel serait un multiple de la bande passante par écran.

Reportez-vous à https://supportforums.cisco.com/thread/311604 pour un bon calculateur de bande passante pour les systèmes Cisco TP.

Classification/marquage du trafic vidéo

Comment le trafic vidéo est-il identifié/distingué ? Une façon de classer les paquets sur CUBE consiste à utiliser des marquages DSCP.

Le tableau suivant illustre les marquages DSCP par référence QoS Cisco et RFC 4594.

Trafic	PHB de couche 3	DSCP de couche 3
Signalisation d'appel	CS3	24
Voix	EF	46
Visioconférence	AF41	34
Téléprésence	CS4	32
Flux multimédia	AF31	26
Vidéo de diffusion	CS5	40

PHB - Comportement par saut. Fait référence à ce que fait le routeur en ce qui concerne les fonctions de classification des paquets et de conditionnement du trafic, telles que la mesure, le marquage, le formatage et la réglementation.

Par défaut, avant la version 9.0 CUCM (Cisco Unified Call Manager) a marqué tout le trafic vidéo (y compris TelePresence) sur AF41. À partir de la version 9.0, CUCM préconfigure les valeurs DSCP suivantes :

• Appels TelePresence (vidéo immersive) sur CS4 et
• Appels vidéo (téléphonie vidéo IP) à l'AF41

Configuration

La configuration de la qualité audio implique le calcul de la bande passante prioritaire et l'implémentation de la stratégie LLQ sur une liaison WAN. Ceci est généralement basé sur le volume d'appels prévu et le codec audio utilisé.

Bien que les principes soient les mêmes, la bande passante vidéo via un CUBE n'est pas facilement calculable. Cela est dû à un certain nombre de facteurs, notamment :

• Comment calcule-t-on la bande passante totale requise en fonction des différents appels TP (passant par le CUBE) qui peuvent impliquer un nombre d’écrans et de résolutions différents ?
• La nature enflammée et le VBR
• Une autre dimension de la complexité [dans le calcul de la bande passante] concerne “ appels d'interopérabilité ” ? Les appels d'interopérabilité utilisent le protocole TIP. TIP est l'acronyme de Telepresence Interoperability Protocol. TIP est utilisé pour multiplexer plusieurs écrans, plusieurs flux audio, ainsi qu'un écran de données auxiliaire en deux flux RTP, un pour la vidéo et l'audio. Il permet des sessions point à point et multipoint ainsi qu'un mélange de terminaux à écran multiple et à écran unique. TIP est un protocole propriétaire de Cisco. Le protocole TIP est basé sur le protocole RTCP.

Par conséquent, le provisionnement de la bande passante pour les systèmes vidéo se fait parfois dans l'ordre inverse, c'est-à-dire la quantité de bande passante qu'un réseau de transport peut fournir, avec une politique LLQ, est déterminé en premier et, en fonction de cela, le point de terminaison est configuré. Les systèmes vidéo de point de terminaison sont suffisamment intelligents pour ajuster les différents paramètres vidéo à la taille du tuyau ! Par conséquent, les points d'extrémité signalent l'appel.

Gestion de la bande passante CUBE

Ainsi, comment CUBE gère-t-il la bande passante dans son offre/réponse (SIP) lors de la signalisation des appels vidéo ? CUBE remplit les champs de bande passante vidéo dans SDP comme suit :

  1. De l'attribut de bande passante dans le SDP entrant. Dans SDP, il existe un attribut bandwidth, qui a un modificateur utilisé pour spécifier le type de débit binaire auquel la valeur se réfère.  L'attribut a la forme suivante : b=<modificateur> : <valeur>

  2. À partir de la bande passante vidéo configurée sur le CUBE. Par exemple, la bande passante maximale estimée est calculée en fonction des fonctionnalités utilisées par l'utilisateur CTS et la bande passante estimée est préconfigurée sur CUBE, à l'aide de l'interface CLI-

• <modificateur de tias vidéo de bande passante> ou
• <modificateur de bande passante vidéo>

  3. Bande passante vidéo par défaut (384 Kbits/s)

Le flux d'appels présenté ci-dessous illustre comment CUBE remplit la bande passante dans les messages de signalisation d'appels-

Plus précisément, le CUBE utilise la logique suivante :

• Sur les offres (pour les appels à DO), CUBE utilise la bande passante configurée.
• Sur (réponses aux EO), CUBE envoie une bande passante dont la valeur est le minimum d'offre et de configuration locale.

Au niveau de la session SDP, la valeur TIAS est la quantité maximale de bande passante nécessaire lorsque tous les flux de médias déclarés sont utilisés[8].

Types de données utiles du codec vidéo

Il s'agit d'une autre zone dans laquelle la vidéo diffère de l'audio.  Les codecs audio utilisent des types de données utiles statiques. Les codecs vidéo, en revanche, utilisent des types de données utiles RTP dynamiques, qui utilisent la plage de 96 à 127.

La raison de l'utilisation du type de données utiles dynamiques est liée à la grande applicabilité des codecs vidéo. Les codecs vidéo ont des paramètres qui fournissent à un récepteur les propriétés du flux qui sera envoyé. Les types de données utiles vidéo sont définis dans SDP, à l'aide du paramètre a=rtpmap. En outre, l'attribut « a=fmtp: » PEUT être utilisé pour spécifier les paramètres de format. La chaîne fmtp est opaque et est simplement passée de l'autre côté.

Voici un exemple -

m=video 2338 RTP/AVP 97 98 99 100
c=IN IP4 192.168.90.237
b=TIAS:768000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500;packetiza tion-mode=1
a=rtpmap:99 H263-1998/90000
a=fmtp:99 custom=1024,768,4;custom=1024,576,4;custom=800,600,4;cif4=2;custom=720,480,2 ;custom=640,480,2;custom=512,288,1;cif=1;custom=352,240,1;qcif=1;maxbr=7680
a=rtpmap:100 H263/90000
a=fmtp:100 cif=1;qcif=1;maxbr=7680

Notez que les deux points de terminaison impliqués dans un appel peuvent utiliser un type de charge utile différent pour le même codec. CUBE répond à chaque côté avec une ligne a=rtpmap reçue sur l'autre jambe. Cela signifie que la configuration « charge utile asymétrique pleine » est nécessaire pour que les appels vidéo fonctionnent.

Bande passante de couche 2

Contrairement à la voix, le trafic vidéo IP en temps réel en général est un flux de bits variable et en rafale. Par conséquent, contrairement à la voix, la vidéo ne dispose pas de formules claires pour calculer la surcharge du réseau, car les tailles et les débits des paquets vidéo varient proportionnellement au degré de mouvement dans l'image vidéo elle-même. Du point de vue d’un administrateur réseau, la bande passante est toujours provisionnée au niveau de la couche 2, mais la variabilité de la taille des paquets et de la variété des supports de couche 2 que les paquets peuvent traverser de bout en bout rend difficile le calcul de la bande passante réelle qui doit être provisionnée au niveau de la couche 2. Cependant, la règle conservatrice qui a été soigneusement testée et largement utilisée est de surprovisionner la bande passante vidéo de 20 %. Cela prend en charge la rafale de 10 % et la surcharge du réseau de la couche 2 à la couche 4.

Surveillance/mesure

Comme mentionné précédemment, les terminaux vidéo ne signalent pas un MOS en tant que tel. Toutefois, les outils suivants peuvent être utilisés pour mesurer/surveiller les performances du réseau de transport et pour surveiller la qualité de la vidéo.

Vidéo SLA IP

Une fonctionnalité intégrée à IOS, IP SLA (Service Level Agreements), assure la surveillance active des performances du réseau. L'opération vidéo IP SLA diffère des autres opérations IP SLA en ce sens que tout le trafic est unidirectionnel, avec un répondeur requis pour traiter localement les numéros d'ordre et les horodatages et pour attendre une requête de la source avant de renvoyer les données calculées.

La source envoie une requête au répondeur lorsque l'opération vidéo en cours est terminée. Cette requête indique au répondeur qu'aucun paquet n'arrivera et que la fonction de récepteur vidéo dans l'opération vidéo peut être désactivée. Lorsque la réponse du répondeur arrive à la source, les statistiques sont lues à partir du message et les champs pertinents de l'opération sont mis à jour.

CiscoWorks IPM (IOS Performance Monitor) utilise la sonde IP SLA et MediaTrace[9] pour mesurer les performances et les rapports du trafic utilisateur.

CUBE VQM

La fonctionnalité VQM (Video Quality Monitor), disponible sur le CUBE, est un outil idéal pour surveiller la qualité vidéo entre deux points d'intérêt. Les résultats sont présentés sous forme de MOS.

Cette option est disponible depuis IOS 15.2(1)T et versions ultérieures. Notez que VQM utilise des ressources DSP.

Référence

• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a00807ca099.shtml
• http://www.cisco.com/en/US/partner/docs/video/milticomm/h320Bonding.html
• http://www.cisco.com/en/US/docs/solutions/TelePresence_Network_Systems_1.1_DG.pdf
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/qos.html
• http://www.cisco.com/en/US/docs/voice_ip_comm/uc_system/design/guides/videodg/basics.html
• téléphonie vidéo IP SRND -
• http://www.cisco.com/en/US/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/TP_InterOp_v2.html
• http://www.encoding.com/do_you_have_any_information_on_h.264_levels
• http://www.cisco.com/en/US/partner/tech/tk1077/technologies_configuration_example09186a0080111c1b.shtml
• http://www.watchpointvideo.com/pdf/Measuring%20Video%20Quality%20in%20Videoconferencing%20Systems.pdf
• http://www.broadcastpapers.com/whitepapers/Why_IPTV_is_different_from_IP_data_and_VoIP.pdf?CFID=25762102&CFTOKEN=60dc627518f1a19b-3F4F563D-FC97-8A61-6169D8F641750255
• http://en.wikipedia.org/wiki/Video_compression_picture_types
• http://inst.eecs.berkeley.edu/~ee290t/sp04/lectures/coding_standards.pdf
• http://www.cs.jhu.edu/~yairamir/cs667/Multimedia/compress.gif
• http://www.wireshark.org/lists/wireshark-users/201003/msg00125.html
• http://www.networkworld.com/news/tech/2002/0923tech.html
• http://www.javvin.com/protocolH263.html
• http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/configuration/12-2se/sla_video.html#GUID-29B155B6-AFC3-4F8B-AC1D-C127C9D797F0

 StartSelection:000000199 EndSelection:0000000538