---
title: "Multimedia sur IP"
...

\newpage{}

Endpoints : postes physiques (PC,smartphone).
Ponts de conférence (polycom)
Legacy : terminaux analogiques / PSTM 

# Transmission de médias

Etapes : 

Post emetteur :

- Sensor : Signal éléctrique
- ADC : Analog to Digital converter (théorème de Shannon)
- Preprocessing : traitement en amont,  Non standard
- Source coding : Codecs (compression du signal) -> standardisé
- Channel coding : Non standard
- Transmission Channel : réseau IP dans notre cas

Poste récépteur :

- Channel decoding :  Non standard
- Source decoding : Codecs (decompression du signal) -> standardisé
- Post processing :  Non standard
- DAC : Digital to Analog converter

## Transmission voix : preprocessing

On peut gagner de la qualité en pre traitant de la signal de façon moins chère qu'en augmentant la qualité des capteur (qui elle coute très cher -> recherche éléctro acoustique). 

Obligatoire :

- Annulation de l'écho
- Contrôle de niveau (ajuster le volume)

Pour meilleure qualité :

- Contrôle automatique du niveau
- Réduction de bruit ambiant
- Bruit de confort : proximité de la personne à l'autre bout
- Egaliseur de fréquence du micro : augmente la qualité (requis pour certaines applications)
- Localisation de source : focalisation sur la personne qui parle
- Reconnaissance vocale

## Transmission voix : source coding / décoding

Compression / décompression : retirer les redondances dans la voix. En gros on zip.
Standard ITU-T

Principales techniques : 

- Codage paramétrique : extraire les paramètres importants de la voix et les envoyer, on resynthétise la voix à partir de ces paramètres de l'autre coté. Ca marche bien que si on fait qu'une opération après ça perd trop en qualité. Ex : g729, g723, g722.2, OPUS (WebRTC)
- Codage d'onde : Extrait les information à partir de l'onde, donc ça perd pas en qualité quand on fait plusieurs opérations (mais ces dernières augmentent le délai).Ex : MP-3, g711 (bande étroite - téléphone), g722 (bande large)

## Transmission voix : channel coding / decoding

Dépend du canal de transmission.

VoIP (Voice on IP) : 

- Partie standardisée :
  -  la transformation en paquets
  -  Les infos sur la voix
- Partie non standardisée :
   -  FEC : mécanisme de redondance de parquets pour résister à la perte de paquets.

## Transmission voix : post processing

Obligatoire : 

- Controle d'écho (pas annulation)
- Equalization des niveaux

Pour meilleur qualité :

- Control automatique de l'equalization des niveau
- Réduction de bruit
- Equalization des fréquences d'enceinte
- Emulation de la position de la source (personne qui parle)

# Protocoles VoIP

Au dessus de l'IP TCP ou UDP.
Pour la voix c'est plutot UDP.
UDP protocole de la même couche que TCP. TCP fait du contrôle de flux. UDP ne vérifie pas l'arrivée des paquets (best effort) plus rapide mais si un paquet est perdu il est perdu définitivement.

Au dessus d'UDP on a RTP pour la voix (Real Time Protocole) ou RTCP.

Au dessus on a l'applicatif, donc les codecs audio et vidéo.

Au dessus on a les applications média (MS Teams, Discord, etc ...)

# Standard de Coding de Media Audio

Les plus utilisés : g711 (bande étroite), g722 (bande large), AMR Wide Band (gourmand en CPU mais efficace), g723, g729

Plus utilisé pour la téléphonie : g711 g723 g729.

## Codecs Wide Band

- g722 assez performant
- AMR Wide, 3GPP : dans les smartphone (consomme bcp de ressource)
- g729.1 (France Telecom)
- OPUS : utilisé pour internet, jusqu'à 20kHz (full bande, tout ce que l'humain peut entendre), il a un très bon débit binaire (bit rate)

## Wideband vs Narrowband

Bande étroite 200 Mhz - 3.4Khz : téléphonie classique. Bcp de basse fréquence disparait ainsi que les aigus. La sensation de présence est perdu. 

L'ajout de La partie 3.4 à 7 dans le wide bande permet d'augmenter l'intelligibilité de la conversion (différnces entre s et f par ex) car certaines différences entre des sons ne se différencient que su cette bande de fréquence.

le full bande  jusqu'à 20kHz (full bande, tout ce que l'humain peut entendre) c'est pour avoir les détails du son, par exemple pour la musique.

# Standard de Coding de Media Video

- H261
- H263
- H264 : plus commun
- 265 : plus récent mais moins adopté

# Protocole SIP

Quand on fait une communication, il faut un protocole pour établir la connexion avant de transmettre les infos avec un autre protocole.

**SIP** : Session Initialisation Protocole.
Centré sur l'utilisateur et pas le device.
Supporte la communication cross media / cross device : un device pour envoyer des message, un device pour l'audio et un pour la video.
Supporte la mobilité et la sécurité. On peut changer de device sans que ça coupe.
Ce protocole est très adopté, entre autres par WebRTC.

Méthodes SIP :

- REGISTER : enregistre la location de l'utilisation
- INVITE : inviter l'utilisateur à un call
- ACK : reconnaitres les messages échangés
- BYE : terminer connexion
- CANCEL : annuler
- OPTIONS : étendre les fonctionnalités natives (appplications riches)

# Protocoles RTP / RTCP

## RTP 

**RTP** : Real Time Protocol

RFC 3550
Transporte de la voix et vidéo en temps réel. Utilise UDP.

Pq les header du paquet IP est sur 32 bits ? -> s'adapter aux machines qui avaient une architecture 32 bits.

Payload type : identifier le format de la payload RTP.

## RTCP

- Monitoring sur RTP
- Pendant de RTP. Quand on choisit un port RTP, celui d'après c'est RTCP. RFC 3550. Fait partie entière de RTP.
- Permet d'avoir des infos sur la qualité du stream RTP : nb paquets reçus, gigue, paquets perdus...
- Doit utiliser moins de 5% de la bande passante de RTP. 
- Pas implémenté par tous les vendors.
- Ca peut être utile pour débug les problème sur l'infra : permet de calculer la latence. On peut faire une analyse à un point du réseau.

RTCP XR (extended reports) ajoutes des fonctionnalités :

- Paquet perdus
- gigue
- Ping
- Niveau
- Qualité d'appel
- Retour d'écho
- Niveau de bruit

# Qualité de voix

Qualité audio bcp + importante que la vidéo dans un cadre pro. Elle dépend de : 

- Qualité des logiciels sur les périphériques et sur le serveur
- Par combien d'élément on passe, et leur qualité
- Qualité des canaux (wifi, filaire, réseau managé/non managé => un service qu'on contrôle ou pas)
- Le comportement de l'utilisateur
- L'utilisation de codecs (narrow / wide band)

## Qualité des périphériques de restitution

- Qualité du haut parleur
- Echo (couplage acoustique)
- Bruit émit par le PC (ventilateur)

## Qualité du micro 

- Sensibilité
- Qualité dans les fréquentes hautes et basses
- Position du microphone (pour les laptops)

## Mode de communication (peer to peer ou multiparty)

Pour conférences il faut :

- De l'annulation d'écho acoustique (AEC) de haute qualité.
- Au minimum deux compressions (entre l'utilisateur et le serveur et le serveur et le destinataire) : si on a des codecs moyens, le fait d'en avoir deux peut poser des soucis

## Charge CPU

Coté serveur (dans le cas de la conférence) il faut bien configurer pour éviter des ressources soit allouées à d'autres tâches que le traitement du signal temps réel sinon on a des soucis.

Coté client, on peut avoir de la latence au niveau du traitement si trop de tâche s'exécutent sur le poste client. Voir même de la perte de paquet à l'émission.

## Réseau

On peut avoir des pb venant du réseau s'il n'est pas géré par l'entreprise, par exemple dès qu'on a du Wifi.

Principaux problèmes :

- Gigue => latence
- Perte de paquet (congestion, ou équipement de mauvaise qualité)
- VPN/TCP dès qu'on a une perte de paquet ça va faire exploser le nombre paquet à cause du controle de flux et donc de la latence
- Nombre de compression. On peut multiplier les compression sur le réseau n'est pas correctement déployé
- Types de codecs
- Configuration de la QoS pour le temps. Si la priorité n'est pas donnée au traffic temps réel, il va y avoir des latences / coupures

## Environnement

- Bruit de fond
- Position de l'utilisateur par rapport au matériel. Si le micro est trop loin, le niveau est trop faible. Aussi distorsion si la directivité du micro n'est pas optimale
- Pour les casque les bruits de respiration peuvent également être gênant.
- Bruit du clavier

# Voice Enhanced Device (VED)

## Coté terminal

- AEC : Composant principal du VoIP. C'est toujours le défi sur lequel on recherche le plus
- Anti saturation. Inclut dans le hardware
- Réduction des bruits de clavier
- Réduction des bruits de ventilation
- Contrôle du bruit, et génération de bruit de confort

## Coté serveur

- Détection des personnes qui parlent à un instant T dans la conférence

## Coté terminal et serveur

- AGC : Contrôle Automatique du Gain
- Réduction de Bruit
- PLC (Packet Loss Concealement), gestion de la gigue
- VAD : Détection de l'activité vocal

# Traitement du signal et amélioration de voix

## Délai

Impact sur délai sur la qualité :
- 0 à 150 ms : conversation normale
- 150 à 300 ms : qualité acceptable
- 300 à 700 ms : demi duplex (talkie walkie)
- au delà : communication impossible

## Perte de paquet

La perte de paquet est due à des erreurs réseau. On utilise la PLC (Dissimulation de la perte de paquets) pour générer un signal de voix synthétique qui va remplacer les paquets manquants. La PLC est intégrée dans les Codecs G.723 et G.729.

La PLC est obligatoire après le buffer d'annulation de la gigue.

## Niveau

L'ALC (Contrôle Automatique du Niveau) est un module des VED. Il possède un algorithme qui fonctionne avec l'annulation d'écho afin d'adapter le gain du signal si son énergie dépasse un certain seuil. Il doit donc augmenter le niveau quand on parle et le réduire quand on ne parle pas.

## Bruit

Les dispositif de réduction de bruit doivent :

- Ne pas induire de délai
- Améliorer le naturel et l'intelligibilité du signal
- Amélioration de ratio signal/bruit
- Simple à calculer

# Transmission Vidéo

## Pre Processing

## Codage / Décodage de source

Le codage de source est la compression vidéo. C'est le défi principal de la transmission vidéo. Cela permet de réduire la redondance spatiale et temporelle des images.

Spatial : Au sein d'une image
Temporel : Entre les images de la vidéo

Seul le décodeur est standardisé. L'encodeur ne l'est pas, mais il doit être compatible avec le décodeur. Beaucoup d'implémentations existent qui varient en qualité.

## Codage / Décodage de canal

Dépend du canal de transmission. Pour la VoIP on a la paquetisation pour le transport IP.
Pas entièrement standardisé. Les mécanismes de transmission le sont mais uniquement sur TCP.
D'autre codage de canal comme FEC ne sont pas standardisés.

## Post Processing 

Augment la qualité grâce à :

- Contrôle du niveau de luminance en fonction des conditions
- Egalisation du RGB par rapport aux caractéristiques de l'écran
- Réduction de bruit (intégré dans le décodeur en général)
- Autre améliorations (contraste, saturation)

# Standards Vidéo

## Codecs

ITU-I : 

- H120
- H261 : Multiples de 64 kb/s
- MPEG-1 : CDROM ; 1.6 Mb/s
- MPEG-2 : TV ; 2-3 Mb/s
- H263 : supportes plus de tailles de trame
- MPEG-4 : Application Multimédia
- H264
- H265 (HEVC : High Efficiency Video Codec)

## Format

La vidéo est formattée en YCbCr (YUV) : 

- Y : Luminance
- Cb & Cr : chrominance (composants de couleur)

La chrominance est moins importante en terme de perception par l'oeil humain, elle est sous échantillonnée (moins de pixels dans le plan de la chrominance) => premier niveau de compression de l'image.

Le format d'entrée est CIF (Common Intermediate Format) : 

- Luminance : 352x288
- Chrominance : 176x144

On capture en RGB et on restitue en RGB ducoup il faut faire deux transformations. On utilise une matrice pour obtenir le vecteur RGB à partir du vecteur YUV pour chaque pixel. On fait ça car il y a des traitements qu'on peut faire sur le format YUV qu'on ne peut pas faire sur le format RGB.


## Bases de la compression vidéo

On veut encoder une séquence d'image. 

Le principe de base c'est qu'on va encoder la première image de la séquence de façon spatiale. Il s'agit d'une INTRA-FRAME ou I-FRAME ou KEY-FRAME. Cette image est décodable toute seul, contient toutes les infos pour l'afficher.

Pour l'image suivante (2e), on va calculer le delta (la différence) entre les deux images et c'est ce delta qu'on va encoder. Ainsi, la première image est requise pour afficher la seconde. Il s'agit d'une PREDICTED-FRAME ou P-FRAME.

Pour la 3e image, on va calculer le delta avec toutes les frames d'avant. Il s'agit également une P-FRAME.

On continue ainsi jusqu'à recevoir une image complètement différente, ou après un certain nombre d'image, et on va refaire une I-FRAME.

Ainsi, si on perd un paquet dans le réseau cela va causer des soucis au décodage si l'ont ne reçoit pas une I-FRAME.

## Les blocs de l'encodeur

L'encodeur est constitué de trois principaux blocs : 

- Estimation du mouvement et compensation
- Transformation, Quantification, Zig-Zag Scan
- Encodeur de symboles (entropique)

Les deux derniers blocs sont utilisés pour l'encodage d'image statiques (PNG, JPEG). La première partie de l'encodeur est celle qui distingue la vidéo.

## Estimation du mouvement et compensation

Corrélation spatiale : différence entre deux pixel au sein de la même image

Corrélation temporelle : différences dans une succession d'image.

Les images ont une forte corrélation spatiale, mais la vidéo a une forte corrélation temporelle. Ce composant de l'encodeur va essayer de prédire le plus précisément possible la différence entre l'image courante et les images précédentes.

La principale méthode est la division d'images en blocs et comparaison des blocs entre n images successives en utilisant des translations (qui ne coutent pas cher en calcul).

## Transformation

1. Transformation

Prend en entrée un signal temporel / linéaire en signal fréquentiel. Décompose le signal en sa composante fréquentielle. On utilise la DCT (Transformation Sinus Discret), qui fait perdre un petit peut d'information mais compresse. Retire les fréquence élevées qui correspondent aux contours qui en masquent d'autres dans une image.

Permet de compacter l'énergie du signal. Diminue l'entropie et améliore les performance de l'encodeur de symbole.

2. Quantification

Pour chaque élément de la matrice, on va pas utiliser la même quantification pour optimiser l'espace pris. On va également perdre un peu d'information. C'est le principal paramètre qui contrôle le bitrate du codec.

3. Zig Zag Scan

Transformation matricielle pour transformer les données 2D en 1D (série) afin de pouvoir être traitées par l'encodeur de symbole.

## Encodeur de Symbole

Utilise les propriétés statistiques de l'entrée (entropie) pour encoder sans perte (comme un ZIP).

On utilise des techniques de DPCM (basé sur la théorie de l'information) : codage Arithmétique, codage de Huffman.

## H264 pour la communication vidéo

Applications de H264 : 

- Télévision, Streaming VOD, Blu-ray, Cinéma
- Communication vidéo

Flexible grâce à deux abstractions : 

- NAL (Network Abstractions Layer)
- VCL (Video Coding Layer)

Pour la communication vidéo, on utilise : 

- I-FRAME pour synchronisation (key frame)
- P-FRAME pour performances de synchro
- PPS & SPS : Picture Parameter Set & Sequence Parameter Set qui contiennent des infos comme la résolution.

Séquence d'ouverture d'une communication : 

SPS - PPS - I - P - P - ... - P - P - I - P - P - ... - P - P 

Beaucoup d'implémentations sont sur le marché, notamment motivées par le marché de la diffusion vidéo.

- Intel Ipp H264 : orienté RT, optimisé pour les CPU Intel
- x264 : orienté films
- FFMPEG : Beaucoup d'outils mais peu de fonctionnalités, mauvais traitement d'erreurs

## SIP et vidéo

Des attributs SIP sont rajoutés pour la qualité de service vidéo, notamment :

- Le NACK qui stipule que l'encodeur doit retransmettre un paquet
- Full Intra Request : le décodeur a trop d'erreur donc il demande à l'encodeur de refaire une trame I
- Temporary Maximum Stream Bitrate Request : quand on a des changements de bande passante dans le réseau, on peut demander de changer le biterate en fonction
- Temporal-Spatial Tradeoff Request : Permet de demander jouer sur le bitrate en jouant des trame P.

## Modes de paquetisation

Il en existe 3 :

## PM0

Une image est divisée en tranches et chaque tranche est contenue dans un paquet RTP. Permet de décoder un paquet sans avoir besoin d'un autre. Meilleure résistance à la perte de paquet.

## PM1

Une image est dans une seule tranche et va ensuite être fragmentée pour être transportée via RTP. Moins de résistance à la perte de paquet car si on en perd un l'image n'est pas décodable. Meilleur qualité d'image dans un réseau sans perte. 

## PM2 

Non utilisé dans la RTCOM car il y a du délai supplémentaire.

## Différences Audio / Vidéo

## Framerate  le biterate

Ils sont stables pour l'audio mais variable pour la vidéo.
Le framing (temps entre les paquets) est régulier pour l'audio alors que pour la vidéo il y a des bursts (ce qui peut créer des pertes sur certain switchs ; on peut utiliser un pacer pour éviter ça).

## Synchronisation coté décodeur

- Audio : élément hardware dans la carte son opère le contrôleur de gigue.
- Vidéo : une interruption logicielle opère le contrôleur de gigue en se basant sur le framerate estimé.

## Gestion des timstamps

Pour l'audio, les timstamps ne sont pas du tout important, ils sont utilisés seulement pour le debug. En revanche pour la vidéo, ils sont utilisés pour séparer trames et de faire une estimation du nombre d'images par seconde.

## RTP

- En vidéo, les marqueurs RTP sont utilisé pour marquer une fin de trame. Le payload type est également différent. En H264, il est négocié par SIP/SDP.

- En vidéo, le numéro de séquence RTP est utilisé pour détecté la perte de paquet.

## Gestion d'erreur 

Le niveau 0 de la gestion d'erreur est la possibilité de demander une I-FRAME à n'importe quel moment / périodiquement (Fast Update) :

- Via SIP :

	- Supporté par tous les endpoints
    - Latence
- RTCP Feedback :

	- Plus rapide car dans le même canal média
    - Négocié au niveau SDP
Deux types de méthode pour gérer la perte de paquet : 

## Résilience


- **RTX** : Ajouter de la redondance contrôlée (retransmission de paquets) afin de permettre le décodage même en cas de perte
	- Marche bien sur les réseau à faible latence
    - Négocié par SIP/SDP
    - Supporté par bcp de clients / MCU
- **FEC** (Forward Error Correction) : Codes correcteurs d'erreur
	- Pas aussi puissant que RTX, mais utile dans les réseau à latence élevés sur lesquels RTX ne peux pas être utilisé
    - Peut être négocié par SDP mais c'est pas standard

On doit utiliser soit RTX soit FEC mais pas les deux. On choisit en fonction de la latence du réseau.

## Dissimulation

La dissimulation est implémentée au niveau du codec.

- Interpolation des éléments voisins quand un élément est manquant (équivalent à la PLC audio)
- Multiple Reference Frame: utiliser plusieurs différentiels au lieu d'un seul pour atténuer l'effet de la perte de frame