Soutenance mémoire
Diffusion des données sur le réseau – Buffering
Cela requiert un accès réseau sur le lieu de l’acquisition, doté de capacité suffisante pour évacuer en temps réel les informations vers le serveur de streaming (item suivant). Ce dispositif est doublé par sécurité, d’un dispositif de stockage sur disque qui permettra de plus ensuite la diffusion différée et en vidéo à la demande de l’événement.
Le fichier audio ou le conteneur vidéo est ensuite placé sur le serveur qui, à chaque requête d’un internaute, duplique le fichier demandé et le délivre sous la forme d’un flux continu de données (petits paquets de données marqués temporellement afin d’être réordonnancés de manière
Cohérente par le client).
C’est le serveur de streaming qui se charge de faire correspondre une URL à un flux temps-réel (direct) ou à un fichier préenregistré.
Protocoles
Il existe actuellement trois protocoles qui permettent de faire du streaming. Les deux premiers, HTTP et FTP, sont des protocoles de transfert de fichier. On peut néanmoins parler de streaming dans la mesure où le flux peut être affiché au fur et à mesure du téléchargement. Ceci dit, du fait de leurs mécanismes de contrôle d’erreurs qui ont tendance à ralentir la transmission ou à décaler le son et la vidéo, on considère que c’est RTP ou Real Time Protocol qui permet de faire du vrai streaming c’est-à-dire de la diffusion de contenu en temps réel.
Le Real Time Transport Protocol, RTP
RTP (RFC 3350) est un protocole basé sur IP fournissant un support pour le transport des données en temps réel comme la vidéo. Les services fournis par RTP consistent en la reconstruction temporelle, la détection de pertes, l’identification du contenu et la synchronisation entre médias. RTP a été conçu à l’origine pour des données temps réel multicast, mais il peut aussi être utilisé pour faire de l’unicast. Il peut également être utilisé pour le transport dans une seule direction comme la VoD (Video On Demand) mais aussi pour des applications interactives telles que la téléphonie à travers Internet. RTP est conçu pour travailler en conjonction avec le protocole RTCP afin de permettre la mesure des performances et le contrôle de la session en cours. Typiquement, RTP est exécuté au-dessus d’UDP (Figure 2.6).
Les blocs de données, générés par la sortie de l’application multimédia, sont encapsulés dans des paquets RTP, puis chaque paquet RTP est à son tour encapsulé dans un segment UDP. Considérons l’exemple d’une application téléphonique sur RTP. Supposons que la source soit encodée au format PCM à 64 kb/s et que les échantillons soient disponibles toutes les 20 ms.
L’application serveur ajoute à chaque bloc un entête RTP qui inclut le type de codage, un numéro de séquence et une estampille de temps. L’en-tête et le bloc de données forment le paquet RTP. Ce paquet est ensuite envoyé sur un socket UDP où il sera empaqueté dans un paquet UDP. Du coté client, c’est un paquet RTP qui est reçu via le socket.
L’application cliente peut extraire le bloc de données et utiliser l’en-tête pour le décoder puis le jouer correctement [48].
La place de RTP dans la couche réseau RTP permet d’associer un flot de paquets à chaque type de source, par exemple un flot pour un micro et un autre pour une caméra. Dans ce cas, pour une vidéoconférence à deux, 4 flots seront créés, 2 flots audio et 2 flots vidéo dans chaque sens. Cependant dans de nombreux formats de compression dont MPEG1 et MPEG2, les images et le son sont mélangés. Pour de tels cas, seul un flot est créé dans chaque sens. RTP est notablement compatible avec les réseaux multicast.
L’entête RTP
Le format de l’en-tête RTP est comme suit :
Les deux premiers octets sont présents dans tous les paquets RTP, tandis que l’identifiant de la liste CSRC est inséré seulement par le mixer.
L’entête RTP comporte les champs suivants :
Version (V) : 2 bits, indique la version du protocole (V=2).
Padding (P) : 1 bit, si P est égal à 1, le paquet contient des octets additionnels de bourrage.
extension (X) : 1 bit, si X=1 l’entête fixe est suivie par une extension.
CSRC count (CC) : 4 bits, contient le nombre de CSRC identifies qui suivent l’entête.
marker (M) : 1 bit, son interprétation est définie par un profil d’application.
payload type (PT) : 7 bits, identifie le format des données contenues dans le paquet RTP. Un profil définit de façon statique la correspondance entre un type de données et le format des données (voir RFC 1890).
sequence number : 16 bits, sa valeur initiale est aléatoire et il est incrémenté de 1 pour chaque paquet envoyé.
timestamp : 32 bits, reflète l’instant où le premier octet du paquet RTP a été échantillonné. Cet instant doit être dérivé d’une horloge qui augmente de façon monotone et linéaire dans le temps pour permettre la synchronisation et le calcul de la gigue à la destination.
SSRC: 32 bits, identifie de manière unique la source.
BELMELIANI Imane Ammaria 48
Le champ CSRC: 32 bits, identifie les sources (SSRC) qui ont contribué à l’obtention des données contenues dans le paquet.
Le nombre d’identificateurs est donné dans le champ CC RTP est conçu pour travailler en conjonction avec le protocole RTCP afin de permettre d’obtenir des feed-back concernant la qualité de la transmission et des informations au sujet des participants pour la session à réaliser [51].
Le Real Time Control Protocol, RTCP
RTCP (RFC 1889 et 1890) est un protocole de contrôle conçu pour travailler en conjonction avec le protocole RTP. Il est basé sur la transmission périodique des paquets de contrôle à tous les participants à la session, utilisant le même mécanisme de distribution que les paquets de données. Les fonctions assurées par ce protocole sont :
Fournir un feedback (des informations sur la qualité du service délivré) à chaque participant dans la session RTP qui peut être utilisé pour contrôler la session.
Fournir une identification persistante de niveau de transport : car l’identifiant SSRC peut changer si un conflit est découvert ou un programme est remis en marche, RTCP transporte donc un champ « CNAME » (Canonical NAME) ou nom permanent qui permet d’identifier les provenances des flux.
Les deux premières fonctions exigent que tous les participants envoient des paquets de RTCP. En ayant chaque participant envoyez ses paquets de contrôle à tous les autres, chacun peut indépendamment observer le nombre de participants.
Ce nombre est utilisé pour calculer le taux auquel les paquets sont envoyés, pour permettre le calibrage de la fréquence d’émission en fonction de ces paquets RTCP reçus.
Fonction optionnelle permettant le contrôle des participants : les paquets RTCP sont envoyés périodiquement parmi les participants. Quand le nombre de participants augmente (ce qui peut être le cas dans une session multicast), il est nécessaire de limiter les informations de contrôle pour éviter que le trafic de contrôle ne vienne saturer les ressources du réseau [44].
Real Time Streaming Protocol (RTSP)
RTSP est un protocole de niveau applicatif, conçu pour diffuser efficacement des données audio-visuelles pour un grand nombre de personnes.
BELMELIANI Imane Ammaria 49
Comme une télécommande de magnétoscope, le protocole RTSP fournit un mécanisme qui permet aux utilisateurs de demander spécifiquement des données d’un ou de plusieurs serveurs, ainsi qu’un type de transfert spécifique et une destination de transmission des données. Le demandeur de flux peut ainsi lancer, arrêter et mettre en pause la transmission des données. Il est de plus possible d’obtenir l’accès direct à différents paquets de données (c’est impossible dans le cas d’une transmission en direct).
Le protocole RTSP a été conjointement développé par Real Networks, Netscape et Columbia University au sein du groupe MMUSIC de l’IETF (Internet Engineering Task Force).
De même que H.323 (standard promu par l’UIT-T pour les applications de visioconférence), RTSP utilise RTP pour former les paquets contenant les données multimédia. Cependant, alors que H.323 est conçu pour la vidéo conférence, et donc pour un nombre modéré de personnes, RTSP est lui conçu pour diffuser efficacement des données audiovisuelles à un grand nombre de personnes [52].
Les principes de RTSP
i. Un protocole temps réel selon un modèle client/serveur : RTSP est un protocole temps réel qui a été conçu pour transférer et contrôler un ou plusieurs flux synchronisés d’objets média continus comme la vidéo et l’audio.
Le protocole est fondé sur le modèle client/serveur. Les commandes de contrôle de la présentation d’un objet média (lecture, pause, …) sont traduites sous forme de requêtes d’accès RTSP envoyées par le client et exécutées par le serveur.
ii. RTSP dépassant les limites de HTTP : RTSP a été créé car on ne pouvait se satisfaire de HTTP, celui-ci étant fait pour le transfert de page Web n’intégrant pas des contraintes de temps. Cependant RTSP hérite de toute la syntaxe de HTTP, de ses mécanismes de sécurité et de ses procédures d’extension.
iii. Un protocole à états : RTSP est un protocole avec états qui utilise la notion de session. Cette caractéristique est importante pour effectuer le transfert de médias continus. En effet, la présentation d’objets de type média continu est caractérisée par une évolution entre différents états de présentation, comme les états Unmapped, Mapped, Active, Terminated et Suspended. L’évolution des transferts de données effectués au moyen du protocole RTSP est décrite par une machine d’états associée au client et au serveur. Le serveur change d’état quand il reçoit une requête du client, et le client change d’état quand il envoie une requête au serveur.
Les principales méthodes sont :
DESCRIBE : Elle est utilisée par le client pour récupérer la description d’une présentation ou d’un objet média, identifié par un URI, sur un serveur RTSP.
SETUP : Elle est utilisée par le client pour spécifier au serveur les paramètres de transport du flot média, comme par exemple le type de protocole de transport (RTP), le mode de transport (point à point ou multipoint) et le numéro du port de communication.
PLAY : Elle signale au serveur qu’il peut commencer à envoyer les données via le mécanisme spécifié dans la méthode SETUP. Elle permet également de jouer un ou plusieurs sous-intervalles de la durée d’un objet média, par exemple jouer une vidéo à partir de la 10ème seconde jusqu’à la 20ème seconde.
PAUSE : Elle est utilisée par le client pour demander au serveur d’interrompre temporairement le transfert du flux média. Le client peut reprendre la transmission du flux en envoyant la requête PLAY au serveur.
TEARDOWN : Elle est utilisée par le client pour demander au serveur d’arrêter définitivement le transfert du flux média [52].
Le RTMP (Real Time Messaging Protocol)
Le RTMP (Real Time Messaging Protocol) est un système pour la livraison de contenu média à la demande et en direct pour les applications Adobe Flash (comme le JW Player). Le RTMP prend en charge la vidéo aux formats FLV et H.264 (MP4/MOV/F4V) et l’audio aux formats MP3 et AAC (M4A). Le RTMP offre plusieurs avantages sur les téléchargements vidéo HTTP standard :
Le RTMP permet le streaming en direct – les spectateurs peuvent visionner votre vidéo au moment même où elle est enregistrée.
Avec le RTMP, les spectateurs peuvent sauter directement vers des parties non encore téléchargées d’une vidéo. C’est particulièrement utile pour le contenu long (> 10 minutes).
Les vidéos transmises via RTMP (et son équivalent chiffré, le RTMPE) sont plus difficiles à dérober que les vidéos transmises via HTTP standard. L’une des fonctionnalités uniques du RTMP tient à sa capacité à réaliser du streaming en direct, par exemple avec des présentations, des concerts ou des événements sportifs. En plus du lecteur et d’un serveur RTMP, il faut alors aussi un petit outil pour ingérer (uploader) la vidéo en direct sur le serveur. Il existe de nombreux outils pour cela, mais le plus simple à utiliser est le logiciel libre Flash Live Media Encoder [54].
Domaines d’application
Partout où la communication électronique est employée, les demandes de streaming sont sans fin. Streaming peut être délivré comme paquet complet de vidéo de la programmation linéaire, comme service d’abonnement, ou comme pay-per-view (PPV). Il peut faire partie d’un site Web interactif.
|
Table des matières
Introduction générale
Premier Chapitre: Contexte de recherche
I.1 − Introduction
I.2 − Télémédecine
1.2.1 − Définition
1.2.2 − Le différent domaine d’application de la télémédecine
1.2.2.1 − Téléconsultation
1.2.2.2 − Téléassistance
1.2.2.3 – Télé-chirurgie
1.2.2.4 − Téléformation
1.2.2.5 − Télé expertise
1.2.2.6− Télésurveillance
1.2.3 − A quels besoins répond la télémédecine ?
1.2.4 − Les apports et enjeux de la télémédecine
1.2.5 − Les freins au développement
1.3 – M-Heath
1.3.1 – Principe
A – Les capteurs sans fils
A.1 – Les réseaux de capteurs sans fil
A.2 – Réseaux de capteurs corporels (BAN)
A.4– WBAN (Wireless Body Area Network)
B – Organisme, technologies et standards existants
B.1 – Réseaux sans fil
BELMELIANI Imane Ammaria 9
B.1.1 – Bluetooth (IEEE 802.15.1)
B.1.2 – ZigBee (IEEE 802.15.4)
B.1.3– Wi‐Fi (ou IEEE 802.11)
B.2 – Réseaux d’accès radio mobiles
B.2.1 – GSM (2G)
B.2.2– GPRS
B.2.3 – EDGE
B.2.4 − UMTS
B.2.5 − HSDPA
B.2.6 − Technologie 4G
1.4 − Conclusion
Second Chapitre :Le streaming vidéo live
2.1 − Introduction
2.2 − Streaming vidéo
2.2.1 − Définition
2.2.2 − Types
2.2. 3 − Mode de diffusion
2.2.3.1 − Le broadcast
2.2.3.2 − Multicast
2.2.3.3 − Unicast
2.2.3.4 − Anycast
2.3 − Architecture du système de streaming
2.3.1− L’aquisition
2.3.2 − Encodage
2.3.3 − Diffusion des données sur le réseau – Buffering
2.4− Protocoles
2.4.1 – Le Real Time Transport Protocol, RTP
2.4.1.1– L’entête RTP
2.4.2– Le Real Time Control Protocol, RTCP
2.4.3 – Real Time Streaming Protocol (RTSP)
2.4.3.1 – Les principes de RTSP
i – Un protocole temps réel selon un modèle client/serveur
ii – RTSP dépassant les limites de http
iii – Un protocole à états
2.4.4 – Le RTMP (Real Time Messaging Protocol)
2.5 – Domaines d’application
2.5.1 – Streaming vidéo à la demande
2.5.2 – La vidéoconférence
2.5.3– Streaming pair-à-pair vidéo
2.6 – Avantages du streaming vidéo
2.7 – Marché et perspectives
2.8 – Conclusion
Troisième chapitre :Service mobile de visioconférence entre les professionnels de santé
3.1– Objectif
3.2 –Etude technique
3.2.1– Données de base
3.2.2− Rédaction de Cahier de charge
3.2.3 − Fonctionnalités et contribution de notre application
3.3 − Bilan d’analyse
3.3.1 – Outils de développements
3.3.1.1 − SDK Android
3.3.1.2− Eclipse
3.3.1.3 – Wowza Media Engine
3.3.1.4 – WAMP server
3.3.2 – Protocoles
3.3.3– Support des réseaux
3.3.3.1 Technologie d’accès mobile
3.3.3.2– Technologie Internet
3.3.4 – Système des terminaux
3.4 – l’enchainement des étapes de projets en génerale
3.4.1 – Etablissement de la connexion
3.4.2– Le traitement de flux vidéo
3.4.3 –La transmission des données
3.5 – les étapes suivis pour la réalisation de projets
3.5.1 – Installation et configuration de Wowza Media Engine
3.5.2 – Creation de l’application web
3.6 – plateforme proposé pour le streaming vidéo live
3.6.1 – Présentation des interfaces de l’application
3.6.2 – Exécution de l’application
4.6-Conclusion
Conclusion générale et perspectives
Bibliographies & Références
Télécharger le rapport complet
