FR2975555A1 - Methode d'adaptation dynamique du debit de reception et recepteur associe - Google Patents

Methode d'adaptation dynamique du debit de reception et recepteur associe Download PDF

Info

Publication number
FR2975555A1
FR2975555A1 FR1154334A FR1154334A FR2975555A1 FR 2975555 A1 FR2975555 A1 FR 2975555A1 FR 1154334 A FR1154334 A FR 1154334A FR 1154334 A FR1154334 A FR 1154334A FR 2975555 A1 FR2975555 A1 FR 2975555A1
Authority
FR
France
Prior art keywords
server
receiver
program
versions
audiovisual program
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.)
Withdrawn
Application number
FR1154334A
Other languages
English (en)
Inventor
Stephane Gouache
Yvon Legallais
Philippe Gilberton
Original Assignee
Thomson Licensing 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
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Priority to FR1154334A priority Critical patent/FR2975555A1/fr
Priority to KR1020137030154A priority patent/KR102012528B1/ko
Priority to CA2835384A priority patent/CA2835384A1/fr
Priority to PCT/EP2012/058187 priority patent/WO2012156211A1/fr
Priority to RU2013156038/08A priority patent/RU2598805C2/ru
Priority to CN201280023415.XA priority patent/CN103548318B/zh
Priority to MYPI2013003857A priority patent/MY168875A/en
Priority to US14/117,973 priority patent/US10015225B2/en
Priority to EP12718240.0A priority patent/EP2710778B1/fr
Priority to MX2013013373A priority patent/MX2013013373A/es
Priority to JP2014510722A priority patent/JP6436772B2/ja
Priority to TW101115870A priority patent/TWI573450B/zh
Priority to HUE12718240A priority patent/HUE026744T2/en
Publication of FR2975555A1 publication Critical patent/FR2975555A1/fr
Priority to HK14108202.1A priority patent/HK1194882A1/zh
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051—Service on demand, e.g. definition and deployment of services in real time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H04L45/3065—Route determination based on the nature of the carried application for real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by 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/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • 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/752—Media network packet handling adapting media to network 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/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/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/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • 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/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • 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/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • 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/6377—Control signals issued by the client directed to the server or network components directed to server
    • H04N21/6379—Control signals issued by the client directed to the server or network components directed to server directed to encoder, e.g. for requesting a lower encoding rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Selective Calling Equipment (AREA)

Abstract

Procédé de réception d'un programme audiovisuel transmis par portions sur un réseau, le procédé utilisant le protocole de transport RTP et le protocole de contrôle RTSP entre un serveur et un récepteur, le programme audiovisuel étant disponible sur le serveur dans une pluralité de versions correspondant au programme encodé dans différentes résolutions et permettant sa transmission à différents débits selon des requêtes du récepteur. Le procédé comprenant une mesure régulière de la bande passante du réseau par le récepteur en vue de d'ajuster le débit de transmission en fonction de l'état du réseau.

Description

1. Domaine de l'invention.
L'invention se rapporte au domaine des récepteurs de programmes audiovisuels et plus particulièrement à l'adaptation dynamique du programme en fonction de la bande passante disponible sur le réseau lors de l'émission d'un programme utilisant le protocole de transmission RTP (de l'anglais Real-Time Transfer Protocol) et le protocole de contrôle de serveur RTSP (de l'anglais Real-Time Streaming Protocol) associé à RTP pour la transmission en streaming.
2. Etat de l'art.
Le téléchargement d'un programme en vue de sa visualisation impose le transfert complet du programme audiovisuel sur le récepteur avant la restitution. Afin d'éviter les contraintes qui y sont associées, telles que la nécessité d'attendre la fin du téléchargement ou de disposer d'une mémoire de stockage suffisante pour l'intégralité du programme, l'usage du streaming (de l'anglais, émission du programme en continu pendant sa visualisation) s'est largement répandu.
Les protocoles de streaming connus incluent RTP (RFC3550 et RFC associés selon le format des données transportées), associé au protocole de contrôle de serveur (RFC2326) et MPEG TS/UDP (de Motion Picture Expert Group Transport Stream / User Datagram Protocol) alors que le téléchargement s'appuie généralement sur le protocole HTTP (de Hyper Text Transfer Protocol).
Les réseaux de communication modernes offrent des capacités en bande passante qui permettent la transmission de programmes audiovisuels en continu ou streaming. La transmission peut se faire à travers des réseaux tels qu'internet, entre un serveur et un client. Le streaming est une méthode de transmission par laquelle le programme audiovisuel transmis est décomposé en portions temporelles successivement transmises sur le réseau tout au long de la transmission et de la restitution. La transmission et la restitution sont simultanées, outre un léger décalage lié à l'utilisation d'une mémoire tampon sur le récepteur.
Le standard 3GPP (3GPP, TSGS-SA, Transparent end-to-end packet switched streaming service (PSS) ; 3GPP file format (3GP), TS 26.244, V6.3.0, 2005-03) définit un format d'organisation des données et de stockage comprenant plusieurs versions d'un même programme correspondant à des débits différents. Ce format, associé à une logique de contrôle sur un serveur de programmes, permet de s'adapter aux conditions et notamment aux variations de bande passante liées à l'utilisation du réseau. Cette logique de contrôle implémentée sur le serveur n'est toutefois pas spécifiée dans le standard 3GPP.
Dans le format 3GPP les données sont encodées pour se conformer à une contrainte de débit sur un lien de transmission pour un débit fixé : lorsque les données sont des images, l'encodage consiste à adapter la résolution des images pour permettre leur transport sur un lien plus ou moins passant. Mais 3GPP ne définit cependant pas de moyen de commutation permettant de modifier la résolution des images transmises pour ajuster la réception des données aux variations de la bande passante. Des méthodes sont connues pour résoudre ce problème : elles s'appuient sur des données transmises du client vers le serveur, telles que les RRs (de l'anglais Receiver Reports) définis dans le protocole RTCP (de l'anglais Real-Time Control Protocol) et qui nécessitent des étapes de traitement et d'interprétation par le serveur en vue de définir si la transmission doit s'effectuer à un autre débit.
La technologie HTTP streaming a été récemment portée à la connaissance du grand public par Apple pour son iPhone et par Microsoft pour son Smoothstreaming. La technologie HTTP streaming n'est pas utilisée jusqu' alors dans les récepteurs IPTV (de l'anglais «Internet Protocol TeleVision») dont le fonctionnement s'appuie sur les protocoles de transmission RTP et RTSP.
Les méthodes de transmission utilisées aujourd'hui en IPTV ne permettent pas une adaptation dynamique du débit en fonction de la bande passante disponible sur le réseau sans utilisation d'un serveur spécifique.
Aussi, lorsque les conditions d'accès au serveur se dégradent, un risque d'interruption du service survient au niveau du récepteur. RTP est un protocole utilisé pour l'encapsulation et la transmission temps-réel de données codant un programme audiovisuel. Le codage utilisé pour les données est généralement du type MPEG-TS ou un format équivalent. RTSP est un protocole de communication permettant le contrôle d'un serveur de média à distance. Ce protocole offre les fonctionnalités typiques d'un lecteur vidéo, telles que « LECTURE » (ou PLAY) et « PAUSE » et permet d'effectuer la lecture d'une portion de programme audiovisuel à partir de la position temporelle de la portion de programme dans le programme.
Lors des transmissions de programmes audiovisuels en streaming utilisant les protocoles RTP, RTSP, des modifications importantes de disponibilité du réseau ont une incidence forte sur la restitution des programmes. Le débit n'étant pas ajusté dynamiquement entre le début et la fin d'une transmission. Des interruptions surviennent alors, ce qui représente un désagrément important pour l'utilisateur. Le protocole de transport RTP s'appuie sur le protocole UDP, et le protocole HTTP s'appuie sur le protocole connecté TCP.
TCP est un protocole dit « connecté » qui répond à des contraintes de fiabilité, il permet de transmettre des données sans erreur de paquets d'un serveur à un récepteur. Pour cela, le récepteur communique avec le serveur en lui indiquant les données reçues. Outre le fait d'être dépendant des données perdues et réémises, le débit moyen est lié à l'acheminement des accusés de réception. Plus le temps d'acheminement est élevé et plus le débit maximum sera réduit.
UDP est un protocole qui ne répond pas aux mêmes contraintes de fiabilité. Il est dit « non fiable » et « sans connexion ». Il est dépourvu de système d'acquittement et son débit moyen n'est pas lié à la distance entre le serveur et le récepteur. C'est pour cette raison que le protocole UDP est utilisé avec RTP dans les applications IPTV. L'un des buts de l'invention est de combiner les avantages d'UDP tout en étant capable d'adapter dynamiquement le débit aux conditions du réseau. 3. Résumé de l'invention.
L'invention a pour but de palier au moins un des inconvénients de l'art antérieur et plus spécifiquement de permettre un contrôle dynamique de la bande passante utilisée lors de la transmission de programmes audiovisuels pour les infrastructures classiques IPTV telles que celles utilisant les protocoles RTP et RTSP.
Une utilisation du protocole de contrôle RTSP adaptée selon l'invention permet au récepteur de demander au serveur la transmission du programme audiovisuel par portions successives. Le récepteur mesure périodiquement, pour chacune des portions transmises, les conditions de transmission du réseau et ajuste le débit de transmission en conséquence.
L'ajustement du débit de transmission est réalisé par le récepteur en sélectionnant, pour chaque portion du programme successivement demandée au serveur, une version du programme parmi plusieurs versions encodées à des débits différents et disponibles sur le serveur. La sélection de la version par le récepteur est faite en fonction du débit de transmission mesuré lors de la transmission de la portion précédente. De cette façon, l'ajustement du débit ne requiert pas de modification du serveur de programmes.
L'invention concerne un procédé de réception d'un programme audiovisuel stocké sur un serveur en vue d'une lecture sur un dispositif d'affichage connecté à un récepteur, le programme audiovisuel étant disponible sur le serveur dans au moins deux versions, chacune des versions comprenant une succession temporelle de blocs de données, les versions comprenant chacune un même nombre de blocs, les blocs commençant chacun par une image encodée sans référence à une image précédente. Selon l'invention, le procédé comprend les étapes, au niveau du récepteur, de réception, selon le protocole de transport RTP, d'une première portion du programme audiovisuel comprenant au moins un bloc de données issu d'une première des versions transmise par le serveur à un premier débit, de détermination de la bande passante après réception de la première portion du programme audiovisuel transmise par ledit serveur au premier débit, d'émission d'une requête vers le serveur, selon le protocole de contrôle RTSP, la requête comprenant des informations d'identification d'une seconde portion du programme audiovisuel dans une des versions du programme en fonction de la valeur déterminée de la bande passante entre le serveur et le récepteur et un paramètre de vitesse de transmission, les informations d'identification comprenant des repères temporels de début et de fin de la seconde portion.
Selon un mode de réalisation de l'invention, les étapes de réception, de détermination de la bande passante et d'émission d'une requête par le récepteur sont reproduites itérativement au cours de la réception du programme audiovisuel.
Selon un mode de réalisation de l'invention, les versions du programme audiovisuel sont comprises dans un même fichier stocké sur le serveur.
Selon un mode de réalisation de l'invention, le programme audiovisuel est associé sur le serveur à un fichier de description comprenant des informations relatives à la localisation des versions du programme audiovisuel dans le même fichier.
Selon un mode de réalisation de l'invention, la détermination de la bande passante disponible entre le serveur et le récepteur comprend une analyse d'au moins une caractéristique des portions du programme audiovisuel reçues au premier débit.
Selon un mode de réalisation de l'invention, au moins une caractéristique des portions est le nombre de bits transmis.
Selon un mode de réalisation de l'invention, l'étape d'émission 5 d'une requête utilise la commande PLAY du protocole RSTP.
L'invention concerne également un dispositif de réception d'un programme audiovisuel diffusé par un serveur, le programme étant disponible sur le serveur dans au moins deux versions, chacune des 10 versions correspondant à une résolution d'image du programme audiovisuel et comprenant une succession de portions, les versions comprenant chacune un même nombre de portions et les portions commençant chacune par une image intra. Selon l'invention, le dispositif comprend des moyens de réception, selon le protocole de transport RTP, d'une première portion du 15 programme audiovisuel dans une première des versions transmises par ledit serveur à un premier débit, des moyens de détermination de la bande passante après réception de la première portion dudit programme audiovisuel transmise par le serveur au premier débit et des moyens d'émission d'une requête vers le serveur, selon le protocole de contrôle 20 RSTP, la requête comprenant des informations d'identification d'une seconde portion du programme audiovisuel dans une des versions du programme en fonction de la valeur déterminée de la bande passante entre le serveur et le récepteur et un paramètre de vitesse de transmission, les informations d'identification comprenant des repères temporels de début et de fin de la 25 seconde portion.
Le débit de transmission est ainsi ajusté pour s'adapter à la bande passante disponible sur le réseau et éviter des interruptions lors de la 30 restitution du programme audiovisuel, quitte à restituer le programme dans une qualité moindre. . Liste des figures.
L'invention sera mieux comprise, et d'autres particularités et avantages apparaîtront à la lecture de la description qui va suivre, la description faisant référence aux dessins annexés parmi lesquels :
- la figure 1 illustre un système de réception de programmes audiovisuels au moyen d'un récepteur / décodeur selon un mode de réalisation de l'invention.
- la figure 2 illustre une méthode d'encodage permettant la création d'un fichier contenant plusieurs versions d'un même programme. - la figure 3 illustre un fichier du serveur comprenant plusieurs versions d'un même programme audiovisuel encodées pour être diffusés à différents débits selon un mode de réalisation de l'invention.
- la figure 4 illustre schématiquement une séquence de messages d'initialisation entre un récepteur et un serveur en vue de la transmission d'un flux selon le protocole de transmission RTP.
- la figure 5 illustre une séquence de messages d'initialisation entre un récepteur et un serveur en vue de la transmission d'un flux selon un mode de réalisation de l'invention.
- la figure 6 est un diagramme qui illustre la méthode mise en oeuvre dans un récepteur, comprenant une évaluation régulière de la bande passante du réseau et l'émission de requêtes comprenant un paramètre de débit et un paramètre de vitesse de transmission adaptés à l'état du réseau.
- La figure 7 est un diagramme fonctionnel d'un récepteur selon un mode de réalisation de l'invention. - La figure 8 est un diagramme fonctionnel illustrant l'unité de contrôle du récepteur décrit sur la figure 7. 7 5. Description détaillée de l'invention.
De manière générale mais non limitative, l'invention concerne un procédé de réception d'un programme audiovisuel en streaming, permettant une adaptation dynamique du débit utilisé pour l'émission du programme selon la congestion du réseau déterminée par une mesure régulière de la bande passante.
La figure 1 illustre un système de réception de programmes audiovisuels par un récepteur 2 à travers un réseau 3. Lors de la réception, le récepteur traite le programme audiovisuel et transmet des signaux au dispositif d'affichage 4 pour sa visualisation. Les programmes sont encodés et disponibles sur le serveur de programmes 1. Les programmes sont stockés sous forme de fichiers informatiques. Les techniques de transmission autorisant la transmission des programmes à des débits variables pendant la restitution nécessitent un encodage spécifique afin de rendre disponible sur le serveur le programme audiovisuel dans différentes versions correspondant à différents débits lors de l'émission des données qui codent le programme. Les différentes versions d'un même programme audiovisuel sont stockées sur le serveur de programmes 1. Les différentes versions peuvent être stockées dans des fichiers distincts ou réunies dans un même fichier et repérées par leurs positions respectives dans le fichier. Un fichier de description associé à chacun des programmes contient les informations relatives aux différentes versions, à leurs débits respectifs et à leur localisation. Ces informations sont transmises au récepteur lors d'une phase d'initialisation de la transmission du programme du serveur vers le récepteur.
La figure 2 illustre le codage d'un programme audiovisuel en vue d'être transmis avec un ajustement du débit selon les conditions de transmission sur le réseau. Le programme audiovisuel est codé en plusieurs versions. Chacune des versions correspond à une résolution d'image et donc à un débit de transmission. Dans chacune des versions le programme est constitué d'une succession de blocs ou groupes d'images. Tous les blocs correspondent à une durée de restitution (ou lecture) élémentaire du programme, par exemple 2 secondes. Ces blocs élémentaires sont couramment appelés chunks (de l'anglais), par exemple dans le cas de la technologie HTTP Adaptive streaming. La première image de chacun des blocs est une image intra. Une image intra se définit comme étant encodée sans référence à une image précédente. La position des images intra de début de bloc est la même dans chacune des versions. Ainsi, si un récepteur demande au serveur de délivrer le bloc suivant dans la continuité du programme en termes de contenu visualisé, mais dans une autre version et donc avec un autre débit de transmission, le décodeur intégré au récepteur pourra effectuer le décodage du bloc sans problème de référence à des images antérieures. La figure 2 décrit un codage d'un programme dans des versions correspondant respectivement à des débits de réception (et donc de transmission) de 500 kbits/s, 1 Mbits/s, 1,5 Mbit/s et 2 Mbit/s.
La figure 3 illustre un fichier 30 contenant plusieurs versions 31, 32, 33, 34 d'un même programme audiovisuel telles qu'issues, par exemple, d'une méthode d'encodage illustrée par la figure 2. Les différentes versions sont placées dans un même fichier avec des index différents. Le passage d'une version à l'autre pendant la transmission d'un programme correspond alors simplement à l'addition d'un index au pointeur de lecture. A chacune des valeurs possibles de l'index ajouté au pointeur correspond une version du programme audiovisuel. Le pointeur identifiant la position temporelle de la portion à restituer du programme.
La figure 4 illustre l'établissement de la communication entre un récepteur et un serveur de diffusion selon un mode de réalisation de l'invention utilisant la norme de transmission RTP. Lors de l'initialisation d'une diffusion qui utilise le protocole RTP, le récepteur adresse un premier message intitulé RTSP DESCRIBE incluant une url au serveur en vue d'obtenir du serveur des informations relatives au programme qui va être visualisé sur un dispositif d'affichage connecté au récepteur. Le terme url (de l'anglais uniform resource locator) décrit ici l'adresse réseau qui pointe sur le programme à visualiser. Cette adresse a par exemple la syntaxe « multimedia.exemple.com ». Le serveur adresse des informations au récepteur dans un message de réponse intitulé RTSP DESCRIBE RESPONSE. Le message RTSP DESCRIBE RESPONSE indique au récepteur si les versions du programmes sont stockées sur le serveur dans des fichiers séparés ou sont concaténées dans un même fichier. Une seconde requête intitulée RTSP SETUP est alors adressé au serveur par le récepteur en vue de préparer la session de streaming du programme. Si les différentes versions du programme sont stockées dans des fichiers séparés sur le serveur, le récepteur initialisera alors avec le serveur autant de session de transmission que de versions disponibles. Si les différentes versions sont concaténées dans un même fichier sur le serveur, le récepteur initiera une seule session de transmission. Dans le cas où les différentes versions du programme sont concaténées dans un même fichier, le récepteur ajoutera un index au pointeur de lecture pour passer d'une version à l'autre du programme et ajuster ainsi le débit de transmission de la portion de programme lue. Pour chaque demande d'initialisation d'une session par le récepteur, le serveur répond par un message intitulé RTSP SETUP RESPONSE. Un troisième message intitulé RTSP PLAY envoyé par le récepteur démarre la transmission du programme par le serveur. Le message RTSP Play est encore appelé requête et comprend un paramètre de repérage temporelle de la portion de programme à transmettre en vue de sa restitution. Le message PLAY comprend en outre un paramètre de vitesse indiquant au serveur à quelle vitesse transmettre les données qui correspondent à la portion de programme à transmettre.
Selon un mode de réalisation de l'invention, le contenu du programme audiovisuel est encodé selon les codecs H.264 pour la vidéo et AAC pour l'audio, la taille d'un bloc de données élémentaire commençant par une image intra correspond à 2 secondes de durée à la restitution, l'encapsulation des données est faite selon un format MPEG transport stream, et les débits associés aux différentes versions sont 500 kbits/sec, 1 Mbits/sec, 1,5 Mbit/sec et 2 Mbits/sec . Le fichier de description associé sur le serveur au fichier de contenu du programme audiovisuel et contenant des informations sur les différentes versions du programme et sur les différents débits associés est un fichier au format SDP qui a par exemple la forme suivante : v=0 o= - 1 1 I N I P4 192.168.1.33 s= Exemple multimedia stream b=RR:O a=X-keyframe-period=2 a=control:* a=range:npt=0-300 m=video 0 RTP/AVP 33 b=TIAS:500000 a=control:trackl D=0 m=video 0 RTP/AVP 33 b=TIAS:1000000 a=control:trackl D=1 m=video 0 RTP/AVP 33 b=TIAS:1500000 a=control:trackl D=2 m=video 0 RTP/AVP 33 b=TIAS:2000000 a=control:trackl D=3
Dans cet exemple de fichier SDP, les quatre flux (MPEG transport stream) sont repérés et associés à leurs débits respectifs par l'utilisation du parameter b=TIAS qui correspond à un débit exprimé en Mbit/s.
20 La figure 5 illustre l'établissement de la communication entre un récepteur et un serveur de diffusion selon un mode de réalisation de l'invention et lorsque les différentes versions du programme à visualiser sont stockées dans des fichiers distincts sur le serveur. Le récepteur initialise la réception de portion du programme audiovisuel à restituer en provenance de 25 différents flux. Lors de la restitution, et pour chaque portion de programme successivement demandée, le récepteur pointe sur le serveur la version adaptée aux conditions de bande passante sur le réseau et reçoit les données du flux correspondant. Chaque flux correspond à la transmission de données issues d'une même version. Selon un mode de réalisation, le 30 récepteur adresse autant de messages d'initialisation que de versions disponibles, préalablement à la transmission. Une fois la phase d'initialisation (SETUP) effectuée pour chacune des versions, le récepteur peut passer d'une version à l'autre en envoyant une requête PLAY spécifiant la version et l'intervalle de temps (par 35 l'utilisation de repères temporels) correspondant au bloc requis, ainsi que la vitesse de transmission. Selon d'autres modes de réalisation, le récepteur 11 10 15 peut adresser des requêtes d'initialisation SETUP avant le premier accès à une version, en cours de transmission.
La figure 6 est un bloc diagramme qui illustre la méthode utilisée par le récepteur, selon un mode de réalisation de l'invention. L'étape S1 est l'étape initiale lors de laquelle le récepteur n'a pas initialisé de réception d'un programme en streaming. A cette étape, le récepteur est en attente d'une commande de la part d'un utilisateur commandant le récepteur. A l'étape S2, le récepteur initialise une session de diffusion en streaming. Il envoie un premier message RTSP DESCRIBE en spécifiant l'adresse url cible du programme audiovisuel à recevoir du serveur en vue de sa restitution. L'adresse url peut être par exemple rtsp://exemple.com/movie/. Cette adresse cible sert de référence pour le contrôle de la diffusion. Le serveur adresse un message de type RTSP DESCRIBE RESPONSE qui indique au récepteur les propriétés des flux de transmission correspondant aux différentes versions du programme audiovisuel, encodées pour être diffusées à différents débits. Ces informations comprennent le nombre de versions, leurs identifiants respectifs, les débits d'encodage et la taille des blocs de données. Les échanges de messages suivants, RTSP SETUP émis depuis le récepteur et RTSP SETUP RESPONSE émise depuis le serveur, préparent la session de diffusion en streaming. Le récepteur mémorise les informations reçues dans la phase d'initialisation S2 et est en mesure d'adresser des requêtes RTSP PLAY successives pour la diffusion et la réception de portions (comprenant un ou plusieurs blocs de données) du programme audiovisuel. A l'étape S3, le récepteur émet une requête RTSP PLAY qui contient des paramètres propres à la diffusion de la portion de programmes à recevoir (et donc à diffuser par le serveur). La structure d'une requête RTSP PLAY selon un mode de réalisation de l'invention est :
PLAY rtsp://multimedia.exemple.com/stream/tracklD=1 RTSP/1.0 Cseq: 833 Range: npt=0-2 Speed: 1 Où PLAY indique que la requête est un message de demande de diffusion d'un bloc de données en vue de sa restitution, Cseq indique le numéro de séquence indiqué par le serveur lors de l'étape d'initialisation S2, Range indique la portion de programme correspondant à la position temporelle de 0 à 2 secondes depuis le début de la diffusion et Speed indique la vitesse de diffusion.
Afin d'éviter des interruptions lors de la restitution du programme audiovisuel, le récepteur adresse les requêtes RTSP PLAY pour la portion de programme à suivre en anticipant pour maintenir une quantité de données suffisante dans le buffer de réception. Préférentiellement, le buffer de réception contient 2 secondes de programme reçues et disponibles avant décodage. Avantageusement, et pour absorber les fluctuations de bande passante disponible sur le réseau, le buffer de réception peut contenir un nombre de données correspondant à plusieurs secondes de restitution du programme audiovisuel transmis.
Selon un mode de réalisation de l'invention et dans un but de simplification, la diffusion des blocs de données issues des différentes versions se fait lors d'une session RTSP unique. Il est donc avantageux de concaténer les différentes versions du programme encodé dans un unique fichier sur le serveur.
Si l'on considère un programme audiovisuel d'une durée d encodé avec les débit B0= 500 Kbps, B1 = 1 Mbps, B2 = 1,5 Mbps et B3 = 2 Mbps, l'accès à la ième version du programme encodé au débit B; depuis la position temporelle t, le paramètre Range de la requête RTSP PLAY correspondante sera défini par de la façon suivante : Range=ixd+t
A l'étape S4, le récepteur reçoit le bloc de données codant la portion de programme ciblée sur le serveur. Le récepteur stocke ce bloc de données dans le buffer de réception où il sera lu par le module de décodage audio / vidéo du récepteur.
L'étape S5 définit si la portion précédemment reçue en S4 était la dernière du programme, dans ce cas la diffusion prend fin.
A l'étape S6 et dans le cas où la portion de données reçue en S4 n'est pas la dernière du programme audiovisuel, en termes de position temporelle, le récepteur effectue une estimation de la bande passante disponible sur le réseau.
L'estimation de la bande passante comprend, selon un mode de réalisation de l'invention, des étapes de définition du débit de diffusion possible par le serveur et de mesure du débit sur une période prédéfinie. Avantageusement, l'estimation de la bande passante peut comprendre une étape de pondération. Selon un mode de réalisation de l'invention, l'étape de pondération comprend une étape de lissage ou d'intégration qui permet d'obtenir une valeur moyenne s'affranchissant des variations rapides de la bande passante autour de cette valeur. Le récepteur comprend une mémoire tampon (buffer de réception) capable d'absorber les variations rapides de bande passante du réseau.
Selon l'invention, l'estimation de bande passante peut être répétée pour chacun des blocs élémentaires de données ou encore pour une portion de programme comprenant un nombre prédéfini de blocs élémentaires de données.
Selon un mode de réalisation de l'invention, le récepteur utilise des informations transmises par le serveur en réponse à la requête RTSP PLAY pour réaliser l'estimation de la bande passante.
La réponse émise par le serveur à une requête RTSP PLAY a la forme suivante :
RTSP/1.0 200 0K Cseq : 834 Range : npt=0-2 RTP-Info: url=rtsp://multimedia.exemple.com/stream/tracklD=1; seq=45102; rtptime = 12345678 Où rtptime est marqueur temporel indiquant le début de la portion de programme repérée par l'intervalle npt.
Si l'on considère par exemple une horloge programme d'un flux encodé au format MPEG-2 TS ayant une valeur de 90000, communiqué au récepteur lors de l'étape d'initialisation de la session de transmission, le récepteur peut calculer un intervalle de temps rangeduration correspondant au temps de réception du bloc de données : rangeduration = rtptime end - rtptime start
Où rtptime start est la valeur du paramètre rtptime indiqué dans le champ d'information RTP-Info de la réponse du serveur, et rtptime end = rtptime du champ RTP-Info + 90000
Où 90000 est l'horloge RTP indiquée lors de la phase d'initialisation de la session de diffusion.
La débit instantané sur la période de réception du bloc de données est alors calculé en additionnant le nombre d'octets de données reçus sur l'intervalle de temps (octets qui constituent les paquets de données de la diffusion selon le protocole RTP), de multiplier le nombre d'octets par 8 pour obtenir le nombre de bits (éléments binaires) et de diviser le résultat du 25 produit par la durée de réception.
Soit une expression du débit instantané : B; = Bytes x 8 / rangeduration Selon un mode de réalisation de l'invention, la valeur du débit instantané ainsi calculée est ensuite utilisée dans un algorithme de lissage pour définir une valeur de débit plus précise.
35 L'algorithme utilise un processus itératif en vue de déterminer le débit qui peut être atteint en considérant les valeurs de débits instantanés calculés sur les itérations précédentes : 30 i est un indice qui fait référence à la ièrrie itération de calcul du débit utile et de sa variance lors de la transmission des données reçues.
Une estimation du débit à venir pour la prochaine itération est calculée ainsi :
avg;+1 = (1- a) x avg; + a x B; où B; est le débit mesuré, avg; est la moyenne calculée pour l'itération courante, a est un facteur de pondération attribué à la valeur mesurée de débit instantané.
Préférentiellement, la valeur de a est égale à 1/16.
Outre le calcul de la valeur moyenne pondérée, l'algorithme utilisé par l'invention estime la variance sur le débit. La variance est lissée de la même façon que le débit : Al = 1 B; - avg; 1 var;+1 =(1 -1 )xvar;+13xA
25 où A est la différence entre le débit mesuré est le débit moyen pour l'itération courante du calcul, var; est la variance calculée pour l'itération courante, R est un facteur de pondération pour la valeur de variance de 30 l'estimation courante.
Préférentiellement, la valeur de R est égale à 1/8.
Pour chacune des itérations de l'algorithme, l'estimation du débit 35 qui peut être atteint pour la diffusion du programme audiovisuel est calculée comme suit :20 B;max = avg; - 4 x var;
Ainsi, si la variance est grande, cela signifie que le récepteur utilise moins que la bande passante moyenne disponible. D'autre part, quand la bande passante est stable et que la variance est faible le récepteur utilise la totalité de la bande passante disponible entre le serveur et lui-même.
Avantageusement, dans le cas où le récepteur utilise toute la bande passante disponible, il adresse au serveur des requêtes RTSP PLAY visant à regrouper plusieurs portions élémentaires du programme reçu, ceci afin d'éviter de surcharger le serveur par des requêtes très régulières. Le récepteur peut par exemple demander lors de la même requête au serveur deux ou quatre blocs élémentaires de données.
Selon un mode de réalisation de l'invention, lorsque la variance est trop importante, par exemple si sa valeur est supérieure à la moitié de la valeur de débit, les estimations de débit et de variance sont calculées comme suit : avg;+1 = ( avg; + B;) / 2 et vari+1 = avgi+1 / 10
25 Selon une variante de l'invention, le récepteur détermine si le réseau permet la diffusion à un débit supérieur au débit courant en pointant sur la même version du programme audiovisuel et en modifiant le paramètre speed défini dans le protocole de contrôle RTSP. Si le débit courant est par exemple de 1,5 Mbits/s, le récepteur évalue la capacité du réseau à 30 transmettre à 2 Mbits/s en envoyant une requête au serveur spécifiant un paramètre « Speed » avec la valeur Speed=1.34.
Une requête RTSP transmise en vue de recevoir le bloc de données correspondant à l'intervalle de temps entre la deuxième et la 35 quatrième seconde du programme audiovisuel localisé par l'url « multimedia.exemple.com/stream » à un débit de 2 Mbits/s alors que le20 débit de diffusion courant est de 1,5 Mbits/sec a par exemple la forme suivante :
PLAY rtsp://multimedia.exemple.com/stream/tracklD=1 RTSP/1.0 Cseq: 833 Range: npt=2-4 Speed: 1.34
A l'étape S7, le récepteur définit les paramètres de la requête à adresser au serveur en tenant compte du résultat du calcul de la bande passante disponible et de la variance de la bande passante. Selon un mode de réalisation de l'invention, le récepteur modifie le paramètre de vitesse speed de la requête RTSP en fonction des combinaisons de valeurs calculées de la bande passante et de la variance. Par exemple, selon une variante de l'invention et dans le cas d'une congestion du réseau qui peut entrainer non seulement une diminution de la vitesse de transmission, mais aussi la perte de données, le récepteur effectue une nouvelle requête en vue de recevoir les données perdues dans une version correspondant à un débit moindre et à une vitesse de transmission accrue. L'utilisation d'un débit moindre et d'une vitesse de transmission accrue permet d'une part de réduire la quantité de données qui transitent entre le serveur et le récepteur, mais aussi de compenser rapidement la perte de temps découlant de la perte des données précédemment transmises par le serveur. Selon un mode de réalisation de l'invention, le récepteur utilise le numéro de séquence de l'entête de paquet RTP qui transporte les données pour détecter la perte de données lors de la transmission d'une portion du programme. La perte des données et l'obligation de les retransmettre a pour conséquence de réduire le taux de remplissage du buffer de réception et d'accroître le risque de survenue d'artefacts lié à un manque de données dans le buffer lors de la restitution du programme. Avantageusement, le récepteur adresse alors une requête RTSP PLAY indiquant un débit inférieur et un paramètre de vitesse supérieur à 1 avant de remettre en oeuvre l'algorithme décrit précédemment.
La figure 7 illustre un dispositif de réception 2 adapté pour la réception et la visualisation d'un programme audiovisuel selon un mode de réalisation de l'invention. Une interface réseau bidirectionnelle 201 permet la réception des données codant le programme audiovisuel à restituer.
L'interface 201 permet également l'émission et la réception de messages de contrôle vers et depuis le serveur de diffusion. Un démultiplexeur 202 filtre les données relatives à la réception d'un programme depuis le flux de réception ainsi que les messages de contrôle et les stocke dans un buffer de réception 203. Les données qui codent le programme audiovisuel sont lues par le décodeur Audio / Vidéo 204 qui les décode et transmet les signaux correspondants à l'interface de sortie 205. Un dispositif d'affichage (non représenté) et connecté à l'interface de sortie 205 permet la visualisation du programme pour l'utilisateur. L'ensemble des éléments 201, 202, 203, 204 et 205 sont contrôlés par l'unité de contrôle 200 qui contient selon un mode de réalisation de l'invention un microcontrôleur et des mémoires associées permettant l'exécution de routines logicielles ainsi que le traitement des données. L'unité de contrôle 200 analyse en outre les messages de contrôle en réception depuis le serveur et génère les messages de contrôle émis vers le serveur.
La figure 8 illustre l'unité de contrôle 200 selon un mode de réalisation de l'invention. L'unité de contrôle comprend un microcontrôleur 210 en charge de l'exécution des applications logicielles. Le code exécutable des applications est stocké dans la mémoire non-volatile 211 au démarrage du récepteur 2 et peut être copié dans la mémoire de travail 212 lorsque le récepteur 2 est opérationnel. La mémoire de travail 212 comprend une mémoire vive pour le stockage des données propres à l'exécution des applications logicielles et le stockage des données reçues. L'unité de contrôle 200 comprend également un module d'estimation de la bande passante 213. Le module d'estimation de la bande passante 213 calcule la bande passante disponible sur le lien entre le serveur et le récepteur 2 à partir des données lues depuis le buffer de réception. Le module de contrôle RTSP 214 compose la requête RTSP en fonction de la valeur de la bande passante calculée et disponible dans le module d'estimation 213. Le module de contrôle RTSP lit les données qui constituent la réponse à la requête RTSP PLAY dans le buffer de réception et communique le marqueur temporel rtptime au module d'estimation 213. Les données échangées entre les différents modules de l'unité de contrôle 200 transitent par le bus interne 216. L'ensemble des échanges de données avec les autres modules fonctionnels du récepteur sont effectués à travers le module d'interfaçe 215.

Claims (9)

  1. REVENDICATIONS1. Procédé de réception d'un programme audiovisuel stocké sur un serveur en vue d'une lecture sur un dispositif d'affichage connecté à un récepteur, ledit programme audiovisuel étant disponible sur ledit serveur dans au moins deux versions, chacune desdites versions comprenant une succession temporelle de blocs de données, lesdites versions comprenant chacune un même nombre de blocs, lesdits blocs commençant chacun par une image encodée sans référence à une image précédente, ledit procédé étant caractérisé en ce qu'il comprend les étapes, au niveau du récepteur : - de réception, selon le protocole de transport RTP, d'une première portion dudit programme audiovisuel comprenant au moins un bloc de données issu d'une première desdites versions transmise par ledit serveur à un premier débit, - de détermination de la bande passante après réception de ladite première portion dudit programme audiovisuel transmise par ledit serveur audit premier débit, - d'émission d'une requête, selon le protocole de contrôle RTSP, vers le serveur, ladite requête comprenant : - des informations d'identification d'une seconde portion dudit programme audiovisuel dans une desdites versions dudit programme en fonction de la valeur déterminée de la bande passante entre ledit serveur et ledit récepteur et - un paramètre de vitesse de transmission, lesdites informations d'identification comprenant des repères temporels de début et de fin de ladite seconde portion.
  2. 2. Procédé selon la revendication 1, caractérisé en ce que lesdites étapes de réception, de détermination de la bande passante et d'émission d'une requête par ledit récepteur sont reproduites itérativement au cours de la réception dudit programme audiovisuel.
  3. 3. Procédé selon l'une des revendications 1 ou 2 caractérisé en ce que lesdites versions dudit programme audiovisuel sont comprises dans un même fichier stocké sur ledit serveur.
  4. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que ledit programme audiovisuel est associé sur ledit serveur à un fichier de description comprenant des informations relatives à la localisation desdites versions dudit programme audiovisuel dans ledit même fichier.
  5. 5. Procédé selon l'une des revendications précédentes, caractérisé en ce que la détermination de la bande passante disponible entre ledit serveur et ledit récepteur comprend une analyse d'au moins une caractéristique desdites portions dudit programme audiovisuel reçues audit premier débit.
  6. 6. Procédé selon la revendication 5 caractérisé en ce que la au moins une caractéristique desdites portions est le nombre de bits transmis.
  7. 7. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'étape d'émission d'une requête utilise la commande PLAY du protocole RSTP.
  8. 8. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'étape de détermination de la bande passante entre ledit serveur et ledit récepteur utilise la réponse du serveur à la commande PLAY du protocole RSTP.
  9. 9. Dispositif de réception d'un programme audiovisuel diffusé par un serveur, ledit programme étant disponible sur ledit serveur dans au moins deux versions, chacune desdites versions correspondant à une résolution d'image dudit programme audiovisuel et comprenant une succession de portions, lesdites versions comprenant chacune un même nombre de portions et lesdites portions commençant chacune par une image intra, ledit dispositif étant caractérisé en ce qu'il comprend: - des moyens de réception, selon le protocole de transport RTP, d'une première portion dudit programme audiovisuel dans une première desdites versions diffusée par ledit serveur à un premier débit, - des moyens de détermination de la bande passante après réception de ladite première portion dudit programme audiovisuel diffusée par ledit serveur audit premier débit, - des moyens d'émission d'une requête vers le serveur, selon le protocole de contrôle RTSP, ladite requête comprenant : des informations d'identification d'une seconde portion dudit programme audiovisuel dans une desdites versions dudit programme en fonction de la valeur déterminée de la bande passante entre ledit serveur et ledit récepteur et - un paramètre de vitesse de transmission, lesdites informations d'identification comprenant des repères temporels de début et de fin de ladite seconde portion.
FR1154334A 2011-05-18 2011-05-18 Methode d'adaptation dynamique du debit de reception et recepteur associe Withdrawn FR2975555A1 (fr)

Priority Applications (14)

Application Number Priority Date Filing Date Title
FR1154334A FR2975555A1 (fr) 2011-05-18 2011-05-18 Methode d'adaptation dynamique du debit de reception et recepteur associe
US14/117,973 US10015225B2 (en) 2011-05-18 2012-05-04 Method for dynamic adaptation of the reception bitrate and associated receiver
EP12718240.0A EP2710778B1 (fr) 2011-05-18 2012-05-04 Procédé d'adaptation dynamique du débit binaire en réception et récepteur associé
PCT/EP2012/058187 WO2012156211A1 (fr) 2011-05-18 2012-05-04 Procédé d'adaptation dynamique du débit binaire en réception et récepteur associé
RU2013156038/08A RU2598805C2 (ru) 2011-05-18 2012-05-04 Способ для динамической адаптации частоты следования битов при приеме и соответствующий приемник
CN201280023415.XA CN103548318B (zh) 2011-05-18 2012-05-04 用于动态地适配接收比特率的方法和相关的接收器
MYPI2013003857A MY168875A (en) 2011-05-18 2012-05-04 Method for dynamic adaptation of the reception bitrate and associated receiver
KR1020137030154A KR102012528B1 (ko) 2011-05-18 2012-05-04 수신 비트율 및 연관된 수신기의 동적 적응 방법
CA2835384A CA2835384A1 (fr) 2011-05-18 2012-05-04 Procede d'adaptation dynamique du debit binaire en reception et recepteur associe
MX2013013373A MX2013013373A (es) 2011-05-18 2012-05-04 Metodo para adaptacion dinamica de la tasa de bits recibida y receptor asociado.
JP2014510722A JP6436772B2 (ja) 2011-05-18 2012-05-04 受信ビットレートの動的適応方法および関連する受信機
TW101115870A TWI573450B (zh) 2011-05-18 2012-05-04 伺服器內所儲存視聽節目表之接收方法和裝置
HUE12718240A HUE026744T2 (en) 2011-05-18 2012-05-04 A method for dynamically adapting a receiving bit rate and associated receiver
HK14108202.1A HK1194882A1 (zh) 2011-05-18 2014-08-11 用於動態地適配接收比特率的方法和相關的接收器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1154334A FR2975555A1 (fr) 2011-05-18 2011-05-18 Methode d'adaptation dynamique du debit de reception et recepteur associe

Publications (1)

Publication Number Publication Date
FR2975555A1 true FR2975555A1 (fr) 2012-11-23

Family

ID=46025738

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1154334A Withdrawn FR2975555A1 (fr) 2011-05-18 2011-05-18 Methode d'adaptation dynamique du debit de reception et recepteur associe

Country Status (14)

Country Link
US (1) US10015225B2 (fr)
EP (1) EP2710778B1 (fr)
JP (1) JP6436772B2 (fr)
KR (1) KR102012528B1 (fr)
CN (1) CN103548318B (fr)
CA (1) CA2835384A1 (fr)
FR (1) FR2975555A1 (fr)
HK (1) HK1194882A1 (fr)
HU (1) HUE026744T2 (fr)
MX (1) MX2013013373A (fr)
MY (1) MY168875A (fr)
RU (1) RU2598805C2 (fr)
TW (1) TWI573450B (fr)
WO (1) WO2012156211A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015139726A1 (fr) * 2014-03-17 2015-09-24 Telefonaktiebolaget L M Ericsson (Publ) Configuration de niveau de congestion pour une gestion de congestion de réseau d'accès radio
GB2519391B (en) * 2014-04-02 2015-10-21 Imagination Tech Ltd Enhanced media quality management
US9767101B2 (en) * 2014-06-20 2017-09-19 Google Inc. Media store with a canonical layer for content
EP3035628A1 (fr) * 2014-12-18 2016-06-22 Alcatel Lucent Procédé pour analyser un débit binaire d'un trafic utilisateur d'une communication de données sur une ligne de communication de données et dispositifs associés
KR102313485B1 (ko) 2015-04-22 2021-10-15 삼성전자주식회사 가상현실 스트리밍 서비스를 위한 영상 데이터를 송수신하는 방법 및 장치
CN104934049B (zh) * 2015-06-24 2018-03-16 深圳市九洲电器有限公司 一种变比特率mp3播放时间获取方法及***
EP3863296B1 (fr) * 2017-09-11 2023-11-22 Tiledmedia B.V. Trames de transmission en continu d'éléments spatiaux à un dispositif client
US10484730B1 (en) * 2018-01-24 2019-11-19 Twitch Interactive, Inc. Chunked transfer mode bandwidth estimation
US11875478B2 (en) * 2020-08-28 2024-01-16 Nvidia Corporation Dynamic image smoothing based on network conditions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100161716A1 (en) * 2008-12-22 2010-06-24 General Instrument Corporation Method and apparatus for streaming multiple scalable coded video content to client devices at different encoding rates
CN101848205A (zh) * 2010-03-16 2010-09-29 深圳市同洲电子股份有限公司 一种基于rtsp的移动终端播放流媒体的方法及***

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1022884A1 (fr) * 1999-01-25 2000-07-26 CANAL+ Société Anonyme Attribution d'adresses dans un système de transmission digital
US6763392B1 (en) 2000-09-29 2004-07-13 Microsoft Corporation Media streaming methods and arrangements
TWI256250B (en) * 2001-05-10 2006-06-01 Ibm System and method for enhancing recorded radio or television programs with information on the world wide web
FI116498B (fi) 2002-09-23 2005-11-30 Nokia Corp Kaistanleveyden mukauttaminen
EP1593047A4 (fr) * 2003-02-13 2010-06-09 Nokia Corp Procede de signalisation d'adaptation de qualite de diffusion et mecanismes de commande pour diffusion multimedia
EP1463309A1 (fr) * 2003-03-26 2004-09-29 THOMSON Licensing S.A. Traitement d'un format de flux de données pour la réception audiovisuelle mobile
US8868772B2 (en) 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
JP2007036666A (ja) 2005-07-27 2007-02-08 Onkyo Corp コンテンツ配信システム、クライアント及びクライアントプログラム
EP1879346A1 (fr) * 2006-07-14 2008-01-16 Sony Service Centre (Europe) N.V. Système et procédé de transmission audio-vidéo en continu
US8773494B2 (en) * 2006-08-29 2014-07-08 Microsoft Corporation Techniques for managing visual compositions for a multimedia conference call
US8346959B2 (en) * 2007-09-28 2013-01-01 Sharp Laboratories Of America, Inc. Client-controlled adaptive streaming
US8718388B2 (en) * 2007-12-11 2014-05-06 Cisco Technology, Inc. Video processing with tiered interdependencies of pictures
US20090259756A1 (en) * 2008-04-11 2009-10-15 Mobitv, Inc. Transmitting media stream bursts
US7921222B2 (en) * 2008-05-06 2011-04-05 Vantrix Corporation Method and system for fast channel switching using standard RTSP messages
JP5322518B2 (ja) * 2008-07-08 2013-10-23 キヤノン株式会社 通信方法
US20100121974A1 (en) 2008-11-11 2010-05-13 Einarsson Torbjoem Stepwise probing for adaptive streaming in a packet communication network
US8621044B2 (en) * 2009-03-16 2013-12-31 Microsoft Corporation Smooth, stateless client media streaming
CA2711311C (fr) * 2009-08-10 2016-08-23 Seawell Networks Inc. Methodes et systemes applicables a la memorisation par blocs video extensibles
US8527647B2 (en) * 2009-10-06 2013-09-03 Unwired Planet, Inc. Managing network traffic using intermediate flow control
JP2011087103A (ja) 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
CA2783592A1 (fr) * 2009-12-11 2011-06-16 Nokia Corporation Dispositif et procedes pour decrire des representations de synchronisation dans des fichiers multimedia transmis en continu
US9247312B2 (en) * 2011-01-05 2016-01-26 Sonic Ip, Inc. Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol
EP2695352A4 (fr) * 2011-04-01 2014-12-31 Intel Corp Diffusion adaptative en flux http à optimisation entre couches

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100161716A1 (en) * 2008-12-22 2010-06-24 General Instrument Corporation Method and apparatus for streaming multiple scalable coded video content to client devices at different encoding rates
CN101848205A (zh) * 2010-03-16 2010-09-29 深圳市同洲电子股份有限公司 一种基于rtsp的移动终端播放流媒体的方法及***

Also Published As

Publication number Publication date
WO2012156211A1 (fr) 2012-11-22
KR20140023983A (ko) 2014-02-27
HUE026744T2 (en) 2016-07-28
CN103548318B (zh) 2019-01-08
MX2013013373A (es) 2014-07-30
JP2014520422A (ja) 2014-08-21
EP2710778A1 (fr) 2014-03-26
KR102012528B1 (ko) 2019-08-20
TWI573450B (zh) 2017-03-01
EP2710778B1 (fr) 2016-01-06
US20140189142A1 (en) 2014-07-03
RU2598805C2 (ru) 2016-09-27
US10015225B2 (en) 2018-07-03
RU2013156038A (ru) 2015-06-27
JP6436772B2 (ja) 2018-12-12
TW201249185A (en) 2012-12-01
MY168875A (en) 2018-12-04
CN103548318A (zh) 2014-01-29
CA2835384A1 (fr) 2012-11-22
HK1194882A1 (zh) 2014-10-24

Similar Documents

Publication Publication Date Title
FR2975555A1 (fr) Methode d'adaptation dynamique du debit de reception et recepteur associe
FR2902266A1 (fr) Procede et dispositif de repartition de la bande passante de communication
FR2906950A1 (fr) Procede et dispositifs pour adapter le debit de transmission d'un flux de donnees en presence d'interferences.
FR2883692A1 (fr) Procede d'envoi de commande a un serveur de flux de donnees numeriques et appareil implementant le procede
FR2932938A1 (fr) Procede et dispositif de transmission de donnees
EP2947888B1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
FR2930387A1 (fr) Procede de traitement d'un flux de donnees codes
FR2988964A1 (fr) Technique de distribution d'un contenu video de type immersif
FR2946820A1 (fr) Procede de transmission de donnees et dispositif associe.
FR3023665A1 (fr) Procede et dispositif d'enregistrement a distance de programmes video.
EP3840335B1 (fr) Réception d'un contenu numérique en mode truque
FR2923970A1 (fr) Procede et dispositif de formation, de transfert et de reception de paquets de transport encapsulant des donnees representatives d'une sequence d'images
EP2536075B1 (fr) Procédé de demande d'accès par un terminal à un contenu numérique apte à être téléchargé depuis un réseau.
FR2917919A1 (fr) Procede et dispositif de transmission d'images.
FR2941110A1 (fr) Procede et dispositif de prediction d'un etat de pertes d'un reseau de communication
FR3109489A1 (fr) Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau
EP2811709A1 (fr) Qualité de mesures d'expérience dans un réseau de télévision linéaire d'unidiffusion
FR3114719A1 (fr) Procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
FR3128084A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.
FR3103668A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu numérique sur réseau mobile avec détermination d’un débit d’encodage maximum autorisé sur une session en fonction d’un godet de données
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.
FR2926177A1 (fr) Procede et disositif de transmission de donnees avec partage specifique des ressources de debit d'un reseau.
EP2575307A1 (fr) Technique de distribution d'un contenu dans un reseau de communication
EP2879352A1 (fr) Contrôle de la diffusion de contenus multimedia
FR2905221A1 (fr) Procede et systemes pour optimiser la transmission d'un flux de donnees.

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20130131