FR3034610A1

FR3034610A1 - Systeme de diffusion de contenus audio et/ou video par un reseau wifi local, et appareils mettant en œuvre le procede

Info

Publication number: FR3034610A1
Application number: FR1552669A
Authority: FR
Inventors: Frederic Beauchamp
Original assignee: Telediffusion de France ets Public de Diffusion
Current assignee: Telediffusion de France ets Public de Diffusion
Priority date: 2015-03-30
Filing date: 2015-03-30
Publication date: 2016-10-07
Anticipated expiration: 2035-03-30
Also published as: WO2016156386A1; FR3034610B1

Abstract

L'invention concerne un procédé de transmission d'un contenu audio et/ou vidéo linéaire d'un serveur de diffusion vers une pluralité de terminaux en utilisant le réseau Wifi. Dans un premier temps, le serveur de diffusion émet vers un premier terminal le contenu demandé sous la forme d'un flux de paquets de données. Puis, un second terminal émet une requête vers le serveur de diffusion pour recevoir par le réseau Wifi ce même contenu, la réception de cette requête déclenche la transmission par le serveur de diffusion d'un message identifiant le premier terminal comme terminal émetteur de ce contenu. Le second terminal émet alors une requête de réception de ce contenu vers le premier terminal pour recevoir ledit contenu à travers une liaison pair à pair. De cette manière, une partie de la charge de gestion des transmissions de contenus diffusés est transférée au niveau des terminaux du réseau et ainsi les ressources du serveur Wifi sont moins utilisées.

Description

1 Système de diffusion de contenus audio et/ou vidéo par un réseau Wifi local, et appareils mettant en oeuvre le procédé. 1. Domaine de l'invention L'invention concerne un procédé de diffusion d'un flux de services émis par une tête de réseau à destination d'une pluralité de terminaux, le flux de services transporte un contenu audio et/ou vidéo découpé en paquets de données et destinés à être reproduit au niveau des terminaux. La présente invention concerne plus particulièrement le fait que les différents paquets sont émis par un serveur de streaming vers chaque terminal à travers un réseau Wifi local. 2. Art antérieur De nos jours, Il existe de nombreux moyens de réaliser la transmission de contenus numériques, parmi lesquels les techniques se basant sur les standards issus des consortiums DVB (de l'anglais « Digital Video Broadcast » pour « Diffusion Video Numérique »). D'autres techniques de transmission de contenus sont aussi utilisées avec des réseaux fonctionnant à l'aide du protocole IP (de l'Anglais « Internet Protocol » pour « Protocole Internet »). Ces contenus sont transmis à l'aide d'un support matériel (un câble par exemple) ou immatériel (un réseau sans fil, généralement radio). De nombreuses personnes utilisent leur terminal pour recevoir en temps réel des services tels que des chaînes de télévision, des informations météo ou de trafic routier, les cotations boursières, l'état des arrivées de trains, ... Ces terminaux dialoguent très généralement par Wifi qui est un standard largement répandu de nos jours. En sélectionnant un service délivrant un contenu linéaire, c'est à dire destiné à être reproduit en temps réel ou avec un très léger retard dès sa réception, l'utilisateur demande à son terminal d'établir une liaison en unicast avec un serveur de streaming via un point d'accès Wifi détecté à 3034610 2 proximité. Le service référence le contenu audio et/ou vidéo à transmettre en temps réel et le terminal reçoit les paquets transportant ce contenu. Dans certains cas, de nombreux terminaux sont présents dans une zone gérée par un serveur de streaming. C'est notamment le cas où des voyageurs se 5 retrouvent dans un même véhicule, un train, un car ou un bateau, ou encore dans une salle d'attente ou une salle de spectacle, par exemple. La liste des services disponibles étant limitée, un certain nombre de terminaux se connectent au serveur de streaming pour recevoir le même contenu. Pour épargner au serveur de streaming la gestion de nombreuses 10 liaisons unicast, une solution simple consiste à transmettre vers les terminaux les contenus en multicast sur le réseau Wifi. Cependant, il s'avère que ce réseau supporte mal un tel mode de communication, et on constate de fréquentes pertes de données. Il existe donc un réel besoin de mettre en oeuvre un moyen de diffusion 15 de contenus audio et/ou vidéo linéaires qui utilise le support du réseau Wifi et qui consomme un minimum des ressources du serveur de streaming. 3. Objectifs de l'invention La présente invention apporte une solution qui ne présente pas les 20 inconvénients décrits plus haut, tout en proposant les avantages listés ci- dessus. La solution proposée permet de diminuer la charge de travail du serveur de streaming en la reportant au niveau des terminaux. 4. Exposé de l'invention 25 La présente invention propose un procédé de transmission d'un contenu linéaire d'un serveur de diffusion vers une pluralité de terminaux en utilisant le réseau Wifi. Le procédé comporte une étape préalable de réception dudit contenu par le serveur de diffusion à l'aide d'un réseau de diffusion une étape d'émission par le serveur de diffusion vers un premier terminal dudit contenu sous la forme d'un flux de paquets de données, une étape d'émission par un 3034610 3 second terminal d'une requête vers le serveur de diffusion pour recevoir, par le réseau Wifi, ce même contenu, ladite étape d'émission de ladite requête déclenchant une étape de transmission, par le serveur de diffusion, d'un message identifiant le premier terminal comme terminal émetteur de ce 5 contenu, le second terminal émettant alors une requête de réception de ce contenu vers le premier terminal pour recevoir ledit contenu à travers une liaison pair à pair. De cette manière, le serveur de diffusion ne gère pas l'ensemble des flux de transmission de contenus linéaires mais en confie une partie aux terminaux 10 connectés au réseau Wifi, libérant ainsi des ressources du serveur de diffusion qui peut les utiliser pour d'autres taches. Selon un premier mode de réalisation, le procédé comporte une étape de gestion d'une liste au niveau du serveur de diffusion, ladite liste associant un contenu donné à au moins un identifiant d'un terminal qui reçoit du serveur de 15 diffusion ce contenu. L'étape de transmission d'un message, par le serveur de diffusion, en réponse à une requête émise par le second terminal pour recevoir ce contenu, comporte une sous-étape de sélection par le serveur de diffusion sélectionne dans ladite liste un identifiant d'un terminal qui est associé au contenu demandé.

20 De cette manière, le serveur de diffusion détermine rapidement les terminaux susceptibles de transmettre le contenu demandé. Selon un autre mode de réalisation, le procédé comporte une étape de transmission d'un message d'un terminal vers le serveur de diffusion indiquant que ce terminal n'a pas les ressources nécessaires pour transmettre à un autre 25 terminal le contenu actuellement reçu et associé dans la liste, cette information étant introduite dans la liste gérée par le serveur de diffusion, un tel terminal n'étant pas sélectionné par le serveur de diffusion pour transmettre le contenu à un autre terminal. De cette manière, le serveur de diffusion n'indique pas à un terminal un 30 identifiant d'un terminal qui reçoit effectivement le contenu demandé mais qui 3034610 4 n'a pas les ressources nécessaires pour le retransmettre. Selon un autre mode de réalisation, le procédé comporte une étape de transmission d'un message d'un terminal vers le serveur de diffusion indiquant que ce terminal possède les ressources nécessaires pour transmettre à un autre 5 terminal une pluralité de contenus actuellement reçus et associés dans la liste, cette information étant introduite dans la liste gérée par le serveur de diffusion, un tel terminal étant sélectionné par le serveur de diffusion pour transmettre l'un des contenus à un autre terminal. De cette manière, le procédé gère des terminaux ayant les ressources 10 nécessaires pour retransmettre plusieurs contenus en même temps. Selon un autre mode de réalisation, le procédé comporte les étapes suivantes : - émission par un terminal demandeur d'un contenu vers un terminal dit « précédent» d'une requête pour recevoir ce contenu par une liaison pair à 15 pair, - émission par le terminal précédent en réponse à la requête d'un message indiquant de demander ce contenu à un terminal dit « suivant », le terminal précédent transmettant déjà ce contenu au terminal suivant, - réitération des deux étapes précédentes, le terminal suivant devenant 20 le terminal précédent, jusqu'à ce qu'un terminal suivant transmette ledit contenu au terminal demandeur. De cette manière, de véritables chaînes de transmission de contenus se constituent pour diffuser les différents contenus à l'aide de liaison pair à pair. La gestion dynamique des liaisons pair à pair entre terminaux pour transmettre 25 le contenu s'effectue par les terminaux eux-mêmes et non par le serveur de diffusion. Selon un autre mode de réalisation, le procédé comporte une étape de comptage des itérations, les étapes suivantes sont déclenchées lorsque le nombre d'itérations atteint une valeur maximale déterminée : 30 - arrêt des itérations, 3034610 5 - recherche par le serveur de diffusion d'un autre premier terminal recevant le contenu du serveur, - émission par le terminal demandeur d'une requête de réception de ce contenu vers cet autre premier terminal pour lui transmettre ledit contenu.

5 De cette manière, le serveur de diffusion gère les chaînes de terminaux transmettant un même contenu et stoppe les itérations au sein d'une chaîne lorsque celle-ci comporte un nombre maximal de terminaux. Selon un autre mode de réalisation, le message transmis par le serveur de diffusion en réponse à une requête pour recevoir par le réseau Wifi un 10 contenu comporte une liste de plusieurs terminaux identifiés comme terminaux recevant ledit contenu, le terminal demandeur d'un contenu s'adressant à un premier terminal de la liste pour recevoir ce contenu et explorant une succession de terminaux à partir de ce premier terminal de la liste par des liaisons pair à pair, une nouvelle requête de réception de ce contenu vers un 15 autre premier terminal de la liste étant déclenchée par le terminal demandeur lorsque le nombre d'itérations atteint une valeur maximale déterminée sans avoir pu recevoir le contenu. De cette manière, chaque terminal demandeur gère sa propre chaîne de terminaux pour recevoir le contenu demandé et ne mobilise pas les ressources du serveur de diffusion pour assurer cette gestion.

20 Selon un autre mode de réalisation, le terminal demandeur émet une requête pour recevoir directement du serveur de diffusion le contenu demandé lorsqu'aucun terminal des successions de terminaux commençant par les premiers terminaux de la liste transmise dans le message, n'est disponible pour transmettre le contenu demandé. De cette manière, même si aucun terminal 25 recevant déjà le contenu demandé n'est disponible, le serveur de diffusion peut toujours directement transmettre ce contenu. Selon un autre aspect, l'invention concerne un serveur de diffusion recevant par un moyen de réception des contenus linéaires à travers un réseau de diffusion et un moyen de communication pour émettre et recevoir des 30 messages vers une pluralité de terminaux à travers un point d'accès Wifi. Le 3034610 6 moyen de communication émet vers un premier terminal et à sa demande un contenu sous la forme d'un flux de paquets de données. Le moyen de communication reçoit d'un second terminal une requête pour recevoir ce même contenu par le réseau Wifi, la réception de cette requête déclenchant la 5 transmission par ledit moyen de communication d'un message identifiant le premier terminal comme appareil émetteur de ce contenu. Selon un autre aspect, l'invention concerne un terminal destiné à recevoir au moins un contenu audio et/ou vidéo linéaire provenant d'un réseau de diffusion comportant au moins une mémoire de stockage de données de l'au 10 moins un contenu et un moyen de communication par Wifi pour émettre et recevoir des messages à travers un point d'accès Wifi. Le moyen de communication émet vers un serveur de diffusion une requête pour recevoir l'au moins un contenu sous la forme d'un flux de paquets de données. Le moyen de communication reçoit en réponse lesdits paquets de données, les 15 dits paquets étant stockés dans la mémoire de données, ledit moyen recevant ultérieurement une requête provenant d'un autre terminal pour transmettre à cet autre terminal lesdits paquets de données précédemment stockés en mémoire, ledit moyen émettant en réponse lesdits paquets extraits de la mémoire de données.

20 Selon un autre aspect, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communications et/ou stocké sur un support lisible par ordinateur et/ou exécutable par une unité centrale. Ledit produit programme d'ordinateur comprend des instructions de programme pour la mise en oeuvre d'au moins une étape du procédé de 25 transmission d'un contenu tel que décrit précédemment et selon l'un quelconque des modes de réalisation. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus 30 clairement à la lecture de la description suivante d'un mode de réalisation 3034610 7 particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 présente un exemple des principaux éléments composant un système pour diffuser des services à des terminaux, 5 - la figure 2 représente un exemple d'ordinogramme des principales étapes pour la mise en oeuvre d'un procédé selon un mode de réalisation, - la figure 3 représente un premier état des flux de communication entre des terminaux et le serveur de streaming à un instant donné, - la figure 4 représente un second état des flux de communication entre 10 des terminaux et le serveur de streaming à un autre instant donné, - la figure 5 illustre le contenu d'un tableau pour la gestion de la diffusion de services au sein d'un réseau Wifi. 6. Description d'un mode de réalisation de l'invention 15 6.1 Principe général L'invention concerne un procédé de transmission d'un contenu linéaire d'un serveur de streaming vers une pluralité de terminaux en utilisant le réseau Wifi. Dans un premier temps, le serveur de streaming émet vers un premier terminal le contenu demandé sous la forme d'un flux de paquets de données.

20 Puis, un second terminal émet une requête vers le serveur de streaming pour recevoir par le réseau Wifi ce même contenu, la réception de cette requête déclenchant la transmission par le serveur de streaming d'un message identifiant le premier terminal comme appareil émetteur de ce contenu. Le second appareil émet alors une requête de réception de ce contenu vers le 25 premier terminal pour recevoir ledit contenu par ce premier terminal à travers une liaison pair à pair, et non plus par le serveur de streaming. De cette manière, une partie de la charge de gestion des transmissions de contenus diffusés est transférée au niveau des terminaux du réseau et ainsi les ressources du serveur de streaming sont moins utilisées. 30 3034610 8 6.2 Mode particulier de réalisation Le système de diffusion illustré par la Fig. 1 comporte notamment un encodeur HLS 1 qui reçoit une pluralité de flux transportant des services. Ces services sont par exemple des chaines audio et/ou vidéo, des applications (de 5 télé-achat, d'information trafic routier, des bulletins météorologiques.....). Ces services fournissent des contenus linéaires, c'est à dire, soumis à la contrainte temporelle d'être reproduits en quasi temps réel, le terme « quasi » signifiant qu'il peut exister un léger décalage temporel entre l'émission par la tête de réseau et la reproduction au niveau du terminal, un tel décalage étant 10 généralement de quelques secondes, voire quelques dizaines de secondes. Les données des services sont présentées à l'entrée de l'encodeur HLS 1 (acronyme de « HTTP Live Streaming ») qui segmente le contenu audio et/ou vidéo en une succession de paquets (ou « chunk » - cette appellation sera ensuite utilisée dans le reste du document). Les techniques de segmentation sont connues en 15 soi, on peut citer par exemple les algorithmes HLS, DASH ou encore, Smooth Streaming. Chaque chunk dispose d'une structure de données de fichier contenant une charge utile (par exemple, les données audio et /ou vidéo, avec les données synchronisant leur reproduction- des « timestamps » typiquement), une référence, et un identifiant de source (typiquement 20 l'identifiant du service associé). Dans le cas d'un contenu audio et/ou vidéo, le flux est généralement de type MPEG. Chaque chunk contient une succession de paquets constituant un flux audio et/ou vidéo. La durée de reproduction des données audio et/ou vidéo de chaque chunk d'un même service est la même, typiquement quelques 25 secondes. Chaque chunk est organisé en un fichier contenant un ensemble de paquets de données audio et/ou vidéo, et est identifié chronologiquement par une référence. Ayant une nature de fichiers indépendants, les chunks peuvent être transmis selon des chemins divers et reçus non-chronologiquement par le terminal. La référence de chaque chunk permet de reconstituer le 30 séquencement des données et de reproduire correctement le contenu.

3034610 9 Les contenus segmentés des services sont transmis à un serveur PUSH 2 pour être diffusés vers au moins un serveur de diffusion 3, qui est la traduction française de « serveur de streaming » , c'est le terme anglo-saxon qui sera par la suite utilisé. L'encodeur HLS 1 et le serveur 2 constituent une tête de réseau 5 de diffusion. La diffusion peut s'effectuer par des réseaux de diffusion de télévision numérique, comme les réseaux TNT, mettant en oeuvre la norme DVB-T ("Digital Video Broadcasting - Terrestrial" pour "diffusion vidéo numérique terrestre"). La diffusion de paquets de données est spécifiée par des standards de façon à être reçu par un grand nombre de récepteurs de tout 10 type. Le réseau (terrestre, satellite ou câble) diffuse des contenus audio et/ou vidéo dans des flux de données plus communément appelés « service » et des données destinées à les référencer. Ces données sont par exemple définies dans les spécifications DVB-SI ('Digital Video Broadcast - specification for Service Information') ou encore 'diffusion de vidéo numérique - spécification 15 des Données de Service' EN 300 468 V1.3.1 (éditée par l'ETSI) et la norme « Technologies de l'information - Codage générique des images animées et du son associé : Système », référencée MPEG ISO/CEI 13818-1, 2nd édition publié le lier décembre 2000. Le serveur de streaming 3 dispose d'une unité centrale 4, d'une 20 mémoire de programme 5 et d'une unité de mémorisation 6, typiquement un disque dur. La mémoire de programme 5 contient notamment une application de gestion des services diffusés qui constitue un des objets de la présente invention. Le serveur de streaming communique avec un point d'accès Wifi 7 gérant un réseau Wifi local. L'ensemble formé par le serveur de streaming 3 et 25 le point d'accès Média 7 est désigné par « Média Serveur» ou « MS» en abrégé, étant entendu que l'ensemble peut se concrétiser par un seul appareil, ou par deux appareils indépendants et connectés entre eux. Selon une variante de réalisation, les flux de chunks générés par l'encodeur HLS sont émis par un serveur HTTP à travers un réseau 3G/4G, c'est 30 à dire un réseau de téléphonie mobile, pour être reçus par un point d'accès 3034610 10 Wifi. Quel que soit son type, le serveur de streaming 3 désencapsule les chunk reçus des différents flux, les répartit pour reconstituer les services le cas échéant (lorsque le flux de données diffusés comporte plusieurs services 5 multiplexés) et les mémorisent dans un buffer circulaire de la mémoire 6. Ce buffer circulaire organisé en FiFo (« First In First Out ») contient en permanence une certaine quantité de chunks par service ce qui correspond à une durée déterminée de reproduction de ces services, par exemple une heure. De cette manière, si chaque chunk d'un service permet la reproduction de 20 secondes 10 de contenus, le buffer permettant une reproduction d'une heure de ce service contient 180 chunks. Au niveau local, le MS dialogue avec des terminaux tels que des ordiphones 8 (ou « smartphone » selon une terminologie anglo-saxonne), des ordinateurs 8 bis portables ou non, des tablettes 8 ter, ... Chaque terminal 15 (désigné par la suite sous la référence générique 8) utilise le réseau Wifi géré par le point d'accès 7 pour transmettre au serveur de streaming des requêtes de communication afin de recevoir des chunks dûment référencés. Les communications entre terminaux sont de type de pair à pair, qui est la traduction française de « peer to peer», c'est le terme anglo-saxon qui sera par 20 la suite utilisé. Les communications peer to peer sont gérées par la couche de communication Wifi sans passer par le serveur de streaming 3. Lorsque le MS reçoit une requête d'un terminal 8 en spécifiant l'adresse IP du serveur de streaming, la couche de communication Wifi transmet la requête au serveur de streaming. Si la requête consiste à recevoir des chunks 25 d'un service actuellement diffusé, alors l'application de gestion des services diffusés recherche dans la mémoire 6 les chunks demandés par ce terminal et lui transmet à travers le point d'accès Wifi 7. Après avoir détaillé les principaux éléments constitutifs du système, nous allons maintenant expliquer comment ceux-ci coopèrent.

30 Lors de la reproduction d'un contenu audio et/ou vidéo, les terminaux 8 3034610 11 demande des salves de trois chunks consécutifs (ce chiffre étant donné à titre d'exemple), et au début de la reproduction du troisième, demande les trois chunks suivants. Si un petit nombre de terminaux dialoguent par le réseau Wifi avec le serveur de streaming 3, alors ce dernier peut assurer la gestion des 5 requêtes et répondre à leurs demandes. Dans certains cas, le nombre de terminaux 8 est important et les ressources du serveur de streaming 3 sont insuffisantes pour extraire les chunks demandés de la mémoire 6. Ce cas intervient notamment lorsque le MS est placé dans un véhicule occupé par de nombreux utilisateurs de terminaux 8, que ce véhicule soit en mouvement ou 10 non, ou dans une salle d'attente ou de spectacle. La présente invention permet notamment de diminuer la charge de travail du serveur de streaming 3 en reportant une partie au niveau des terminaux 8. La Fig. 2 présente un exemple d'ordinogramme montrant les étapes de 15 mise en oeuvre de l'invention selon un exemple de réalisation. Selon une étape préalable, le serveur de streaming 3 et les terminaux 8 téléchargent leurs applications de gestion des services diffusés, le téléchargement s'effectue à partir d'un site distant, ou d'un support matériel (clef USB, carte à puce, CD, ...). A l'étape 2.1, le serveur de streaming 3 reçoit du réseau de diffusion au 20 moins un service. L'application de gestion des services diffusés stocke alors les chunks des services dans la mémoire 6 gérée circulairement, et met à jour un premier tableau listant les services reçus du réseau de diffusion. Si la fonction permettant de revenir en arrière dans le contenu n'est pas disponible, seuls les trois derniers chunks peuvent être mémorisés, soit une durée de l'ordre de 60 25 secondes. Si la fonction de retour en arrière est proposée, alors le gestionnaire du serveur de streaming peut augmenter considérablement le nombre de chunks dans la mémoire 6 gérée circulairement pour allonger la durée disponible des contenus audio et/ou vidéo. A tout moment, des terminaux 8 peuvent interroger le serveur de streaming 3 via le réseau Wifi et son point 30 d'accès 7, et lui demander la liste des services actuellement disponibles. Le 3034610 12 serveur de streaming renvoie la liste extraite du premier tableau (étape 2.2). A l'étape 2.3, l'utilisateur du terminal TA demande au serveur de streaming de recevoir le Service Si qui transporte le contenu audio et/ou vidéo Cl. L'application de gestion des services diffusés vérifie que le service demandé 5 est diffusé et que les chunks correspondants sont bien présents dans la mémoire 6. Si c'est le cas, le serveur de streaming extrait de la mémoire 6 les derniers chunks du service demandé et demande au point d'accès Wifi de les émettre vers TA (étape 2.4). Le serveur de streaming met à jour le tableau indiquant que les chunks du service Si sont actuellement transmis à TA. A une 10 étape ultérieure 2.5, un second terminal TB demande au serveur de streaming de recevoir le même service Si. Le serveur de streaming consulte le tableau de configuration des services, et constate que ce service est déjà transmis vers le terminal TA. A l'étape 2.6, le serveur de streaming 3 transmet alors au terminal TB non pas les derniers chunks du service demandé mais l'identifiant du 15 terminal TA, par exemple son adresse P_A. En recevant cet identifiant, le terminal TB demande au point d'accès Wifi 7 d'établir une liaison Peer to Peer en Wifi avec le terminal TA identifié par l'adresse IP_A et lui transmet une demande de réception du service Si. Recevant déjà les chunks de ce service et les stockant temporairement dans sa 20 mémoire, le terminal TA répond au terminal TB à l'étape 2.7 par un message Peer to Peer indiquant qu'il possède bien les derniers éléments de ce service en spécifiant les numéros des chunks stockés dans sa mémoire. A la réception du message, le terminal TB demande à recevoir une salve de trois chunks, de préférence les trois derniers reçus et stockés par le terminal TA (étape 2.8). Le 25 terminal TA lui envoie alors à l'étape 2.9. Les échanges en Peer to Peer entre TA et TB s'effectuent à travers le point d'accès Wifi et sans passer par le serveur de streaming 3. Les chunks du service à destination du terminal TB transitent par le terminal TA. De cette manière, le serveur de streaming 3 assure la fourniture des chunks à un premier 30 terminal, mais ce terminal assure la fourniture au terminal suivant ce qui 3034610 13 diminue la charge de travail à exécuter par le serveur de streaming. Bien évidemment, la solution se généralise en créant une véritable chaîne où un second terminal dit « courant » reçoit d'un premier terminal dit « précédent » les chunks et les transmet à un troisième terminal dit « suivant » qui lui en fait 5 la demande. Certains terminaux 8 ne disposent pas des ressources permettant de gérer la retransmission d'un service vers un autre terminal en Peer to Peer, ou n'ont tout simplement pas téléchargé leur application de gestion des services diffusés. Selon un perfectionnement, lors de la requête pour recevoir un 10 service, un tel terminal signale ce fait au serveur de streaming 3 qui l'enregistre dans le tableau en lui associant cette information. Le serveur de streaming ne sélectionne pas pour retransmettre un service un terminal qui ne dispose pas des ressources pour réaliser une telle retransmission. La présente invention couvre également le fait qu'un terminal peut 15 recevoir plusieurs services en même temps, et qu'il peut de ce fait transmettre à la demande de terminaux éventuellement différents les chunks des services reçus. Cette gestion est possible à condition que les ressources du terminal le permettent. Selon un autre mode de réalisation, à l'étape 2.6, le serveur de 20 streaming transmet au terminal demandeur d'un service plusieurs identifiants de terminaux. Des liaisons Peer-toPeer s'établissent alors entre le terminal demandeur et les terminaux identifiés par le serveur de streaming. De cette manière, pour recevoir une salve de plusieurs chunks, un terminal demande un chunk (n) à un premier terminal, le chunk suivant (n+1) à un second et le chunk 25 suivant (n+2) à un troisième. Au bout d'un certain temps, de véritables chaînes de terminaux se constituent pour diffuser les services au sein du réseau Wifi. A tout moment, un terminal de la chaîne peut interrompre la réception des chunks, soit en coupant la réception, soit en se retirant de la couverture Wifi, soit en éteignant 30 l'appareil. La chaîne qui est coupée doit se reformer immédiatement pour 3034610 14 continuer à transmettre le service aux terminaux de la chaîne situés après la coupure. La Fig. 3 représente un réseau local comportant un serveur de streaming 5 3 et cinq terminaux TA, TB, TC, TD et TD communiquant avec un point d'accès Wifi (non représenté). La Fig. 3 montre les chemins des données à un instant précis, où l'application côté serveur de streaming gère la transmission des chunks de deux services : le service Si vers le terminal TA, et le service S2 vers le terminal TE. TB reçoit via le point d'accès Wifi les chunks du service Si 10 transmis par TA. Pour ne pas alourdir la figure, une seule flèche de TA vers TB est représentée alors que dans les faits, la liaison entre TA et TB transite par le point d'accès Wifi 7. TC reçoit de TB les chunks du service Si et TD reçoit de TC les chunks du service Si. Le tableau listant les services reçus du réseau de diffusion indique que Si est transmis à TA et que S2 est transmis à TE.

15 Supposons maintenant que l'utilisateur du terminal TC décide de ne plus recevoir le service Si mais le service S2. TC transmet une requête au serveur de streaming 3 pour recevoir ce service et l'application de gestion des services diffusés lui répond en indiquant de transmettre sa requête à TE. Comme décrit par la Fig. 2, TC demande à TE par une liaison Peer to Peer via le point d'accès 20 Wifi de recevoir les chunks du service S2, et TC devient le second terminal de la chaîne de transmission du service S2. TC ne demande plus de recevoir de TB les chunks du service Si, et ne les possède donc plus en mémoire. Lorsque TD demande à TC de lui transmettre les chunks de Si, TC soit ne lui répond pas, soit répond qu'il ne les a pas. TD s'adresse alors au serveur de streaming 3 pour 25 demander à recevoir Si. En lisant le tableau, le serveur de streaming répond de s'adresser à TA. TA constatant que son application de gestion des services diffusés est déjà occupé à transmettre les chunks de Si à TB, répond à TD de s'adresser à TB. TD transmet sa requête à TB. TB constatant qu'il est le dernier de la chaîne, répond qu'il possède bien les derniers chunks de ce service et qu'il 30 est prêt à les transmettre. Ainsi, la situation illustrée par la Fig. 4 intervient 3034610 15 rapidement où deux chaînes sont opérationnelles, l'une pour transmettre Si du serveur de streaming 3 vers TA, puis vers TB, puis vers TD, et une autre pour transmettre S2 du serveur de streaming 3 vers TE, puis vers TC. On constate que cette gestion dynamique s'adapte bien à la 5 modification des besoins des terminaux en termes de réception de services. Selon une variante, la gestion des chaînes de terminaux s'effectue intégralement au niveau de l'application de gestion des services diffusés, cette application étant résidente dans le serveur de streaming qui a ainsi la connaissance totale des flux entre terminaux du réseau Wifi et la composition 10 des différentes chaînes en cours. Le passage d'un terminal à un autre pour véhiculer les chunks entraîne un retard dans la réception par le terminal en fin de chaîne et donc sa reproduction. Selon un perfectionnement, les applications de gestion des services diffusés résidente dans le serveur de streaming 3 et les terminaux 8 15 limitent le nombre de terminaux formant une chaîne de transmission des contenus audio et/ou vidéo. Si un terminal constate que son numéro d'ordre dans la chaîne dépasse le nombre maximum, 10 par exemple, alors il indique cette information au serveur de streaming. Le serveur de streaming enregistre le fait que cette chaîne est complète et sait qu'il ne doit plus proposer de 20 connexions de ce service par ce terminal, au moins au cours d'un certain temps. Le serveur de streaming transmet au terminal demandeur, soit l'identifiant d'un autre terminal à qui il transmet les chunks de ce service, soit son propre identifiant indiquant en cela qui assume la gestion de ce terminal et crée ainsi une nouvelle chaîne.

25 Selon une variante de réalisation, à l'étape 2.6, le serveur de streaming transmet à un terminal demandeur d'un service une liste de plusieurs identifiants de terminaux à qui le serveur de streaming transmet actuellement le service demandé et qui sont donc des premiers terminaux de chaîne. Le terminal demandeur s'adresse à un premier terminal de la liste et constate que 30 le maximum de terminaux est atteint où qu'aucun terminal de la chaîne ne 3034610 16 dispose des ressources nécessaires pour lui transmettre le service, alors il décide de lui-même de passer à un autre premier terminal de la liste. Si aucun terminal des chaînes ainsi explorées ne peut délivrer ce service, alors le terminal demandeur transmet au serveur de streaming une requête pour créer 5 une nouvelle chaîne dans lequel il est le premier terminal. La Fig. 5 présente un exemple de tableau listant les services reçus du réseau de diffusion, ce tableau est mis à jour par l'application de gestion des services diffusés présente dans le serveur de streaming 3. L'exemple présenté montre quatre services diffusés et reçus par le serveur de streaming. Un 10 premier service appelé « Info Météo» est transmis au terminal T1 ayant l'adresse IP « IP_1 ». Un second service appelé « Canal 1 » est transmis au terminal T5 et au terminal T18. Le tableau indique que la chaîne qui démarre par le terminal T5 a atteint son nombre maximum de terminaux. Si un terminal demande à recevoir ce service, alors le serveur de streaming répond en 15 transmettant l'adresse IP _18 du terminal T18. Un troisième service appelé « Canal 2)> n'est transmis à aucun terminal. Un quatrième service appelé « Info Trafic» est transmis aux terminaux T3, T18 et Tl. Le terminal T3 est marqué comme étant non connectable car il n'a pas les ressources nécessaires pour supporter la transmission des chunks vers un autre terminal. Le terminal T18 20 est également marqué comme étant non connectable car, recevant déjà le second service et le retransmettant à un autre terminal, il n'a plus les ressources nécessaires pour supporter la transmission des chunks vers d'autres terminaux. Si un terminal demande à recevoir ce quatrième service, alors le serveur de streaming transmet l'adresse de Tl. A noter que T1 reçoit aussi le 25 premier service. En consultant le tableau, on peut constater que T1 possède les ressources pour gérer deux chaines de transmission de service. L'invention n'est pas limitée aux modes de réalisation qui viennent d'être décrits. En particulier, tout appareil informatique dialoguant avec un serveur par liaison Wifi est susceptible de mettre en oeuvre la présente 30 invention.

Claims

REVENDICATIONS1. Procédé de transmission d'au moins un contenu audio et/ou vidéo linéaire d'un serveur de diffusion (3) vers une pluralité de terminaux (8) en utilisant un réseau Wifi, comportant une étape préalable de réception (2.1) dudit contenu par le serveur de diffusion à l'aide d'un réseau de diffusion et une étape d'émission (2.4) par le serveur de diffusion vers un premier terminal, dudit contenu sous la forme d'un flux de paquets de données ; caractérisé en ce qu'il comporte une étape d'émission (2.5) par un second terminal d'une requête vers le serveur de diffusion pour recevoir, par le réseau Wifi, ce même contenu, ladite étape d'émission de ladite requête déclenchant une étape de transmission (2.6) par le serveur de diffusion d'un message identifiant le premier terminal comme terminal émetteur de ce contenu, le second terminal émettant alors une requête de réception (2.8) de ce contenu vers le premier terminal pour recevoir ledit contenu à travers une liaison pair à pair.
2. Procédé de transmission d'un contenu selon la revendication 1 caractérisé en ce qu'il comporte une étape de gestion d'une liste au niveau du serveur de diffusion (3), ladite liste associant un contenu donné à au moins un identifiant d'un terminal (8) qui reçoit du serveur de diffusion ce contenu, et en ce que l'étape de transmission d'un message, par le serveur de diffusion, en réponse à une requête émise par le second terminal pour recevoir ce contenu, comporte une sous-étape de sélection par le serveur de diffusion, dans ladite liste, d'un identifiant d'un terminal qui est associé au contenu demandé et une sous-étape de transmission, dans ledit message, dudit identifiant sélectionné, au second terminal.
3. Procédé de transmission d'un contenu selon la revendication 2 caractérisé en ce qu'il comporte une étape de transmission d'un message d'un terminal (8) vers le serveur de diffusion (3) indiquant que ce terminal n'a pas les 3034610 18 ressources nécessaires pour transmettre à un autre terminal le contenu actuellement reçu et associé dans la liste, cette information étant introduite dans la liste gérée par le serveur de diffusion, un tel terminal n'étant pas sélectionné par le serveur de diffusion pour transmettre le contenu à un autre 5 terminal.
4. Procédé de transmission d'un contenu selon la revendication 2 ou 3 caractérisé en ce qu'il comporte une étape de transmission d'un message d'un terminal (8) vers le serveur de diffusion (3) indiquant que ce terminal possède les ressources nécessaires pour transmettre à un autre terminal une pluralité de 10 contenus actuellement reçus et associés dans la liste, cette information étant introduite dans la liste gérée par le serveur de diffusion, un tel terminal étant sélectionné par le serveur de diffusion pour transmettre l'un des contenus à un autre terminal. 15
5. Procédé de transmission d'un contenu selon l'une quelconque des revendications 1 à 4; caractérisé en ce qu'il comporte les étapes suivantes : - émission par un terminal demandeur d'un contenu vers un terminal dit « précédent» d'une requête pour recevoir ce contenu par une liaison pair à pair, 20 - émission par le terminal précédent en réponse à ladite requête d'un message vers le terminal demandeur indiquant de demander ce contenu à un terminal dit « suivant », le terminal précédent transmettant déjà ce contenu au terminal suivant, - réitération des deux étapes précédentes, le terminal suivant devenant le 25 terminal précédent, jusqu'à ce qu'un terminal suivant transmette ledit contenu au terminal demandeur.
6. Procédé de transmission d'un contenu selon la revendication 5; caractérisé en ce qu'il comporte une étape de comptage des itérations par le 30 serveur de diffusion, les étapes suivantes sont déclenchées lorsque le nombre 3034610 19 d'itérations atteint une valeur maximale déterminée : - arrêt des itérations, - recherche par le serveur de diffusion d'un autre premier terminal recevant le contenu par le serveur, 5 - émission par le terminal demandeur d'une requête de réception de ce contenu vers cet autre premier terminal pour lui transmettre ledit contenu.
7. Procédé de transmission d'un contenu selon la revendication 5; 10 caractérisé en ce que le message transmis par le serveur de diffusion en réponse à une requête pour recevoir par le réseau Wifi un contenu, comporte une liste de plusieurs terminaux identifiés comme terminaux recevant ledit contenu, le terminal demandeur de ce contenu s'adressant à un premier terminal de la liste pour recevoir ce contenu et explorant une succession de 15 terminaux à partir de ce premier terminal de la liste par des liaisons pair à pair, une nouvelle requête de réception de ce contenu vers un autre premier terminal de la liste étant déclenchée par le terminal demandeur lorsque le nombre d'itérations atteint une valeur maximale déterminée sans avoir pu recevoir ce contenu. 20
8. Procédé de transmission d'un contenu selon la revendication 7 ; caractérisé en ce que le terminal demandeur émet une requête pour recevoir directement du serveur de diffusion le contenu demandé lorsqu'aucun terminal des successions de terminaux commençant par les premiers terminaux de la 25 liste transmise dans le message, n'est disponible pour transmettre le contenu demandé.
9. Serveur de diffusion (3) recevant par un moyen de réception au moins un contenu audio et/ou vidéo linéaire à travers un réseau de diffusion et 30 comprenant un moyen de communication pour émettre et recevoir des 3034610 20 messages vers une pluralité de terminaux (8) à travers un point d'accès Wifi, caractérisé en ce que ledit moyen de communication émet vers un premier terminal et à sa demande un contenu sous la forme d'un flux de paquets de données, ledit moyen de communication recevant d'un second terminal une 5 requête pour recevoir ce même contenu par le réseau Wifi, la réception de cette requête déclenchant la transmission par ledit moyen de communication d'un message identifiant le premier terminal comme terminal émetteur de ce contenu. 10
10. Terminal (8) destiné à recevoir au moins un contenu audio et/ou vidéo linéaire provenant d'un réseau de diffusion, ledit terminal comportant au moins une mémoire de stockage de données du contenu et un moyen de communication par Wifi pour émettre et recevoir des messages à travers un point d'accès Wifi (7), caractérisé en ce que ledit moyen de communication 15 émet vers un serveur de diffusion une requête pour recevoir ledit contenu sous la forme d'un flux de paquets de données, ledit moyen de communication recevant en réponse lesdits paquets de données, les dits paquets étant stockés dans la mémoire de données, ledit moyen recevant ultérieurement une requête provenant d'un autre terminal (8) pour transmettre à cet autre terminal lesdits 20 paquets de données précédemment stockés en mémoire, ledit moyen émettant en réponse lesdits paquets extraits de la mémoire de données.
11. Produit programme d'ordinateur téléchargeable depuis un réseau de communications et/ou stocké sur un support lisible par ordinateur et/ou 25 exécutable par une unité centrale, caractérisé en ce qu'il comprend des instructions de programme pour la mise en oeuvre d'au moins une étape du procédé de transmission d'un contenu selon l'une quelconque des revendications 1 à 8.