TP TL53
J. Millet
TP Codec 1/6
TP TL53
J. Millet
TP Codec 2/6
- Fermer Bitrateviewer, cliquer sur le raccourci bureau vers Avidemux, charger Mire_SD.avi, - Menu Outils, cliquer "Histogramme de débit".
Q5) Indiquer le nombre d'images I, P, B ( en haut de fenêtre ).
En déduire ce que sont les pics que l'on avait pour le débit.
Expliquer par rapport au contenu du fichier ( image détaillée fixe dans le temps ) Q6) Faire la capture de Bitrateviewer pour les 4 autres vidéos.
Compléter les colonnes du tableau.
Q7) Indiquer avec les informations largeur et hauteur du tableau la différence entre les vidéos Ski_v1 et Ski_v2.
Comparer la forme du débit ( captures Bitrateviewer ).
Comparer les valeurs de débits ( moyen et max ).
Pourquoi la TNT SD ( 720x576 ) utilise la compression mpeg2 alors que la TNT HD ( 1920 ou 1440 x 1080p ) utilise mpeg4 ?
- Pour la vidéo de ski ( v1 ou v2 ), on a 3 creux importants sur le diagramme débit/temps.Q8) Repérer le temps en mn, sec qui leur correspond.
En regardant la vidéo dans VLC, expliquer pourquoi on a ces creux.
II) VLC en diffusion multimédia = Streaming:
On veut envoyer en diffusion des flux multimédia.
Sur Ubuntu, on a ajouté dans la barre du haut d'écran un applet de mesure de débit en temps réel: Netspeed.
- Ouvrir l'affichage graphique = Clic droit sur les débits de la barre du haut, Détails du périphérique.
Influence du rapport entre Débit vidéo et Débit de diffusion
On diffuse Mire_SD.Avi car elle permet d'analyser la résolution grâce aux lignes verticales plus ou moins fines.
- Sur Ubuntu, lancer VLC.
* Choisir Media/Diffusion, sélectionner le fichier Mire_SD.avi, Diffuser
* Cocher HTTP, mettre à côté l'IP du PC émetteur 192.168.1.23, noter le port associé.
On utilise un profil de diffusion prédéfini ( conteneur = encapsulation, codec vidéo, codec audio, sous-titres )
* Profil: Ogg/Theora (On a un ancienne version de Ubuntu qui reste légère pour être copiée mais on a alors VLC0.9 qui n'accepte pas de diffusion en codec MPEG2 pour des résolutions élevées ) On a en bas de la fenêtre la ligne de commande qui est réellement utilisée avec vlc.
vcodec -> codec vidéo
vb -> débit de la vidéo ( video bitrate ) scale -> échelle de diffusion ( réduction, zoom )
acodec -> codec audio ( ab = débit audio audio bitrate, channels = 1 mono ou 2 stéréo )
Q9) Quel est le débit prévu pour la partie vidéo du streaming ( vb = video bitrate ) ?
- Rendre visible à l'écran le débit sous ubuntu de netspeed ( on va faire à la fin une capture d'écran )
- Lancer la diffusion: Cliquer sur Stream ( on voit alors en bas à droite l'instant de lecture de vidéo et sa durée )
(
on aurait pu aussi voir la vidéo qui est diffusée en local en cochant dans la définition de la diffusion jouer en local")
Si le bouton Stream du bas est hors écran, taper entrée du clavier principal, rouvrir la fenêtre => VLC réduit le haut de fenêtre, le bas est accessible.
- Lancer VLC sur le PC réel, * Media/ouvrir un flux réseau
* Protocole: http
* Adresse de la source ( avec n° de port ! ): 192.168.1.23:8080
Q10) A la fin de la diffusion, imprimer l'écran sous PC réel montrant l'évolution du débit ( graphique de netspeed ubuntu ).
Ouvrir Paint, Coller ( CTRL+V ), découper l'image pour n'avoir que le débit, mettre ce graphique dans votre compte-rendu.
TP TL53
J. Millet
TP Codec 3/6
Q11) Evaluer la valeur moyenne du débit émis et noter cette valeur dans votre compte-rendu.
Est-ce que le serveur de diffusion VLC envoie seulement le fichier diffusé ( débit de Q1 ) ou ajoute-t-il des éléments de remplissage ( bourrage pour avoir un débit vb + débit ab + des entêtes HTTP/TCP/IP/Ethernet ) ?
Q12) Comment jugez vous la réception vidéo ?
Critères de jugement: Perturbations -> Fluidité = Evolution dans le temps: Saccades, ralentissements ( lag, freeze = blocage ) -> Résolution = Précision et netteté: Image pixelisée ( carré à l'écran ), flou, perte de contours
Pour être moins subjectif, en comparant vb aux valeurs de la vidéo ( voir Q1 et Q2 ), comment pouvait-on deviner ?
Diffusion d'une vidéo avec détails et mouvement: Ski_v1.mp4
Les vidéos les plus exigeantes à la compression sont celles qui évoluent vite et avec beaucoup de détails, en particulier de la neige ( ski ) ou de l'eau ( canoe kayak ).
On a introduit cette fois du mouvement dans la vidéo par rapport à la mire.
- Lancer la diffusion avec les mêmes paramètres de Ski_v1.mp4.
Q13) Recommencer Q10) pour la diffusion de la vidéo Ski_v1.
Q14) Comment jugez vous la réception vidéo ? Rappeler les valeurs pour cette vidéo de Q1 et Q2 ?
Diffusion d'une vidéo de résolution plus importante: Ski_v2.mp4 - Lancer la diffusion avec les mêmes paramètres de Ski_v2.mp4.
Q15) Recommencer Q10) pour la diffusion de la vidéo Ski_v2.
Q16) Comment jugez vous la réception vidéo ? Rappeler les valeurs pour cette vidéo de Q1 et Q2 ?
On change le débit de diffusion:- Mettre une diffusion en mode personnalisé, Encapsulation: Ogg/Ogm
Codec vidéo: Theora, Mettre débit à 8000 kbit/s , échelle 1 Codec audio: Vorbis, 128, 2
Q17) A la fin de la diffusion, faire une impression d'écran sous PC réel. Ouvrir Paint, Coller avec CTRL+V, découper l'image pour n'avoir que le débit netspeed, mettre ce graphique dans votre compte-rendu.
Q18) Que devient la forme du débit ? L'image a-t-elle une influence ( le débit s'adapte-t-il à l'image ou l'image au débit ) ?
- Recommencer la diffusion, mettre la vidéo sur le récepteur en grand écran.
On constate une qualité médiocre alors que l'on a cette fois un débit largement suffisant pour faire passer la vidéo. Mais la diffusion correspond à un codage de l'émetteur, une transmission sur le canal, un décodage au récepteur.
Q19) Pourquoi a-t-on une qualité médiocre ? ( codage source, transmission, décodage récepteur ? ) En déduire la contrainte pour regarder une émission en HD ( caméra, codage, diffusion, récepteur ).
III) Effet du ré-encodage sur le serveur de diffusion
Le choix du codec
(
et son réglage = pourcentage d'images I, P, B)
une influence sur: la qualité,le débit nécessaire, l'utilisation de l'UC, le délai.
- Ouvrir dans la barre de menu du haut le moniteur système ( clic droit ). Choisir l'onglet "Ressources".
TP TL53
J. Millet
TP Codec 4/6
Codec MPEG2
- Choisir le Profil MPEG2 ( Conteneur MPEG-TS, codec vidéo MPEG2, vb 800 kbit/s ).
Lancer la diffusion de Ski_v1.mp4.
- Mettre la fenêtre netspeed sous la partie CPU du moniteur système
(
Étendre si besoin pour que cela soit visible).
Q20) Faire une impression écran du PC réel, découper les 2 fenêtres ( netspeed et CPU du moniteur système ), ajouter à votre compte-rendu.
Codec H264
- Choisir le profil Personnalisé, Encapsulation MPEG-TS, codec vidéo H264, mettre 800 kbit/s.
codec audio MPEG Audio 128 kbit/s, 2 ( pas AAC ) Lancer la diffusion de Ski_v1.mp4.
Q21) Recommencer la question précédente.
Q22) A quoi correspond l'augmentation d'utilisation de CPU quand on lance le streaming sur l'émetteur avant d'activer le récepteur ( voir la fonction indiquée dans la ligne de commande VLC ou les questions Q1 Q2 codec vidéo ) ?
Q23) Conclusion sur le débit émis selon codec pour VLC ? sur l'utilisation CPU selon codec ?
IV) Effet du choix de protocole de diffusion selon la qualité de la ligne
Avec notre lien direct ( vmware = LAN parfait ) entre PC émetteur et récepteur, on n'a perdu aucun paquet sur le réseau, on n'a introduit qu'un retard de codage et décodage du codec.
Mais en réalité le réseau intervient entre émetteur et récepteur, c'est lui qui pose le plus de problème ( sauf en fibre ).
On a déjà joué sur le débit en réglant la diffusion. On va modifier
* le délai ( ou latence = temps de transfert des paquets ),
* la gigue ( variation du temps de transfert des paquets )
* le taux de perte des paquets.
Pour cela on utilise netem ( network emulation ) dans la gestion des flux de la carte réseau ( tc = traffic control ).
- Ouvrir un terminal sous Ubuntu, se mettre en sudo su, ouvrir avec un éditeur ( gedit ) le script simadsl.
( Mettez vous d'abord dans son répertoire = Bureau !! sinon vous avez un fichier vide )
( inspiré de http://blog.nicolargo.com/2009/03/simuler-un-lien-wan-sous-linux.html , http://wiki.secondlife.com/wiki/BLT et http://swik.net/netem )
-
Mettre les caractéristiques d'une bonne ligne adsl: BWU=8Mbit ( 8 Mbit/s sortant du DSLAM côté serveur ) BWD=256 kbitDELAYD=20ms DELAYU=20ms LOSSU=1%
LOSSD=1%
TP TL53
J. Millet
TP Codec 5/6
- Sauvegarder et lancer le script: ./simadsl start Diffusion avec protocole HTTP sur TCP
- Lancer le streaming en profil MPEG2 en HTTP de Ski_v1.mp4 ( comme avant mais avec une mauvaise ligne ).
On constate des blocages ( freezes ).
Q24) Est-ce dû au protocole http sur tcp ( attente d'acquittements ) ou à un blocage de débit ( voir netspeed ) ?
- Arrêter le script: ./simadsl stop- Définir une très mauvaise ligne avec perte de paquets importantes: BWU=3Mbit LOSSU=10%
LOSSD=10%
- Lancer le script: ./simadsl start
- Lancer le streaming en profil MPEG2 en HTTP.
On constate des blocages ( freezes ).
Q25) Conclusion sur une diffusion en http sur une mauvaise ligne ?
Diffusion avec protocole RTP sur UDPOn utilise un autre protocole pour les diffusions: RTP ( Real Time Protocol sur UDP ) - Lancer une diffusion en UDP sous Ubuntu:
* Media / Diffusion, choisir Ski_v1.mp4.
* Sortie: RTP, mettre l'adresse IP DU DESTINATAIRE (PC réel en 192.168.1.2), laisser le port 1234.
* Profil MPEG2 avec débit 800 kbit/s - Démarrer le script de ligne: ./simadsl start
- Ouvrir VLC du PC réel: Media/ouvrir un flux réseau,
RTP, IP destinataire du flux (PC réel 192.168.1.2 ), port 1234.
Q26) Conclusion sur une diffusion en RTP sur une mauvaise ligne?
- Arrêter le flux du streaming sous Ubuntu, relancer.
Q27) Que se passe-t-il sur le client configuré en RTP ?
- Arrêter le script: ./simadsl stop- Arrêter VLC, fermer la fenêtre de détails de Netspeed.
V) Codecs audio, protocoles RTP ( Real Time Protocol ) et RTCP ( Real Time Control Protocol ) On va utiliser un système de ToIP pour étudier les codecs audio et leur transfert via RTP.
- Lancer le serveur ToIP sur le PC réel: Axon - ( On a défini 2 téléphones 1000 et 1001 )
- Lancer sur le PC réel le client Express Talk, faire sa configuration si nécessaire: n° 1000 ( port TCP 5070 ), serveur en 192.168.1.23 ( Vérifier qu'il n'y a pas de message rouge ( il s'est enregistré auprès du serveur SIP number: 1000@192.168.1.2:5070 ) - Lancer le client sur le PC virtuel: Xlite ( port TCP 5060 )
Le démarrage est long ( 1 mn puis il faut attendre 1 mn qu'il passe la détection de firewall ).
Vérifier qu'il affiche son numéro = 1001
- Téléphoner pour vérifier que tout marche. Couper la communication.
TP TL53
J. Millet
TP Codec 6/6
Codec G711 loi µ ou A
- Dans le PC Ubuntu, cliquer en face avant de xlite sur tous les codecs sauf G711a (le seul qui reste lumineux).
- Dans le PC réel, lancer une capture wireshark sur l'interface ethernet ( 192.168.1.2 ) - Appeler depuis Xlite sous ubuntu.
- Terminer la capture wireshark après 1 mn, se mettre sur une trame RTP.
- Telephony / RTP / Stream Analysis . L'appel utilise l'encapsulation de protocoles suivante
La colonne "IP BW" de la fenêtre Wireshark donne le débit au niveau Ethernet.
Q28) Noter le débit ( colonne IP BW, prendre au milieu de la capture quand la communication est en régime stable ).
Sachant que le débit du flux de voix G711 est 64 kbit/s, quel est le débit des entêtes ? Quel est le rendement = taille flux du média / taille totale de la trame ( média + entêtes ) ?
Codec GSM
- Dans le PC Ubuntu, cliquer en face avant de xlite pour n'avoir que GSM qui reste lumineux.
- Dans le PC réel, relancer une capture wireshark sur l'interface 192.168.1.2 - Appeler depuis Xlite sous ubuntu.
- Terminer la capture wireshark après 1 mn, se mettre sur une trame RTP.
- Telephony / RTP / Stream Analysis.
Q29) Noter le débit = colonne IP BW ( prendre au milieu de la capture quand la communication est en régime stable ).
Connaissant le débit des entêtes grâce à la question précédente, en déduire le débit du codec.
A-t-on le codec GSM d'origine à 13 kbit/s ou une de ses évolutions ?
- Fermer la machine virtuelle.- Remettre l'adresser IP d'origine du PC réel notée en début de tp.
Remarque: On aurait pu jouer avec le script simadsl en branchant haut-parleurs et micro:
Avec des délais de 200 ms up et down => 200+200 = 400 ms => perte d'interactivité.
Avec une perte de paquets => perte de qualité.
Remarque: Ne pas confondre RTP, RTCP avec RSVP ou RTSP.
RSVP ( Resource Reservation Protocol ) est un protocole permettant de mettre en place de la qualité de service pour les applications de streaming sur IP.
RTSP ( Real Time Streaming Protocol ) est un protocole qui permet au client de contrôler le serveur de diffusion ( lecture à une position quelconque, pause,... ).
Ethernet RTP UDP IP
Codec voix
TP TL53
J. Millet
TP Asterisk sur Raspberry Pi
192.168.0.1 puis 10.0.0.3
TP Asterisk Sur
Raspberry Pi
Matériel:
1 RPI avec alim,1 graveur de carte SD et 1 fichier image OS_RPI_raspbx.img sur PC 1 webcam usb,
1 casque HP + micro ( pour enregistrer messages IVR ), 1 SPA3102,
1 téléphone analogique
1 PC avec xlite, ssh, firefox ( flux MJPEG ), win32diskImager, tftpd32.
I Z
téléphone SPA3102
numérique n° 4200 Line = FXO
Phone = FXS
Ethernet Internet
n° 101 donné par SPA3102
Objectifs:
- Utiliser Asterisk.
- Faire un serveur vocal interactif.
- Utiliser Asterisk avec un logiciel externe ( Motion pour vidéosurveillance ).
PC LAN avec client SIP
Xlite n° 100 10.0.0.13
Raspberry Pi 10.0.0.23 serveur Asterisk