FR2922401A1 - Dispositif de reception en continu de paquets de donnees audio et/ou video - Google Patents

Dispositif de reception en continu de paquets de donnees audio et/ou video Download PDF

Info

Publication number
FR2922401A1
FR2922401A1 FR0758195A FR0758195A FR2922401A1 FR 2922401 A1 FR2922401 A1 FR 2922401A1 FR 0758195 A FR0758195 A FR 0758195A FR 0758195 A FR0758195 A FR 0758195A FR 2922401 A1 FR2922401 A1 FR 2922401A1
Authority
FR
France
Prior art keywords
time
packets
receiving device
adapting
buffering time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0758195A
Other languages
English (en)
Other versions
FR2922401B1 (fr
Inventor
Jean Noel Cuoq
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sagemcom Broadband SAS
Original Assignee
Sagem Communications SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR0758195A priority Critical patent/FR2922401B1/fr
Application filed by Sagem Communications SAS filed Critical Sagem Communications SAS
Priority to EP08842934A priority patent/EP2218256A1/fr
Priority to BRPI0817882A priority patent/BRPI0817882A2/pt
Priority to PCT/FR2008/051801 priority patent/WO2009053595A1/fr
Priority to CN200880110550A priority patent/CN101822048A/zh
Priority to US12/682,362 priority patent/US20100299448A1/en
Publication of FR2922401A1 publication Critical patent/FR2922401A1/fr
Priority to CO10041379A priority patent/CO6382187A2/es
Application granted granted Critical
Publication of FR2922401B1 publication Critical patent/FR2922401B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4385—Multiplex stream processing, e.g. multiplex stream decrypting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44008—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1059—End-user terminal functionalities specially adapted for real-time communication

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un dispositif 108 de réception en continu de paquets de données audio et/ou vidéo transmis sur un réseau 104 depuis un serveur source 101. L'invention s'applique uniquement au domaine des données émises en continu. Le dispositif 108 comprend une mémoire tampon réseau 110 dans laquelle peuvent être mémorisés les paquets et qui présente un temps de mise en mémoire variable et des moyens 120 pour adapter le temps de mise en mémoire tampon en vue de performance de restitution améliorée. Le dispositif 108 comporte en outre des moyens 121 pour déterminer localement la valeur d'au moins un indicateur 135, 136, 137 de qualité de service, les moyens 120 pour adapter le temps de mise en mémoire tampon adaptant ce temps en fonction de la valeur de l'indicateur.

Description

Dispositif de réception en continu de paquets de données audio et/ou vidéo
Domaine technique de l'invention La présente invention concerne un dispositif de réception en continu de paquets de données audio et/ou vidéo transmis sur un réseau depuis un serveur source. L'invention s'applique uniquement au domaine des données émises en continu ( streaming en anglais) donc des données qui doivent être jouées en temps réel : l'invention ne concerne pas les données qui sont téléchargées et enregistrées dans un premier temps sur un dispositif de réception puis jouées ensuite. L'invention s'applique plus particulièrement au domaine des dispositifs reliés à un réseau de transmission de paquets de données avec une qualité de services non garantie du type IP ( Internet Protocol en anglais), l'architecture de réseau IP existante, appelée architecture best effort (ou architecture du meilleur effort ), n'offrant aucune garantie de qualité de service. Appliqué aux réseaux à commutation de paquets, le terme QoS (acronyme de Quality of Service en anglais, Qualité de Service en français) désigne la capacité à fournir un service conforme à des exigences notamment en matière de temps de réponse, de bande passante ou de perte de paquets. En d'autres termes, l'invention ne s'applique à des réseaux du type ATM ( Asynchronous Transfer Mode en anglais) offrant une QoS adaptée aux différents types de trafic. D'une façon générale, la lecture en continu (ou streaming) est un principe utilisé pour l'envoi de contenu en direct . Très utilisée sur Internet, elle permet la lecture d'un flux audio ou vidéo (cas de la VoD Video On Demand ou télévision numérique sur Internet), à mesure qu'il est diffusé. Elle s'oppose ainsi à la diffusion par téléchargement qui nécessite de récupérer l'ensemble des données d'un morceau ou d'un extrait vidéo avant de pouvoir l'écouter ou le regarder. Ainsi, des paquets de données audio et/ou vidéo sont émis par un serveur sur le réseau Internet et reçus par un dispositif tel qu'un décodeur de télévision numérique ou tout autre type de dispositif de restitution de données audio-vidéo ( media player en anglais) connecté au réseau (un terminal mobile tel qu'un téléphone ou un assistant personnel par exemple).
Arrière-plan technologique de l'invention Un dispositif de réception en continu de paquets de données audio et/ou vidéo récupère donc ces paquets de données qu'il place dans une mémoire tampon (dite buffer en anglais) qui correspond à une partie d'une mémoire de type RAM (pour Random Access Memory en anglais) ou de tout type de mémoire à accès rapide (disque dur, clef USB par exemple). Cette mémoire sera désignée par la suite sous la dénomination mémoire tampon réseau . La présence d'une mémoire tampon réseau explique le délai existant entre le moment où l'utilisateur appelle (en cliquant sur un lien hypertexte par exemple) le morceau ou le film sur Internet et le début de la lecture du fichier audio-vidéo. Cette mise en mémoire tampon s'impose pour différentes raisons : Le premier aléa nécessitant cette mise en mémoire tampon est constitué par la gigue ( jitter en anglais) qui est un phénomène de fluctuation du signal. Cette fluctuation peut être un glissement de phase ou une dispersion temporelle. Ainsi, les paquets étant transportés en best effort , les données peuvent donc arriver plus ou moins vite et cette gigue entraîne des erreurs en sortie lors de la récupération des données. Donc pour pouvoir maintenir la synchronisation de restitution, le dispositif de réception des pa- quets met les données reçues en tampon de manière à lisser les variations de temps de transmission et/ou de débit. On notera en outre que les paquets de données n'arrivent pas toujours dans l'ordre et qu'il convient donc de les regrouper et de les agencer dans le bon ordre dans la mémoire tampon réseau.
En outre, dans le contexte de la transmission d'images audio-vidéo sur le réseau Internet, où généralement le taux d'erreurs de transmission important se caractérise par la perte de paquets, il convient de protéger les paquets des données à l'aide, entre autres, de codes correcteurs d'erreurs tels que des codes de contrôle continu FEC, acronyme de l'expression an- glaise Forward Error Correction . Le FEC consiste à ajouter des éléments redondants du message numérique aux données transmises avant l'envoi du signal audio/vidéo, pour pouvoir les vérifier à la réception et ainsi réduire les risques d'erreurs liés à la diffusion et qui perturberaient la réception. La norme "FEC COP#3 r2" du "Pro MPEG Forum" décrit une mise en oeuvre de la fonction FEC. De plus en plus d'opérateurs utilisent le codage FEC : typiquement, en surchargeant d'environ 20% la quantité de paquets initiaux, on réduit considérablement le nombre de paquets perdus. L'introduction de ces codes de correction entraine bien entendu un temps de calcul supplémentaire pendant lequel les données doivent être tamponnées (i.e. mises en mémoire tampon). Par ailleurs, l'utilisation d'un protocole de transmission de données pour la diffusion en temps réel du type RTP ( Real-time Transfer Protocol en anglais) associé à un protocole de contrôle des flux de données du type RTCP ( Real-time Transfer Control Protocol en anglais) nécessite égale-ment l'utilisation d'une mémoire tampon réseau. Le dispositif reçoit des paquets via le protocole RTP ; lorsqu'il détecte un paquet manquant, il envoie sur une voie de retour une requête conforme au protocole RTCP pour de-mander le paquet manquant. Il est donc nécessaire de mémoriser le reste des données le temps (typiquement 300 ms) que le paquet manquant revienne du serveur. Les protocoles RTP et RTCP sont conformes aux descriptions des documents RFC 3550, 4588 et 4585.
L'absence de mémoire tampon réseau pour les paquets de données entraînerait une dégradation de l'image (perturbations à l'écran telles qu'une vidéo saccadée ou une image figée) et/ou du son (son haché ou métallique par exemple). En revanche, l'utilisation de cette mémoire tampon réseau dans la- quelle les paquets sont temporairement enregistrés au fur et à mesure de leur réception par le dispositif implique que soit trouvé un bon compromis entre le temps de mise en mémoire tampon et la qualité d'image et/ou de son souhaitée. Si on souhaite une très bonne qualité, il faut un temps de mise en mémoire important (jusqu'à l s à 3s pour un décodeur de télévision numérique) entraînant de ce fait une occupation importante de la RAM et un temps de connexion rallongé pour l'utilisateur. De même, par exemple dans le cas d'une transmission de la télévision en multicast (c'est-à-dire une transmission point-à-multipoint qui permet de faire des économies de bande passante en ne faisant transiter qu'un paquet, même lorsqu'il est destiné à plusieurs destinations) le changement de programme ( zapping ou TV surfing en anglais) est également rallongé. Dans le cas de la VoD, les mo- des fonctionnement d'avance ou de retour rapide ("trick mode" en anglais), le lancement d'une vidéo ou le lancement d'une séquence dans une liste de fichiers ( playlist en anglais) sont aussi impactés. Ces modes ne sont en effet pas mis en oeuvre localement ; faisant appel au serveur, ils entraînent une mise en mémoire tampon plus longue.
Une solution connue pour répondre à ce besoin de compromis consiste à adapter le temps de mise en mémoire tampon au travers d'échanges entre le serveur et le dispositif de réception. Le dispositif de réception présente donc un temps de mise en mémoire tampon variable. Le dispositif de réception envoie une requête de réglage de la durée de mise en mémoire tampon et reçoit des signaux provenant du serveur source qui commande l'adaptation du temps de mise en mémoire. Toutefois, la mise en oeuvre d'une telle solution de configuration du temps de mise en mémoire tampon (appelée aussi parfois bufferisation par la suite) pose certaines difficultés.
Ainsi, un premier inconvénient de cette solution réside dans l'augmentation du trafic engendrée. Cette augmentation du trafic entraîne une perturbation de l'accès au réseau et un surcoût non négligeable. Par ailleurs, une telle solution entraîne l'ajout de matériels au niveau du réseau (notamment au niveau des équipements de tête de réseau).
Description générale de l'invention Dans ce contexte, la présente invention vise à fournir un dispositif de réception en continu de paquets de données audio et/ou vidéo transmis de-puis un serveur source via un réseau permettant un ajustement efficace du temps de mise en mémoire tampon réseau pour compenser les perturbation inhérentes au réseau tout en s'affranchissant des problèmes précités.
A cette fin, l'invention propose un dispositif de réception en continu de paquets de données audio et/ou vidéo transmis depuis un serveur source via un réseau, le dispositif de réception comprenant : - une mémoire tampon réseau dans laquelle peuvent être mémorisés lesdits paquets, la mémoire tampon réseau présentant un temps de mise en mémoire tampon variable, -des moyens pour adapter le temps de mise en mémoire tampon des paquets en vue de performance de restitution améliorée, le dispositif étant caractérisé en ce qu'il comporte des moyens pour déter- miner localement la valeur d'au moins un indicateur de qualité de service, les moyens pour adapter le temps de mise en mémoire tampon adaptant le temps de mise en mémoire en fonction de la valeur de l'indicateur de QoS. Grâce à l'invention, la détermination du temps de mise en mémoire tampon est réalisée localement via la détermination d'au moins un indicateur de QoS sans signal de commande du serveur: ce traitement local au dispo- sitif de réception implique les avantages suivants : - ce n'est pas le réseau qui adapte la durée de temps de mise en mémoire tampon (donc pas de surcharge réseau), - il n'y a d'investissement de l'opérateur pour réaliser l'adaptation puis- que tout est fait localement, - l'invention est applicable à de la transmission multicast et unicast , -l'utilisateur n'a pas à intervenir sur le dispositif via des menus de configuration qui peuvent être perçus comme complexes.
C'est le dispositif selon l'invention qui est en charge de déterminer le meilleur compromis possible entre le temps de mise en mémoire tampon, la qualité d'image et/ou de son souhaitée et le temps de connexion et de navi- gation en VoD. Ainsi, avec un temps de bufferisation très faible, on aura : - une qualité d'image et de son moyenne si la ligne est de qualité mé- diocre, - un temps de connexion et de navigation en VoD nominal. Inversement, avec un temps de bufferisation élevé, on aura : - une bonne qualité d'image et de son même si la ligne est de qualité médiocre, - un temps de connexion et de navigation en VoD très long (jusqu'à 1 à 2 s de plus par rapport au cas nominal).
Les problèmes de réception sont souvent spécifiques à chaque abonné, l'avantage du dispositif selon l'invention est que l'adaptation se fait dynamiquement sans que l'abonné ait besoin de demander à l'opérateur de configurer le dispositif ou de configurer lui-même la taille du buffer. Le dispositif selon l'invention peut également présenter une ou plu- sieurs des caractéristiques ci-dessous, considérées individuellement ou se- lon toutes les combinaisons techniquement possibles. Avantageusement, le temps de mise en mémoire tampon est inférieur à 3 s (préférentiellement inférieur à 2 s) et supérieur à 100 ms. Avantageusement, l'indicateur de qualité de service est choisi parmi les indicateurs suivants : - le nombre de paquets manquants, - la latence lors de demande de paquet manquant (par exemple dans le cas d'une diffusion en unicast avec une détection de paquets manquants du type RTP/RTCP), - le rendu audiovisuel. Selon un mode de réalisation, les moyens pour adapter le temps de mise en mémoire tampon adaptent le temps de bufferisation en fonction du ratio entre la valeur de l'indicateur de qualité de service et la durée d'utilisation du dispositif de réception.
Selon une variante, les moyens pour adapter le temps de mise en mémoire tampon adaptent le temps lorsque la valeur de l'indicateur de qualité de service dépasse un seuil critique. Cette adaptation peut se faire lors-que la valeur de l'indicateur de qualité de service dépasse le seuil critique au moins pendant un temps déterminé.
Avantageusement, les moyens pour adapter le temps de mise en mémoire tampon sont adaptés en fonction du type de paquets de données, ces moyens pouvant réagir différemment selon que les paquets de données sont du type vidéo à la demande ou télévision.
Selon une variante, les paquets de données sont des paquets correspondant à un signal de télévision, le dispositif selon l'invention comportant des moyens pour détecter une chaîne plus particulièrement regardée par l'utilisateur et les moyens pour adapter le temps de mise en mémoire tam-pon adaptant spécifiquement le temps de mise en mémoire des paquets correspondant à la chaîne détectée. Avantageusement, lesdits moyens pour déterminer localement la va-leur d'au moins un indicateur de qualité de service comportent des moyens de réinitialisation de ladite valeur.
Avantageusement, lesdits moyens pour adapter le temps de mise en mémoire tampon des paquets en vue de performance de restitution améliorée évoluent avec le temps par apprentissage Le dispositif selon l'invention est particulièrement adapté au domaine des décodeurs de télévision.
Brève description des figures D'autres caractéristiques et avantages de l'invention ressortiront clairement de la description qui en est donnée ci-dessous, à titre indicatif et nullement limitatif, en référence à la figure 1 annexée qui est une représentation schématique simplifiée d'une architecture utilisant un dispositif selon l'invention. Description des formes de réalisation préférées de l'invention La figure 1 représente une architecture 100 utilisant un dispositif 108 selon l'invention. Dans l'exemple illustré, le dispositif 108 est un décodeur de télévision numérique.
L'architecture 100 comporte en outre : - un téléviseur 119, un téléphone 106 et un micro-ordinateur 107, - un modem 105, - un réseau 104 du type Internet, - une source distante 101 de données audio vidéo telle qu'un serveur distant. Le modem 105 est un modem du type ADSL ( Asymmetric Digital Subscriber Line en anglais) triple play offrant à l'utilisateur l'accès aux trois services que sont la télévision ou la vidéo à la demande VoD via la télévision 119, la téléphonie via le téléphone 106 et Internet via le micro-ordinateur 107. Le serveur 101 comporte un encodeur 102 et un dispositif d'encapsulation 103.
Qu'il s'agisse d'une VoD ou d'un signal de télévision, on part d'un signal audio vidéo natif SI qui subit une compression et un encodage du type MPEG-2 dans l'encodeur 102 pour aboutir à un signal MPEG-2 S2. Même si la description s'appuie sur la norme de codage vidéo MPEG-2, d'autres standards similaires peuvent être utilisés tels que MPEG-4 ou H263.
Le signal S2 audio vidéo n'est pas transmis sur le réseau de distribution 104 dans son format brut tel qu'il apparait après la phase de compression et d'encodage en MPEG-2. Il est découpé en paquets audio vidéo, multiplexés entre eux et encapsulés en un flux spécifique pour le transport baptisé MPEG-2 TS ( Transport Stream en anglais). Cet unique flux est dé- coupé et inséré dans des paquets RTP ( Real-time Transport Protocol en anglais) avec éventuellement des systèmes de correction d'erreur du type FEC. Les paquets sont ensuite encapsulés dans des paquets UDP ( User Datagram Protocol en anglais) ou TCP ( Transmission Control Protocol en anglais) intégrant tous les éléments constitutifs nécessaires à la recons- truction du programme eux-mêmes transmis dans des datagrammes IP. On notera que l'invention s'applique uniquement au cas de paquets audio vidéo émis en streaming (donc des données qui doivent être jouées en temps réel sur le téléviseur 119). Les paquets de données sont reçus par le modem 105 via un mufti- plexeur DSLAM non représenté ( Digital Subscriber Line Access Multiplexer en anglais) qui transmet ces paquets à un récepteur de paquets 109 du décodeur 108. L'accès aux chaines de télévision ou à la VoD nécessite l'utilisation du décodeur 108 dont la fonction primaire est de décoder le flux de données vidéo compressées au format MPEG 2. Le récepteur de données numériques 109 et le modem 105 sont reliés par un câble Ethernet 123. On notera que cette liaison pourrait également être une liaison WiFi ou WiMAX. Le décodeur 108 comporte : - une mémoire tampon réseau 110 - un microprocesseur 116 commandé par des programmes situés dans une mémoire de programme 117, - une mémoire de données 118, - des bus 112, 114, 115 d'adresses de données et de commandes per-mettant aux différents éléments du décodeur 108 d'être reliés entre eux et permettant aussi au microprocesseur 116 de pouvoir communiquer avec ces éléments afin de les gérer, - un dispositif décodeur de données du type MPEG-2 111.
Le décodeur 108 reçoit via le récepteur 109 des paquets de données compressées qui sont transmises à la mémoire tampon réseau 110 puis au décodeur MPEG-2 111 pour être restituées au téléviseur 119 via une prise péritel 124. On notera que le décodeur MPEG-2 111 utilise une mémoire tampon Audio-Vidéo (AV) 113. Ainsi, dans le cas d'une séquence vidéo à la norme MPEG-2, celle-ci peut être composée de trois types d'images : I (Intra), P (Prédites) et B (Bidirectionnelles). Toutes ces images ne sont pas traitées et compressées de la même façon. Les images P sont prédites à partir des images I ou P précédentes. Les images B sont également des images prédites mais elles présentent la particularité de pouvoir être interpo- fées à partir d'images I ou P passées et/ou futures. Le décodage d'une image B n'est possible que si les images I ou P qui lui servent de référence (notamment les images futures) sont disponibles. Ceci explique la présence de la mémoire tampon AV 113 qui stocke provisoirement les images I et P déjà décodées par le décodeur MPEG-2 111 le temps que le décodeur MPEG-2 111 décode les images P et B suivantes. Les images sont ensuite replacées dans leur ordre normal. On voit ici que la mémoire tampon AV 113 dépend du type de l'algorithme de compression utilisé et que sa fonction est complètement différente de celle de la mémoire tampon réseau 110. Le débit de données transmises au décodeur 108 peut varier typi- quement entre 1,5 Mbit/s et 12 Mbit/s. Comme nous l'avons expliqué plus haut, les paquets sont temporairement enregistrés au fur et à mesure de leur réception par la mémoire tampon réseau 110 pour palier à différents aléas tels que : - les problèmes liés à la gigue, -l'utilisation d'un code de correction d'erreur du type FEC entraînant un temps de calcul supplémentaire, - l'utilisation de protocoles du type RTP/RTCP qui implique des temps d'attente additionnelle pour l'envoi de requête et la réception de paquets manquants. On notera qu'en transmission multicast ou unicast sans voie de re- tour, seul le codage FEC est possible, l'utilisation du protocole RTCP impli- quant la présence d'une voie de retour. En transmission unicast avec voie de retour, on peut avoir: - un codage FEC - une utilisation des protocoles RTP/RTCP - une combinaison du codage FEC + des protocoles RTP/RTCP (par exemple pour demander des paquets qui n'auraient pas été corrigés par le codage FEC). Il est nécessaire de trouver le meilleur compromis possible entre le temps de mise en mémoire tampon, la qualité d'image et/ou de son souhaitée et le temps de connexion et de navigation en VoD. Ainsi, avec un temps de bufferisation très faible, on aura : - une qualité d'image et de son moyenne si la ligne est de qualité méd iocre, - un temps de connexion et de navigation en VoD nominal. Inversement, avec un temps de bufferisation élevé, on aura : - une bonne qualité d'image et de son même si la ligne est de qualité médiocre, - un temps de connexion et de navigation en VoD très long (jusqu'à 1 à 2 s de plus par rapport au cas nominal). La mémoire tampon réseau 110 peut faire partie d'une mémoire de type RAM dont la taille globale est par exemple 128 ou 256 Mo pour un dé- codeur de télévision numérique avec typiquement une taille de l'ordre de 512 Ko à 5 Mo consacrée à la mémoire tampon réseau 110. Afin de réaliser ce compromis, le temps de mise en mémoire tampon est variable : ce temps pourra typiquement varier entre 100 ms et 3 s (préfé- rentiellement inférieur à 2 s voire à 1 s) pour un décodeur de télévision numérique avec une valeur par défaut de l'ordre de 300 ms. Au passage, on peut noter que cette valeur par défaut peut varier en fonction de la destination des décodeurs si l'opérateur sait à quels pays sont destinés les déco- deurs. La mémoire de données 118 est notamment destinée à mémoriser différentes informations, valeurs ou paramètres nécessaires au fonctionne-ment du décodeur. La mémoire de données comporte ainsi notamment des indicateurs de QoS à valeur variable qui peuvent être par exemple : - le nombre de paquets manquants 135, - la latence lors de demande de paquet manquant 136, - le rendu audiovisuel 137 sur le téléviseur 119 au travers par exemple d'indicateur du nombre d'erreurs correspondant à des images figées. Le nombre de paquets manquants correspond au nombre de paquets de données non délivrés, la plupart du temps dû à un encombrement du ré-seau. Ce nombre de paquets manquants est fourni par un compteur de continuité ( continuity counter en anglais) dont la valeur est codée sur 4 bits pour les paquets TP ( Transport Packet en anglais) définis par la norme MPEG-2 Systems ISO/IEC 13818-1. Si le protocole RTP (RFC 3550) est utilisé, le champ sequence_number (codé sur 16 bits) de l'en-tête peut également être utilisé. La latence lors de demande de paquet manquant est déterminée via les protocoles RTP/RTCP : lorsqu'une requête de paquet manquant est émise selon RTP (RFC 3550), la latence correspond au temps écoulé entre l'émission de la requête et le retour du paquet manquant via RTCP. Concernant l'indicateur de rendu audiovisuel, au niveau du décodeur MPEG-2 111, il y a principalement deux cas d'erreurs liés au taux de rem-plissage de la mémoire tampon AV 113: - erreur du type sous-remplissage ( under-flow en anglais) : le décodeur MPEG-2 111 consomme les données plus rapidement que ces dernières arrivent. Si le décodeur MPEG-2 111 n'a plus de don- nées, il ne peut plus décompresser les images suivantes et dans ce cas la dernière image qui a pu être décompressée reste figée sur l'écran du téléviseur 119. - erreur du type débordement ( over-flow en anglais) : les don-nées arrivent plus rapidement que le décodeur MPEG-2 111 ne peut les consommer : la mémoire tampon AV 113 déborde et des données sont donc perdues. La conséquence est que des perturbations seront visibles sur l'écran du téléviseur 119. Le décodeur MPEG-2 111 remonte des alarmes (interruptions par exemple) chaque fois qu'il rencontre ces cas d'erreurs et il est donc possible de suivre ces erreurs (et donc le rendu audiovisuel) via un indicateur. On notera que ces indicateurs sont uniquement donnés à titre d'exemple et que l'invention s'applique également à d'autres types d'indicateurs. On notera en outre que le décodeur 108 peut indifféremment utiliser plusieurs indicateurs ou un seul.
La mémoire de données 118 comprend également un indicateur 138 fournissant la durée d'utilisation du décodeur 108 par l'utilisateur (i.e. nombre d'heures de visualisation sur le téléviseur 119). La mémoire de programmes 117 est notamment destinée à la gestion des différentes opérations à exécuter pour mettre en oeuvre différentes fonc- tionnalités du décodeur 108. Elle comporte plusieurs moyens logiciels (i.e. applications) dont certains sont dédiés à la mise en oeuvre de l'invention. Dans d'autres exemples de réalisation du décodeur 108, ces moyens logiciels pourraient être remplacés par des circuits électroniques spécifiques. Ainsi, la mémoire de programmes 117 comporte : - des moyens 120 pour adapter le temps de mise en mémoire tampon des paquets en vue de performance de restitution améliorée, - des moyens 121 pour déterminer localement la valeur d'au moins un des indicateurs de qualité de service 135, 136 et/ou 137, - des moyens 122 de calcul du ratio de la valeur moyenne de l'indica-teur de QoS sur la durée de visualisation. Ainsi, le décodeur 108 mémorise localement en permanence des données de suivi d'au moins un indicateur de QoS 135, 136 et/ou 137 via les moyens 121.
Au bout d'une période prédéterminée (qui peut être par exemple un jour, une semaine ou un mois), le décodeur 108 calcul le ratio de la valeur moyenne de l'un des indicateur de QoS (par exemple le nombre de paquets manquants 135) sur la durée d'utilisation 138. Si ce ratio dépasse un certain seuil, le décodeur 108 va activer ses moyens 120 afin d'augmenter le temps de stockage dans la mémoire tampon réseau 110 des paquets en vue de performance de restitution améliorée de l'image. Inversement si ce ratio passe au-dessous d'un autre seuil, le décodeur 108 peut décider de baisser le temps de stockage dans la mémoire tampon réseau 110 afin d'améliorer le délai de trick mode dans le cas de la VoD ou le temps de connexion (zapping) dans le cas d'un flux de TV sans voie de retour. Ainsi, périodiquement, le décodeur 108 réajuste le temps de bufferisation. Les moyens 121 pour déterminer localement la valeur d'au moins un indicateur de QoS comporte également des moyens de réinitialisation à zéro de la valeur de QoS après chaque ajustement du temps de bufferisation. Chaque décodeur 108 s'adapte à la qualité de la ligne de transmission en fonction d'un ou des indicateurs de QoS calculés localement (donc sans commande d'un signal provenant du réseau); un décodeur qui a une très bonne qualité de réception (par exemple parce que la transmission se fait par fibre optique ou parce que l'abonné est situé près du DSLAM) aura un trick mode quasi instantané dans le cas de la VoD, un temps de connexion quasi instantané dans le cas d'un flux de TV sans voie de retour et un temps de bufferisation réduit parce que l'indicateur de QoS indiquera une bonne qualité. Inversement, pour un abonné qui habite près d'un as-censeur ou du tramway et qui a beaucoup de problème de qualité de réception (perturbations électromagnétiques par exemple), il y aura une bufferisation plus importante de manière à privilégier la qualité d'image (et donc un trick mode de VoD ou un temps de connexion TV plus long). Le décodeur 108 est donc un système intelligent avec une auto-adaptation dy- namique et locale en fonction de la qualité de service sans aucune modification du temps de bufferisation qui serait pilotée par le réseau. On notera que le décodeur selon l'invention fonctionne par apprentis-sage. En d'autres termes, le réglage du temps de bufferisation sera d'autant plus fin à mesure que le décodeur aura un historique plus important des va-leurs de QoS (i.e. les moyens 120 pour adapter le temps de mise en mémoire tampon des paquets en vue de performance de restitution améliorée évoluent avec le temps par apprentissage) On peut également mettre en oeuvre une adaptation du temps de bufferisation par type de paquets de données et donc de services fournis à l'utilisateur : ainsi, selon que le service est de la télévision (désignée par le terme live en anglais) ou de la VoD, le temps de bufferisation peut être ajusté différemment par des moyens 120.
Nous allons décrire dans ce qui suit un exemple d'apprentissage pour le décodeur selon l'invention. Sur certains bouquets TV, coexistent différents types de services avec des débits différents : - des chaines diffusés en MPEG-2 dont les débits sont de l'ordre de 4 Mbit/s : ces services seront appelés par la suite groupe MPEG-2 - des chaines diffusés en H264 dont les débits sont de l'ordre de 1,7 Mbit/s : ces services seront appelés par la suite groupe H264 L'impact d'une mauvaise qualité de réception sur la ligne sera d'au-tant plus important que le débit est élevé : - le groupe MPEG-2 présente qualité médiocre avec un nombre d'erreur dans l'indicateur QoS élevé - le groupe H264 présente une qualité moyenne avec un nombre d'er- reur dans l'indicateur QoS faible. Supposons par ailleurs que l'utilisateur regarde principalement les chaines du groupe MPEG-2 car elles constituent le bouquet Premium. Le cycle suivant va se mettre en place : Etape 1 - Jour J : - installation du dispositif selon l'invention par l'abonné - temps de bufferisation = valeurs par défaut = 500 ms. Etape 2 - Jour J + 2 : - les indicateurs sont les suivants : o groupe MPEG-2 : indicateur QoS très mauvais et durée de visualisation = 5 h. o groupe H264 : indicateur QoS moyen et durée de visualisa- tion = 20 minutes Etape 3 - Jour J + 2 : - le dispositif augmente la bufferisation au maximum (même bufferisa- tion quelque soit les services): temps de bufferisation= 2 s. Etape 4-Jour J+2: - les indicateurs sont réinitialisés à la valeur 0 Etape 5 - Jour J + 4 : - les indicateurs sont les suivants o groupe MPEG-2 : indicateur QoS excellent et durée de visualisation = 5 h. o groupe H264 : indicateur QoS excellent et durée de visualisa- tion = 20 minutes Etape 6 - Jour J + 4 : - le dispositif diminue la bufferisation: temps de bufferisation = 1 s. Etape 7 - Jour J + 4 : - les indicateurs sont réinitialisés à 0 Etape 8 - Jour J + 6 : - les indicateurs sont les suivants o groupe MPEG-2 : indicateur QoS moyen et durée de visualisa- tion = 5 h. o groupe H264 : indicateur QoS très bon et durée de visualisa- tion = 20 minutes Etape 9 - Jour J + 6 : -le dispositif augmente légèrement la bufferisation : temps de bufferi-sation = 1,2 s. Etape 10 - Jour J + 6 : - les indicateurs sont réinitialisés à 0 Etape 11 - Jour J + 8 : - les indicateurs sont les suivants o groupe MPEG-2 : indicateur QoS bon et durée de visualisation =5h. o groupe H264 : indicateur QoS excellent et durée de visualisation = 20 minutes Etape 12 - Jour J + 8: - le dispositif décide de ne pas modifier les paramètres car : o groupe MPEG-2 a un rapport d'indicateur QoS sur durée de visualisation significative qui est satisfaisant o groupe H264 : indicateur "trop" bon (temps de zapping inutile-ment impacté) mais avec une durée de visualisation non significative Etape 13 - Jour J + 20 : - les indicateurs sont les suivants : o groupe MPEG-2 : indicateur QoS moyen/bon et durée de visualisation = 30 h. o groupe H264 : indicateur QoS excellent et durée de visualisation = 2 h (considérée comme une durée significative) Etape 14 - Jour J + 20 : - le dispositif décide un traitement différencié suivant le type de servi-ces : o groupe MPEG-2 : temps de bufferisation légèrement augmenté à 1,3 s o groupe H264 : temps de bufferisation diminué à 0,8 s. Etape 15 - Jour J + 20 : 25 - les indicateurs sont réinitialisés à 0 Etape 16- Jour J + 30 : - les indicateurs sont les suivants : o groupe MPEG-2 : indicateur QoS bon et durée de visualisation =20h. 30 o groupe H264 : indicateur QoS bon et durée de visualisation = 2 h. Etape 17 : - Pas de changement opéré par le dispositif. 15 20 Dans cet exemple, il a fallu 30 jours pour que le dispositif selon l'invention s'adapte au mieux. Mais si l'opérateur change des paramètres de diffusion (par exemple parce qu'une partie des services du Bouquet Premium passe en H264 ou parce que l'utilisateur utilise un module Wifi (qui rajoute des perturbations) entre le décodeur et le modem ADSL), les para-mètres se réajusteront à nouveau automatiquement. Même si la détermination des indicateurs de QoS est faite en temps réel, il convient de noter que la modification du temps de mise en mémoire tampon ne prendra effet qu'à la prochaine connexion sur un flux du déco- deur 108 (correspondant par exemple un zapping dans le cas d'un flux TV multicast ou à un trick mode dans le cas de la VoD). Une modification du temps de bufferisation en temps réel induirait inévitablement une perturbation visible pour l'utilisateur. Selon une variante de l'invention, l'adaptation du temps de mise en mémoire tampon réseau peut être réalisée à chaque dépassement par l'un des indicateurs de QoS d'un seuil critique ; par exemple, si l'indicateur de rendu audiovisuel indique une image figée toutes les 5 s, les moyens 120 vont immédiatement augmenter le temps de bufferisation et ce nouveau temps de bufferisation produira ses effets à la connexion suivante du déco- deur 108. Il est également possible de combiner les deux modes de réalisation en réalisant : - un calcul par période (jour, semaine ou mois) avec ajustement possible, - un ajustement systématique (et indépendant de la période de calcul) en cas de dépassement d'un seuil critique. Une adaptation encore plus fine peut être faite par chaîne de télévision, chaque chaîne n'ayant pas le même débit et le même niveau de codage (des chaînes peuvent utiliser plus ou moins d'images Intra par exem- ple qui influent sur le risque de perturbation). Le réglage du temps de bufferisation peut en conséquence être différent selon la chaîne de télévision. Une adaptation spécifique du temps de bufferisation pour une chaîne de télévision particulièrement regardée par l'utilisateur peut également être mise en oeuvre. Le dispositif 108 comporte alors des moyens 125 pour détecter une chaîne plus particulièrement regardée par l'utilisateur et les moyens 120 pour adapter le temps de bufferisation adaptent spécifiquement le temps de mise en mémoire des paquets correspondant à la chaîne détec- tée. En revanche, on peut garder un temps de bufferisation par défaut pour les autres chaînes de télévision. Le décodeur favorise ainsi la qualité d'image de la chaîne la plus regardée. Bien entendu, l'invention n'est pas limitée au mode de réalisation qui vient d'être décrit.
Notamment, dans l'exemple illustré, le mode de réalisation fait référence à un dispositif de réception de paquets en continu qui est un décodeur de télévision numérique. L'invention s'applique tout aussi bien à un dispositif de réception incorporé au modem ADSL, voire même à un dispositif de réception de paquets indépendant localisé entre le modem ADSL et le déco- deur. En outre, l'invention s'applique à d'autres types de terminaux de réception de paquets de données en streaming tels que des terminaux mobiles (téléphone ou assistant personnel). En revanche, l'invention ne concerne pas les dispositifs de réception ayant des temps de bufferisation supérieurs à 3 s tels que les micro-ordinateurs. Enfin, on pourra remplacer tout moyen par un moyen équivalent

Claims (12)

REVENDICATIONS
1. Dispositif de réception (108) en continu de paquets de données audio et/ou vidéo transmis depuis un serveur source (101) via un réseau (104), ledit dispositif de réception (108) comprenant : - une mémoire tampon réseau (110) dans laquelle peuvent être mémorisés lesdits paquets, ladite mémoire tampon réseau (110) présentant un temps de mise en mémoire tampon variable, - des moyens (120) pour adapter le temps de mise en mémoire tampon desdits paquets en vue de performance de restitution améliorée des-dits paquets, ledit dispositif (108) étant caractérisé en ce qu'il comporte des moyens (121) pour déterminer localement la valeur d'au moins un indicateur (135, 136, 137) de qualité de service, lesdits moyens (120) pour adapter le temps de mise en mémoire tampon adaptant ledit temps en fonction de ladite va-leur de l'indicateur (135, 136, 137).
2. Dispositif de réception (108) selon la revendication précédente caractérisé en ce que le temps de mise en mémoire tampon est inférieur à 3 s.
3. Dispositif de réception (108) selon l'une des revendications précé-dentes caractérisé en ce que le temps de mise en mémoire tampon est supérieur à 100 ms.
4. Dispositif de réception (108) selon l'une des revendications précédentes caractérisé en ce que ledit au moins un indicateur de qualité de service est choisi parmi les indicateurs suivants : - le nombre de paquets manquants (135), - la latence lors de demande de paquet manquant (136), - le rendu audiovisuel (137).
5. Dispositif de réception (108) selon l'une des revendications précédentes caractérisé en ce que lesdits moyens (120) pour adapter le temps de mise en mémoire tampon adaptent ledit temps en fonction du ratio entre la-dite valeur d'au moins un indicateur (135) de qualité de service et la durée d'utilisation (138) dudit dispositif de réception.
6. Dispositif de réception (108) selon l'une des revendications précédentes caractérisé en ce que lesdits moyens (120) pour adapter le temps de mise en mémoire tampon adaptent ledit temps lorsque ladite valeur d'au moins un indicateur (137) de qualité de service dépasse un seuil critique.
7. Dispositif de réception (108) selon l'une des revendications précédentes caractérisé en ce que lesdits moyens (120) pour adapter le temps de mise en mémoire tampon sont adaptés en fonction du type de paquets de données.
8. Dispositif de réception (108) selon la revendication précédente ca-ractérisé en ce que lesdits moyens (120) pour adapter le temps de mise en mémoire tampon réagissent différemment selon que les paquets de don-nées sont du type vidéo à la demande ou télévision.
9. Dispositif de réception (108) selon l'une des revendications 7 ou 8 caractérisé en ce que les paquets de données sont des paquets correspon-dant à un signal de télévision, ledit dispositif comportant des moyens (125) pour détecter une chaîne plus particulièrement regardée par l'utilisateur et lesdits moyens (120) pour adapter le temps de mise en mémoire tampon adaptant spécifiquement le temps de mise en mémoire des paquets correspondant à ladite chaîne détectée.
10. Dispositif de réception (108) selon l'une des revendications précédentes caractérisé en ce que lesdits moyens (121) pour déterminer localement la valeur d'au moins un indicateur (135, 136, 137) de qualité de service comportent des moyens de réinitialisation de ladite valeur.
11. Dispositif de réception (108) selon l'une des revendications pré-cédentes caractérisé en ce que lesdits moyens (120) pour adapter le temps de mise en mémoire tampon des paquets en vue de performance de restitution améliorée évoluent avec le temps par apprentissage.
12. Dispositif de réception (108) selon l'une des revendications précédentes caractérisé en ledit dispositif est un décodeur de télévision numé- rique.
FR0758195A 2007-10-10 2007-10-10 Dispositif de reception en continu de paquets de donnees audio et/ou video Expired - Fee Related FR2922401B1 (fr)

Priority Applications (7)

Application Number Priority Date Filing Date Title
FR0758195A FR2922401B1 (fr) 2007-10-10 2007-10-10 Dispositif de reception en continu de paquets de donnees audio et/ou video
BRPI0817882A BRPI0817882A2 (pt) 2007-10-10 2008-10-06 dispositivo de recepção em contínuo de pacotes de dados áudio e/ou vídeo
PCT/FR2008/051801 WO2009053595A1 (fr) 2007-10-10 2008-10-06 Dispositif de reception en continu de paquets de donnees audio et/ou video
CN200880110550A CN101822048A (zh) 2007-10-10 2008-10-06 用于流式接收音频和/或视频数据分组的设备
EP08842934A EP2218256A1 (fr) 2007-10-10 2008-10-06 Dispositif de reception en continu de paquets de donnees audio et/ou video
US12/682,362 US20100299448A1 (en) 2007-10-10 2008-10-06 Device for the streaming reception of audio and/or video data packets
CO10041379A CO6382187A2 (es) 2007-10-10 2010-04-09 Dispositivo para la recepcion en flujo de paquestes de datos audio y/o video

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0758195A FR2922401B1 (fr) 2007-10-10 2007-10-10 Dispositif de reception en continu de paquets de donnees audio et/ou video

Publications (2)

Publication Number Publication Date
FR2922401A1 true FR2922401A1 (fr) 2009-04-17
FR2922401B1 FR2922401B1 (fr) 2010-04-16

Family

ID=39367002

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0758195A Expired - Fee Related FR2922401B1 (fr) 2007-10-10 2007-10-10 Dispositif de reception en continu de paquets de donnees audio et/ou video

Country Status (7)

Country Link
US (1) US20100299448A1 (fr)
EP (1) EP2218256A1 (fr)
CN (1) CN101822048A (fr)
BR (1) BRPI0817882A2 (fr)
CO (1) CO6382187A2 (fr)
FR (1) FR2922401B1 (fr)
WO (1) WO2009053595A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8010692B1 (en) * 2009-11-05 2011-08-30 Adobe Systems Incorporated Adapting audio and video content for hardware platform
US9491505B2 (en) 2012-02-28 2016-11-08 Qualcomm Incorporated Frame capture and buffering at source device in wireless display system
US10841352B2 (en) * 2012-11-27 2020-11-17 International Business Machines Corporation Non-chronological buffering of segments of a media file
JP6593053B2 (ja) * 2015-09-15 2019-10-23 株式会社リコー コンテンツ再生装置、コンテンツ再生方法、コンテンツ再生プログラム
KR102479513B1 (ko) * 2018-02-26 2022-12-21 삼성전자주식회사 전자장치 및 그 제어방법

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1104958A2 (fr) * 1999-11-15 2001-06-06 Siemens Information and Communication Networks Inc. Algorithme pour ajustement de mémoire pour gigue
EP1146678A1 (fr) * 2000-04-14 2001-10-17 Alcatel Mémoire tampon auto-adaptative de gigue
US20020194609A1 (en) * 2001-06-18 2002-12-19 Tran Thanh T. Video client with dynamically allocable video buffer for efficiently streaming video
EP1349334A1 (fr) * 2002-03-28 2003-10-01 Siemens Schweiz AG Methode pour ajuster la mémoire-gigue dans une passerelle de media
WO2004072766A2 (fr) * 2003-02-13 2004-08-26 Nokia Corporation Procede et dispositif d'adaptation de debit pour la diffusion multimedia
FR2888441A1 (fr) * 2005-07-11 2007-01-12 Thomson Licensing Sas Soc Par Appareil et procede d'estimation du taux de remplissage des tampons d'entree de clients d'une distribution de contenu temps reel.
EP1775964A1 (fr) * 2005-10-11 2007-04-18 Huawei Technologies Co., Ltd. Méthode et dispositif pour synchronisation d'un flux de données audiovisuelles en temps réel via un réseau de commutation de paquets

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6377972B1 (en) * 1999-01-19 2002-04-23 Lucent Technologies Inc. High quality streaming multimedia
AU2002220110A1 (en) * 2000-12-05 2002-06-18 Starguide Digital Networks, Inc. Method and apparatus for ip multicast content distribution system having national and regional demographically targeted advertisement insertion
US7095729B2 (en) * 2000-12-22 2006-08-22 Intel Corporation Method for multimedia communication over packet channels
US20020085536A1 (en) * 2000-12-29 2002-07-04 Rudrapatna Ashok N. System and method for implementing a wireless isochronous data service
US7130316B2 (en) * 2001-04-11 2006-10-31 Ati Technologies, Inc. System for frame based audio synchronization and method thereof
KR101029495B1 (ko) * 2003-01-31 2011-04-18 코닌클리케 필립스 일렉트로닉스 엔.브이. 저장된 대화형 ｔｖ 애플리케이션들의 재생의 성능을향상시키는 애플리케이션 간 제어
US7088741B2 (en) * 2003-05-01 2006-08-08 Genesis Microchip Inc. Using an auxilary channel for video monitor training
KR100782835B1 (ko) * 2005-01-29 2007-12-06 삼성전자주식회사 캡션 정보의 출력시점 및 출력 우선순위를 조절하는 방법및 그 장치
US7616664B2 (en) * 2005-02-18 2009-11-10 Hewlett-Packard Development Company, L.P. System and method of sending video and audio data over a network
EP1879347B1 (fr) * 2006-07-14 2012-05-30 Sony Europe Limited Système et procédé de transmission audio-vidéo en continu

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1104958A2 (fr) * 1999-11-15 2001-06-06 Siemens Information and Communication Networks Inc. Algorithme pour ajustement de mémoire pour gigue
EP1146678A1 (fr) * 2000-04-14 2001-10-17 Alcatel Mémoire tampon auto-adaptative de gigue
US20020194609A1 (en) * 2001-06-18 2002-12-19 Tran Thanh T. Video client with dynamically allocable video buffer for efficiently streaming video
EP1349334A1 (fr) * 2002-03-28 2003-10-01 Siemens Schweiz AG Methode pour ajuster la mémoire-gigue dans une passerelle de media
WO2004072766A2 (fr) * 2003-02-13 2004-08-26 Nokia Corporation Procede et dispositif d'adaptation de debit pour la diffusion multimedia
FR2888441A1 (fr) * 2005-07-11 2007-01-12 Thomson Licensing Sas Soc Par Appareil et procede d'estimation du taux de remplissage des tampons d'entree de clients d'une distribution de contenu temps reel.
EP1775964A1 (fr) * 2005-10-11 2007-04-18 Huawei Technologies Co., Ltd. Méthode et dispositif pour synchronisation d'un flux de données audiovisuelles en temps réel via un réseau de commutation de paquets

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SEN S ET AL: "Proxy prefix caching for multimedia streams", INFOCOM '99. EIGHTEENTH ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER A ND COMMUNICATIONS SOCIETIES. PROCEEDINGS. IEEE NEW YORK, NY, USA 21-25 MARCH 1999, PISCATAWAY, NJ, USA,IEEE, US, vol. 3, 21 March 1999 (1999-03-21), pages 1310 - 1319, XP010323883, ISBN: 978-0-7803-5417-3 *

Also Published As

Publication number Publication date
BRPI0817882A2 (pt) 2019-09-24
WO2009053595A1 (fr) 2009-04-30
CO6382187A2 (es) 2012-02-15
EP2218256A1 (fr) 2010-08-18
CN101822048A (zh) 2010-09-01
FR2922401B1 (fr) 2010-04-16
US20100299448A1 (en) 2010-11-25

Similar Documents

Publication Publication Date Title
US10623785B2 (en) Streaming manifest quality control
US9641578B2 (en) Minimizing unicast bandwidth in an adaptive bit rate system
US10368075B2 (en) Clip generation based on multiple encodings of a media stream
EP3348067B1 (fr) Changement de canal rapide dans un réseau de diffusion en continu à débit binaire adaptatif de multidiffusion (mabr) en utilisant des rafales de segment de répétition de multidiffusion dans un tuyau de téléchargement abr progressif partagé
CA2618328C (fr) Systeme de transmission en continu de video a la demande flexible et multisource pour une communaute d'abonnes entre homologues
US9100461B2 (en) Automatically publishing streams to multiple destinations
US9113182B2 (en) Selecting a media content source based on monetary cost
EP1908259B1 (fr) Appareil et procede d'estimation du taux de remplissage des tampons d'entree de clients d'une distribution de contenu temps reel
US9253545B2 (en) Routing media content based on monetary cost
FR2922401A1 (fr) Dispositif de reception en continu de paquets de donnees audio et/ou video
US20220295127A1 (en) Consolidating content streams to conserve bandwidth
Okerman et al. Fast startup multicast streaming on operator iptv networks using hesp
FR2980662A1 (fr) Methode d'enregistrement d'un contenu dans un fichier sur un serveur et dispositif correspondant
EP2129130A1 (fr) Procédé de transmission simplifié d'un flux de signaux entre un émetteur et un appareil électronique
EP2075960B1 (fr) Système et procédé d'adaptation des flux de contenu vidéo à la variabilité des conditions de transmission d'un réseau radiotéléphonique et à la dynamique du contenu de la source vidéo
WO2014006092A1 (fr) Dispositif et procede d'enregistrement de donnees relatifs a une fonction de decalage temporel sur un support d'enregistrement
EP3973714A1 (fr) Restitution d'un contenu en arrière-plan ou sous forme d'incrustation dans le cadre d'un téléchargement progressif adaptatif de type has
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
FR2905221A1 (fr) Procede et systemes pour optimiser la transmission d'un flux de donnees.
EP2087733A1 (fr) Procédé de retardement temporel de flux de contenus numériques, dispositif, et produit programme d'ordinateur correspondants

Legal Events

Date Code Title Description
CA Change of address
CD Change of name or company name
CJ Change in legal form
TP Transmission of property

Owner name: SAGEMCOM BROADBAND SAS, FR

Effective date: 20111215

ST Notification of lapse

Effective date: 20130628