PROJET : Synchronisation de flux multi-source avec SVC

Transcription

1 PROJET : Synchronisation de flux multi-source avec SVC Master 2 Ingénierie des Réseaux 2010/2011 Tuteur : HADJADJ-AOUL Yassine Groupe : COPY Cédric DANIEL Claude NDIAYE Babacar THEFAUT Jordann TRIHAN Aurélien

2 Sommaire I. INTRODUCTION... 3 A. Principes de SVC :... 3 B. Solution initiale :... 6 II. Déroulement du projet... 7 III. Evolution du projet... 8 A. Problème au niveau de l existant :... 8 B. Le choix des proxies : C. Problèmes logiciels : Pcap : SVC Modifier : IV. Solution actuelle : A. Principe de fonctionnement de l'application B. Détection des couches C. Synchronisation des couches V. Conclusion VI. Annexe A. Schéma d un échange entre le serveur et le client VII. Bibliographie VIII. Tables des illustrations Page 2

3 I. INTRODUCTION Avec l'évolution rapide des équipements mobiles, ces derniers possèdent maintenant de nombreuses interfaces connectées à des réseaux hétérogènes. Le format SVC (Scalable Video Coding) est une nouvelle technique d'encodage étendant le format H.264/MPEG4 AVC défini par JVT (Joint Video Team). Il permet d'encoder une vidéo en plusieurs sous-flux. Cette vidéo est maintenant composée d'un flux de base et de plusieurs flux d'amélioration. SVC offre donc la possibilité d'offrir aux utilisateurs un contenu échelonnable, s'adaptant aux capacités offertes par les terminaux et les réseaux auxquels ils sont connectés. A. Principes de SVC : Figure 1 : Principe de SVC Page 3

4 L'idée derrière SVC est de pouvoir diffuser un flux vidéo contenant un flux de base auquel peut s'ajouter divers flux d'amélioration. Charge ensuite à l'équipement récepteur de lire le flux de base et les flux d'amélioration qu'il peut supporter. Pour ce faire, trois types de scalabilité sont définis : la scalabilité spatiale qui offre différentes résolutions, la scalabilité temporelle qui échelonne la fréquence de l'affichage, la scalabilité qualitative qui permet d'offrir différentes qualités d'image. Jusqu'à présent, les distributeurs de contenu (ex : Youtube) étaient forcés d'encoder leurs vidéos dans différents formats et résolutions pour s'adapter aux besoins de leurs utilisateurs, leur imposant d'important besoins de stockage. SVC leur permettrait, alors de n'avoir qu'une seule vidéo dont l'utilisateur ne lirait que les parties voulues. Une fois la vidéo encodée en SVC, les serveurs de diffusion transmettent le flux en utilisant les protocoles RTSP 1, RTP 2 et RTCP 3. Le premier protocole est utilisé par le client pour contrôler le serveur de diffusion, depuis la requête de la vidéo en passant par des commandes telles que Play ou Pause. Ce protocole, s'appuyant sur TCP, transporte aussi vers le client toutes les informations nécessaires pour lire la vidéo et notamment grâce à SDP 4 qui permet de décrire les informations concernant la vidéo. Dans notre cas nous allons utiliser SDP avec l'extension définie dans la RFC 5583 qui permet de gérer les dépendances entre couche. RTCP est un protocole de contrôle de flux RTP. Nous l'utiliserons principalement pour son champ NTP 5 qui nous facilitera la synchronisation du contenu des paquets RTP. RTP est, quant à lui, le protocole qui va transporter la vidéo. Nous avons utilisé les travaux présents dans la draft de RFC : «RTP Payload Format for Scalable Video Coding» 6 qui permet de faire transiter SVC via RTP. La vidéo voit ses différentes couches découpées en «slices» ; ces slices vont être encapsulées dans des NAL (Network Abstraction Layer) qui seront alors transportées dans RTP. Une NAL ne transporte donc des données que d'une couche à la fois. RTP disposant de plusieurs moyens de transporter des NAL, nous nous baserons dans notre projet sur des paquets RTP de type SNU. 1 RTSP : Real Time Streaming Protocol, RFC RTP: Real Time Protocol, RFC RTCP: Real Time Control Protocol, RFC SDP: Session Description Protocol, RFC NTP: Network Time Protocol, RFC RTP Payload Format for Scalable Video Coding «draft-ietf-avt-rtp-svc-27» Page 4

5 Figure 2 : Structures possibles d un paquet RTP Actuellement, un seul flux RTP est utilisé pour transmettre l'ensemble de couches contenues dans les vidéos SVC. Le but de notre projet est donc de diffuser par le biais de plusieurs flux RTP passant par différentes interfaces les différentes couches d'une vidéo SVC. Le point important est la resynchronisation des différentes NAL transmises. Page 5

6 B. Solution initiale : Figure 3 : Schéma initialement prévu Initialement, l'idée était d'utiliser le serveur de diffusion Darwin Server, qui, d'après les documents fournis au premier semestre, était sensé pouvoir gérer la diffusion de couches de vidéo SVC par plusieurs interfaces. Darwin devait pour cela suivre le schéma vu précédemment : RTSP puis RTCP et RTP (cf. annexe 1). Ne nous restait plus, alors, qu'à modifier un lecteur multimédia pour assurer l'envoi correct des requêtes de demande de transmission par les interfaces souhaitées, puis la récupération des données et leur resynchronisation. Pour cette dernière, nous avions prévu d'utiliser l'algorithme de Seo présenté dans les documents rendus lors de la première phase 7. Celui-ci se base sur le paquet RTSP/SDP contenant le taux d'échantillonnage de la vidéo, sur le premier paquet RTCP (un par interface) contenant un champ NTP (Network Time Protocol) et émis avant la transmission des flux RTP. A l'aide des timestamps NTP et RTP, on resynchronise les différentes NAL contenues dans les paquets RTP, puis le lecteur multimédia lit la vidéo. Tout du moins, l'idée était là... 7 "Efficient Media Synchronization Mechanism for SVC Video Transport over IP Networks", K. Seo, S. Jung, J. Kim Page 6

7 II. Déroulement du projet Pour montrer le cheminement de notre projet et les difficultés rencontrées, nous avons décidé de commencer par vous montrer les différents diagrammes de Gantt du projet. Nous avions prévu débuter celui-ci début Janvier. Mais face aux contraintes d'emploi du temps, nous avons dû débuter le projet fin Janvier, diminuant ainsi de deux semaines nos prévisions. Figure 4 : Gantt provisionnel du projet Figure 5 : Gantt effectif du projet Page 7

8 III. Evolution du projet A. Problème au niveau de l existant : Pour commencer, nous avons cherché un serveur de diffusion transmettant des flux SVC. Nous avons ainsi passé quelques jours sur le serveur Darwin, pour nous apercevoir qu'au contraire de ce qui était dit dans les documents, il ne supporte pas la transmission de flux SVC. En effet, Darwin a besoin de fichier «hinted» (fichier avec des informations utilisées pour la transmission) pour pouvoir diffuser en mode RTSP. On peut créer ce type fichier avec des logiciels comme MPEG4IP, cependant aucun de ces logiciels ne supportent actuellement la norme SVC, on ne pouvait pas donc utiliser Darwin. Ensuite, nous nous sommes tournés vers VLC pour diffuser ce flux SVC, seulement, VLC ne supporte pas la norme SVC, et il est dans l'incapacité de diffuser ce type de flux. Pour pouvoir lire nos vidéos SVC, on nous a conseillé l'utilisation du lecteur multimédia MPlayer. Seulement, celui-ci ne supporte pas SVC nativement. Pour intégrer SVC à MPlayer, il nous a fallut y intégrer un module supplémentaire développé à l'ietr de Rennes, Open SVC Decoder. Ce module utilisait sa version propre de MPlayer que nous avons utilisé, et comme cette version ne supportant pas nativement RTSP, nous avons eu quelques difficultés à l'installer dû fait de dépendance non indiqué dans la documentation. Mais au final, MPlayer s'est imposé comme le lecteur utilisé par notre projet. Devant la difficulté de trouver un serveur de flux correspondant à nos besoins, il nous a été proposé de rejouer une capture de trame qui nous a été fournie. Nous nous avons alors choisi de poursuivre les recherches d'un serveur de diffusion, tout en nous penchant sur les possibilités de rejouer la capture par le biais de la bibliothèque Pcap. Cependant deux choses nous sont alors apparues : la capture fournie contenait une simulation de transmission SVC multicast, aucun des protocoles et échanges souhaités n'y étaient présents (cf. Figure 3). En outre, nous avons découvert le serveur de diffusion Live555 très proche de nos attentes (cf. Figure 4), la seule chose y manquant étant le paquet RTCP initial, qui permet la récupération du champ NTP nécessaire à la synchronisation, mais d'autres paquets RTCP sont régulièrement transmis. Page 8

9 Figure 6 : Capture fournie Figure 7 : Capture de l'échange de flux entre Live555 et MPlayer Néanmoins, ce serveur diffuse toutes les couches sur un même flux RTP, ce qui n'est pas le but de notre de notre projet. En effet nous voulons diffuser un flux contenant une couche de base sur une interface et un autre flux contenant une couche d'amélioration sur une autre interface. Page 9

10 B. Le choix des proxies : La modification des logiciels déjà existants étant relativement coûteux en temps, nous avons décidé de faire évoluer notre solution initiale vers le développement de proxies, côté serveur et côté client (cf. Figure 5). Le fonctionnement est détaillé au point 4 (Fonctionnement Actuelle). Notre première idée était d'utiliser Pcap, sur lequel nous avions déjà travaillé, pour capturer les paquets souhaités. Pcap est la bibliothèque C utilisée par beaucoup d'utilitaires de sécurité libres pour sniffer des paquets. Dans notre cas, sniffer des paquets n'est pas suffisant, encore faut-il les bloquer pour éviter que des connexions intempestives ne s'établissent. Nous avions donc pensé ajouter un système de firewall pour bloquer les paquets souhaités. Trop complexe et inadapté, nous avons rapidement changé d'avis. Nous nous sommes alors tournés vers la bibliothèque Netfilter_queue censée nous permettre d'analyser et bloquer les paquets que nous voulions cibler avant qu'ils ne soient traités par le système. Cette librairie étant elle aussi complexe, nous avons décidé de programmer nos proxies à l'aide de sockets, et avec toujours la solution de Firewall, ce qui permettra de rendre transparente l'utilisation du proxy pour le logiciel client. Page 10

11 C. Problèmes logiciels : 1. Pcap : L'intérêt de Pcap était de pouvoir filtrer précisément les paquets reçus et émis tel que le fait Wireshark avec son filtre d'affichage. Nous souhaitions pouvoir ainsi filtrer directement les paquets RTSP, RTP et RTCP. En réalité, les filtres Pcap sont en fait les filtres de capture de Wireshark, c'est à dire un filtrage jusqu'au niveau transport permettant de cibler des ports et les protocoles TCP/UDP mais pas de cibler simplement des protocoles de plus haut niveau. 2. SVC Modifier : Pour réaliser la détection des NAL et des couches auxquelles celles-ci appartiennent, on nous a fourni les sources d'une application Java nommée SVCModifier, programmée par un ingénieur de l'irisa. Cette application a pour but de simuler la perte de NAL au sein des différentes couches transmises. Prenant une vidéo H.264 SVC en entrée, cette application sort ainsi différentes vidéos avec des NAL aléatoirement manquantes. Figure 8 : Modèle avec proxies Le problème est que cette application ne prend absolument pas en compte la gestion des différentes couches, contrairement à ce que son objectif pourrait laisser penser. En outre, la structure des NAL y est relativement mal gérée. Page 11

12 Puisque nous avions commencé à regarder Pcap, nous avions décidé en premier lieu de l'utiliser pour capturer les paquets arrivants sur les proxies. Le problème posé par Pcap est qu'il n'agit qu'en tant que sniffer, et ne permet pas de bloquer les paquets observés. En outre, l'intérêt principal que nous attendions de Pcap est la possibilité d'y intégrer des filtres évolués pour n'observer que les protocoles RTP, RTCP et RTSP, tels qu'offert par Wireshark en filtres d'affichage. Seulement, Pcap n'offre que les possibilités de filtrage limitées offertes par le filtre de capture de Wireshark. Une solution envisagé pour pallier à ces problèmes est l'utilisation conjointe de la libraire netfilter_queue et tshark, ce qui nous permettrait de régler ces deux problèmes Le proxy Client reçoit des paquets RTP sur ses différentes interfaces. Ensuite il réalise la synchronisation de ces paquets pour le donner au Player.. Page 12

13 IV. Solution actuelle : A. Principe de fonctionnement de l'application Comme expliqué avant, nous avons utilisé des programmes faisant office de proxies afin de diminuer la complexité du projet. Ces deux programmes sont situés au niveau du serveur et du client. Le proxy côté client va gérer les connections demandées par le lecteur multimédia (MPlayer) avec comme direction le serveur de streaming grâce notamment à une règle Iptables qui redirige le flux RTSP vers le proxy. Ce programme va en extraire des informations clés comme l'adresse ou le port de réception du flux RTP afin de les modifier pour que cela fonctionnent correctement avec nos proxies. Une fois ces informations récupéré on retransmet le tout vers le proxy serveur, qui lui même va le retransmettre au serveur de diffusion. Une fois la transaction RTSP terminée, on va envoyer un paquet RTCP qui contient un champ NTP, qui sera utilisé plus tard lors de la transaction pour la synchronisation des deux flux. Le proxy serveur va pouvoir récupérer le flux RTP contenant les données vidéo, et extraire les différentes couches SVC. Pour cela on utilise un programme développé par nos soins et inspiré d OpenSVCDecoder, qui utilise les structures définis par ce logiciel. Une fois ces couches extraites on les redistribue via deux interfaces différentes à destination du proxy côté client. Le proxy côté client quant à lui récupère les deux flux et les synchronise via la méthode de Seo avec le NTP et le timestamp du flux. Une fois la synchronisation fait, on redirige le flux vers le serveur. Page 13

14 Figure 9 : Diagramme temporel d échange entre le proxy serveur et le proxy client Voici un diagramme temporel présentant plus en détail les échanges entre les proxies client et serveur. B. Détection des couches H.264/SVC étant une modification de H.264/AVC 8, les en-têtes des NAL ont maintenant une taille de un ou quatre octets. De base, l'en-tête des NAL est composé d'un octet, contenant sur cinq bits un champ indiquant le type du NAL. Ce champ Type possédait un certain nombre de valeurs possibles allant de 0 à 12 dans la norme AVC, mais étant étendu jusqu'à 31 dans la norme SVC. Il est donc assez simple de reconnaître un NAL SVC d'un NAL AVC. Les NAL SVC contiennent justement un en-tête étendu sur trois octets supplémentaires. Ceux-ci contiennent trois champs qui nous intéressent. Ces champs nommés dependency_id, quality_id, temporal_id, nous permettent respectivement de connaître les couches spatiales, de qualité, et de fréquence d'image utilisées. 8 Page 14

15 L'ensemble des couches disponibles dans une vidéo SVC peut donc être représenté sous la forme d'une matrice 3*3. Le draft de l'ietf concernant le transport de SVC dans RTP nous explique qu'il est possible de combiner les paramètres dependency_id et quality_id en une seule valeur : le DQId. Celui-ci est égal à ((dependency id * 16) + quality id). Figure 10 : Représentation des couches La détection des couches peut donc se faire simplement en utilisant les paramètres DQId et temporal_id. Ainsi, sur le schéma ci-dessus, on peut voir la couche de base (0,0) en vert, le premier niveau d'amélioration en rose et le troisième en bleu. Page 15

16 C. Synchronisation des couches La synchronisation des flux RTP s'effectue grâce aux temps absolus des premiers paquets RTCP (qui contiennent un champ NTP). En effet on calcule le temps absolu à partir des timestamps RTP et RTCP entre le paquet courant et le tout premier paquet RTP. Les formules ci dessous permettent de calculer le temps absolu pour un flux. : Temps absolue pour un paquet RTP : Le timestamp contenu dans le paquet RTCP. : Le bitrate qui est présent dans le SDP. : La différence de timestamps entre deux paquets RTP. La même opération est réalisée sur les deux flux vidéo. La synchronisation des deux flux est déterminée par une valeur seuil. Cette valeur seuil est calculée grâce aux bitrates et aux timestamps contenu dans le paquet RTCP : Page 16

17 V. Conclusion Ce projet a été une étude intéressante car nous avons pu travailler sur des problématiques d actualité qui seront probablement très utilisées dans un futur proche (lié à l évolution technologique). Les futures implémentations seront probablement déployées par de grands groupes industriels afin de répondre à des problèmes de stockage de données mais aussi à des contraintes de mobilités. Dans le cadre de notre formation, ce projet nous a permis d observer les problématiques liées au format et aux traitements des paquets de transport de la vidéo. Comme nous l avons exposé précédemment, ce projet, d'une complexité importante, nous aura pris beaucoup de temps pour les activités de recherche. Les prévisions faites lors de l'étude bibliographique se sont révélées erronées. C'est en partie dû au fait que les ressources que nous avions supposés disponibles ne l'étaient pas (par exemple le serveur Darwin). De plus il y a peu de travaux et de documentation autour du sujet, et la prise en main des différents outils a décalé les prévisions du planning initial. Nous avons ainsi essayé et testé de nombreuses librairies, et ce travail ne s'est pas forcément révélé fructueux. Cependant nous avons tout de même pu produire une partie de l architecture qui s approche du résultat attendu. Nous allons maintenant employer le temps restant pour terminer la solution. Page 17

18 VI. Annexe A. Schéma d un échange entre le serveur et le client Page 18

19 VII. Bibliographie Libcap - Netfilter_queue - RTP Payload Format for Scalable Video Coding - RFC RTSP - RTP - RTCP - SVC - SDP - NTP - MPlayer - OpenSVCDecoder - Live Darwin - «Multi-interface streaming of scalable video» «Efficient Media Synchronization Mechanism for SVC video Transport over IP Networks» - MPEG4IP - Page 19

20 VIII. Tables des illustrations Figure 1 : Principe de SVC... 3 Figure 2 : Structure d un paquet RTP... 5 Figure 3 : Schéma initialement prévu... 6 Figure 4 : Gantt provisionnel du projet... 7 Figure 5 : Gantt effectif du projet... 7 Figure 6 : Capture fournie... 9 Figure 7 : Capture de l'échange de flux entre Live555 et MPlayer... 9 Figure 8 : Modèle avec proxies Figure 9 : Diagramme temporel d échange entre le proxy serveur et le proxy client Figure 10 : Représentation des couches Page 20