FR2849733A1 - Dispositif et procede d'ajustement de debit d'un flux de contenus et produits associes - Google Patents
Dispositif et procede d'ajustement de debit d'un flux de contenus et produits associes Download PDFInfo
- Publication number
- FR2849733A1 FR2849733A1 FR0300009A FR0300009A FR2849733A1 FR 2849733 A1 FR2849733 A1 FR 2849733A1 FR 0300009 A FR0300009 A FR 0300009A FR 0300009 A FR0300009 A FR 0300009A FR 2849733 A1 FR2849733 A1 FR 2849733A1
- Authority
- FR
- France
- Prior art keywords
- receiver
- transmitter
- content
- cont
- parameter
- 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.)
- Pending
Links
Classifications
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
- H04L1/0026—Transmission of channel quality indication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1854—Scheduling and prioritising arrangements
-
- 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/18—End to end
-
- 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2416—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/10—Flow control; Congestion control
- H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
-
- 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/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
- H04L47/263—Rate modification at the source after receiving feedback
-
- 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
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1835—Buffer management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
La présente invention concerne un dispositif (10) et un procédé d'ajustement de débit d'un flux de contenus en fonction de capacités de traitement d'au moins un récepteur (1). Ces contenus sont transmis par un émetteur vers le récepteur selon un protocole de communication prévoyant une transmission en retour de données de réception (REP) des contenus par le récepteur vers l'émetteur, incluant au moins un paramètre relatif à des conditions de communication de ces contenus dans le réseau.Le dispositif comprend un module d'estimation (12) d'un niveau requis pour le débit en fonction d'informations relatives à ces capacités et un module d'inscription (13) modifiant ce paramètre, pour transmettre en retour vers l'émetteur des renseignements d'ajustement de flux, capables de provoquer une modification du débit en rapport avec le niveau requis.Application au streaming.
Description
La présente invention se rapporte à un dispositif et un procédé
d'ajustement de débit d'un flux de contenus en fonction de capacités de traitement d'un ou plusieurs récepteurs, ainsi qu'à des produits associés.
De plus en plus de terminaux utilisateur, tels que notamment des ordinateurs personnels (PCs pour " Personal Computers ") et des assistants numériques personnels (PDAs pour " Personal Digital Assistants "), sont fondés sur des plate-formes génériques sur lesquelles des logiciels sont implémentés. Cette évolution concerne en particulier des lecteurs 1 0 audio/vidéo.
Cependant, les capacités des terminaux sont souvent très différentes, tant en performances CPU (pour " Central Processing Unit ") qu'en mémoire disponible. Il est donc nécessaire de définir des techniques 15 qui adaptent soit le contenu au terminal, soit le terminal au contenu.
Des solutions connues concernant l'adaptation du terminal au contenu, consistent à effectuer un décodage sélectif si le terminal ne parvient pas à décoder en temps réel l'ensemble des données. Par exemple, lors de la réception d'un flux vidéo MPEG2 (pour " Moving Picture Experts 20 Group "), qui comprend classiquement des images de types I (décodées en elles-mêmes), P (décodées à l'aide d'images antérieures) et B (décodées à l'aide d'images antérieures et postérieures), le terminal débordé ne décode pas les images B (celles-ci n'étant pas utilisées pour la prédiction des images suivantes).
Dans des applications de diffusion sans voie de retour, par diffusion générale (" broadcasting ") ou multidiffusion (" multicasting "), cette solution permet efficacement de s'adapter, bien qu'elle conduise à des pertes d'informations pouvant porter préjudice à la qualité de réception. -2
Par contraste, dans des applications point à point, il est possible d'éviter ce problème en adaptant les débits d'émission aux terminaux. Pour ce faire, selon une technique connue, on met en oeuvre une étape préalable de négociation entre le terminal visé et un client pour communiquer à 5 l'émetteur les performances de ce terminal. L'émetteur choisit alors un contenu qui puisse être décodé en temps réel par le terminal. Cette technique repose sur la définition d'un protocole permettant d'échanger ce type d'informations, et sur la définition d'une mesure des performances du terminal. Parmi les méthodes divulguées portant sur l'adaptation d'un émetteur aux capacités d'un récepteur, le document japonais JP2000270330 divulgue une adaptation de débits d'émission en fonction de capacités de traitement de terminaux avec décodeurs, au moyen d'une 15 notification préalable à l'émetteur de ces capacités par les terminaux récepteurs. Il ressort de la divulgation de ce document qu'un protocole spécifique de transmission doit être convenu entre l'émetteur et le récepteur 20 pour y parvenir, ce qui présente l'inconvénient de nécessiter l'implémentation d'un système cohérent tant au niveau des émetteurs que des récepteurs concernés. De plus, une telle procédure ne peut bénéficier d'une application relativement large que dans la mesure o elle fait l'objet d'une normalisation reconnue. Par ailleurs, des techniques standardisées sont couramment employées pour adapter des flux d'émission à des conditions de circulation de données dans un réseau point à point. Ainsi, dans le protocole RTCP (pour " Real-Time Control Protocol "), la durée d'aller-retour (" RTT " pour 30 " Round Trip Time ") de paquets IP (pour " Internet Protocol ") entre un émetteur et un récepteur est notifié à l'émetteur, qui peut prendre des mesures appropriées pour modifier le flux émis. Cette disposition est -3 particulièrement utile pour réagir à une congestion dans le réseau. Dans le cas d'un algorithme du type " TCP-friendly ", un taux d'erreur observé au récepteur (" loss event rate ", noté " p ") est également communiqué à l'émetteur, qui peut ainsi adapter son flux d'émission et générer de la protection aux erreurs en fonction du taux d'erreur mesuré.
L'utilisation de la durée d'aller-retour RTT a fait l'objet d'améliorations spécifiques visant à tenir compte de la contenance d'une mémoire tampon au niveau du récepteur. En effet, une telle mémoire 10 tampon prolonge la durée à prendre en compte pour ajuster le débit du flux d'émission. Ainsi, le document JP2001-257715 divulgue un émetteur disposant d'une section de traitement d'informations capable de calculer le RTT à partir d'un accusé de réception en provenance du récepteur. La section de traitement extrait un débit de transmission correspondant à ce 15 RTT et à des renseignements sur la quantité de stockage d'une mémoire tampon associée au terminal, joints à l'accusé de réception. Une section de contrôle de débit modifie alors le débit de transmission effectif sur la base de ce débit extrait. Cette technique permet d'agir sur le débit de transmission, de façon à obtenir une bonne reproduction en temps réel et à éviter des 20 congestions de réseau.
Ces méthodes, qui permettent de prendre en compte les contenances de mémoires tampons pour des variations de débits, requièrent des implémentations particulières aux niveaux des émetteurs et récepteurs, 25 ainsi que des protocoles de communication spécifiques. Par ailleurs, elles laissent entier le problème d'adaptation aux capacités de traitement de récepteurs. Une solution tentante pour améliorer encore la justesse du débit 30 d'émission consisterait à émettre au préalable une notification informant l'émetteur des capacités du récepteur, comme décrit dans le document JP2000-270330, puis à transmettre à l'émetteur en cours de transmission -4 des accusés de réception contenant non seulement le RTT mais aussi des renseignements sur la mémoire tampon du récepteur, comme décrit dans le document JP2001-257715. L'émetteur, par des algorithmes judicieusement combinés, adapterait son flux d'émission en prenant en compte les deux types d'informations.
Bien qu'une telle combinaison puisse s'avérer très efficace pour produire une bonne fluidité des décodages en temps réel, elle maintient la nécessité d'une implémentation dans les émetteurs et les récepteurs et de la 10 mise en oeuvre d'un protocole spécifique. De plus, elle laisse subsister de fortes incertitudes sur l'admission de ce protocole spécifique dans des réseaux étendus (appelés réseaux " WAN " pour " Wide Area Networks ") tels qu'lnternet, sauf à limiter l'implémentation à un parc restreint de terminaux d'émission et de réception compatibles. 15 La présente invention concerne un dispositif d'ajustement de débit d'un flux de contenus en fonction de capacités de traitement d'au moins un récepteur, qui rend possible une implémentation simple et efficace, et est susceptible de s'appliquer sans difficulté particulière à un très grand nombre 20 d'émetteurs et de récepteurs, éventuellement de modèles distincts, sans qu'il soit nécessaire de faire adopter un nouveau protocole spécifique de communication. L'invention concerne également un procédé d'ajustement, un 25 terminal de réception et un programme d'ordinateur correspondant au dispositif de l'invention.
Elle s'applique en particulier au domaine des communications RTCP, notamment sur Internet, mais aussi sur d'autres réseaux WAN et sur 30 des réseaux locaux (appelés réseaux " LAN ", pour " Local Area Networks "). De plus, l'invention est tout spécialement intéressante pour des transmissions en continu (dites par " streaming ") de flux vidéo, tels que par -5 exemple de la vidéo à la carte (" VOD " pour " Video On Demand "), ou pour la retransmission d'événements en direct sur Internet.
A cet effet, l'invention a pour objet un dispositif d'ajustement de 5 débit d'un flux de contenus en fonction de capacités de traitement d'au moins un récepteur. Ces contenus sont transmis par un émetteur vers ce récepteur via un réseau, selon un protocole de communication prévoyant une transmission en retour de données de réception des contenus par le récepteur vers l'émetteur. Ce dispositif comprend: - un module d'entrée d'informations relatives à ces capacités, - un module d'estimation d'un niveau requis pour le débit au moins en fonction de ces informations, - et un module d'inscription de renseignements d'ajustement de flux destiné à inscrire les renseignements d'ajustement pour transmission en 15 retour avec les données de réception vers l'émetteur, ces renseignements d'ajustement étant capables de provoquer une modification du débit en rapport avec le niveau requis.
Selon l'invention, le protocole de communication prévoyant une 20 transmission en retour vers l'émetteur d'au moins un paramètre relatif à des conditions de communication des contenus dans le réseau entre l'émetteur et le récepteur, le module d'inscription est destiné à modifier ce paramètre de façon à l'utiliser pour transmettre les renseignements d'ajustement.
Par " capacités de traitement " d'un récepteur, on entend des ressources du récepteur apte à un traitement des données reçues, par exemple pour un décodage d'un flux MPEG2. Ces capacités peuvent donc inclure notamment une vitesse de traitement de données (typiquement une performance CPU, pour " Central Processing Unit "), un volume mémoire 30 (tel que celui d'une mémoire RAM - pour " Random Access Memory "), une consommation d'énergie et/ou une présence de composants dédiés au traitement des contenus (par exemple un décodeur matériel, dit " décodeur -6 hardware "). On exclut en revanche de cette définition des entités ayant des fonctions de pure régulation de flux, en l'occurrence des mémoires tampons (" buffers ").
D'une façon inattendue et à contre-emploi, les capacités de traitement du récepteur sont utilisées pour influer sur un paramètre du protocole normalement consacré à des propriétés de circulation dans le réseau. De plus, ce paramètre est modifié en amont de la transmission en retour vers l'émetteur, ce qui tranche également avec les techniques 10 connues, dans lesquelles des algorithmes d'ajustement sont mis en oeuvre au niveau de l'émetteur.
Cette façon de procéder est d'autant plus surprenante qu'en agissant ainsi au niveau du récepteur (ou d'un ensemble de récepteurs), on 15 a la possibilité de décharger l'émetteur de toute opération spécifique d'adaptation au récepteur, alors même que cet émetteur ne dispose d'aucune implémentation en relation avec les capacités de traitement du récepteur. Ce résultat est obtenu en agissant sur un paramètre du protocole qui vise normalement des conditions de communication dans le réseau, mais 20 auquel on attribue une fonction additionnelle: incorporer implicitement des informations sur les capacités du récepteur.
Lier les capacités de traitement du récepteur à un tel paramètre est inattendu, même au regard de la divulgation du document JP200125 257715 sur la transmission en retour de la contenance d'une mémoire tampon, avec la durée RTT. En effet, la mémoire tampon remplit un rôle directement lié à la fluidité des échanges, et est une extension naturelle du concept de temps de parcours des données entre l'émetteur et le récepteur - lorsque des files d'attente augmentent dans des mémoires tampons, les 30 transmissions sont ralenties et la durée RTT croît. Tel n'est pas le cas des capacités de traitement du récepteur, sans relation apparente immédiate avec des conditions de communication dans un réseau. -7
Le dispositif d'ajustement de l'invention est très avantageux notamment en ce qu'il autorise un processus d'ajustement de débit aux capacités de traitement du récepteur, totalement transparent pour l'émetteur. 5 Ce dernier agit en fait conformément aux dispositions du protocole, dans le but de parer à des congestions de réseau.
Une conséquence essentielle de cette situation est qu'il n'est pas nécessaire de modifier les appareils d'émission, ni de leur adjoindre des 10 dispositifs dédiés. Au contraire, tout émetteur en accord avec le protocole de communication peut convenir. Seuls les récepteurs doivent être pourvus de moyens spécifiques, par incorporation de ces moyens soit en leur sein, soit dans un système adjoint approprié. Une autre conséquence de cette situation est que le protocole n'a pas à être modifié et qu'il n'est pas 15 nécessaire non plus de définir un protocole additionnel. Par conséquent, sous réserve d'une adaptation des récepteurs, le dispositif d'ajustement de l'invention est applicable dès lors qu'est en place un protocole prévoyant une transmission en retour de données de réception incluant un paramètre relatif à des conditions de communication dans le réseau. 20 Il est par ailleurs avantageux de combiner la technique du dispositif de l'invention avec une prise en compte de la mémoire tampon.
Dans ce cas, de préférence, la contenance de cette mémoire tampon est directement prise en compte par une modification d'un paramètre du 25 protocole, qui peut être identique au paramètre exploité pour les capacités de traitement du récepteur. Ainsi, comme indiqué précédemment, il n'est pas nécessaire de modifier les émetteurs, et le protocole de communication standard peut être exploité.
Le dispositif d'ajustement de l'invention peut permettre non seulement de s'adapter précisément aux capacités de traitement du récepteur, mais aussi de le faire même lorsque ces capacités varient au -8 cours du temps. De préférence, il est prévu pour agir de façon complètement automatisée, y compris pour établir les capacités de traitement des récepteurs. Les opérations effectuées sont ainsi totalement transparentes aux utilisateurs.
Le dispositif d'ajustement de l'invention peut être implémenté directement dans un terminal de réception utilisateur, par exemple sous la forme d'un gestionnaire de qualité interne déterminant le débit de transmission souhaité puis agissant en conséquence sur le paramètre ou les 10 paramètres utilisés. Il peut aussi être implémenté dans un système autonome disposé entre le récepteur et le réseau. Un tel système autonome peut également être associé à plusieurs récepteurs, et tenir compte de leurs diverses capacités de traitement. Cette dernière réalisation est particulièrement intéressante pour un groupe géographiquement défini de 15 terminaux, par exemple dans un immeuble ou une entreprise.
Les données de réception sont préférentiellement transmises en retour via le réseau de communication utilisé pour l'envoi du flux de contenus. Selon une forme préférée du protocole de communication, celui-ci est le protocole RTCP. On peut également appliquer l'invention à un réseau et un protocole point à point, ou aussi à une multidiffusion (pour des groupes de terminaux).
Dans un première mode de réalisation préférée du paramètre du protocole, celui-ci est prévu pour servir à calculer un délai de transmission allerretour entre l'émetteur et le récepteur. Le paramètre du protocole comprend alors avantageusement un délai introduit au récepteur entre un 30 moment de réception des contenus et un moment d'émission des données de réception par le récepteur. Dans le protocole RTCP, notamment, le délai de transmission est la durée RTT, qui est modifiée au niveau du récepteur -9 en jouant sur le délai appelé DLSR (pour " Delay since Last Sender Report ") séparant la réception des contenus de l'émission des données de réception. Dans un deuxième mode de réalisation préférée du paramètre du protocole, celui-ci comprend un taux de perte de contenus. Dans le protocole RTCP, notamment, ce taux de perte p peut être exploité dans la mesure o l'émetteur utilise un algorithme TCP-friendly (pour " Transmission Control Protocol ").
Ces deux modes de réalisation portant sur le paramètre du protocole sont avantageusement combinés, le dispositif d'ajustement étant capable de modifier tant l'un que l'autre des deux types de paramètres, ou même les deux paramètres à la fois.
L'avantage du choix de DLSR comme paramètre de modification du protocole RTCP est qu'il s'applique à d'autres algorithmes que TCPfriendly. En fait, quel que soit l'émetteur disposant d'un algorithme de contrôle de congestion, cet émetteur s'adapte aux capacités de traitement 20 du récepteur lorsque le dispositif d'ajustement est mis en oeuvre au niveau du récepteur. De plus, ce paramètre évite une éventuelle génération de protection aux erreurs non nécessaire, propre à l'utilisation du taux de perte.
En revanche, l'avantage du choix de p comme paramètre de 25 modification du protocole RTCP (lorsqu'il est utilisable) est qu'il permet d'agir directement sur le paramètre concerné, alors que la modification du paramètre DLSR induit des incertitudes sur l'effet obtenu quant à la durée RTT, celle-ci dépendant aussi de la rapidité de circulation des données de réception entre le récepteur et l'émetteur. 30 Avantageusement, le module d'inscription est capable de modifier le paramètre (ou les paramètres) du protocole au moyen de plusieurs -10 variations successives de ce paramètre. Cette réalisation est particulièrement judicieuse lorsqu'il n'est pas possible de modifier directement le paramètre décisif au niveau de l'émission, mais qu'on agit sur lui par l'intermédiaire d'un paramètre accessoire.
Ceci s'applique en particulier au paramètre DLSR, qui permet de modifier indirectement la durée RTT. Selon le présent mode de réalisation, on procède à des incrémentations successives de DLSR au niveau du récepteur, afin d'ajuster avec précision le débit du flux de contenus. Par 10 rapport à cette version améliorée, l'utilisation du taux de perte conserve d'une part un avantage en ce qu'elle évite de telles itérations, et d'autre part les inconvénients mentionnés plus haut.
Dans des modes de réalisation améliorés du dispositif 15 d'ajustement de l'invention, celui-ci ne tient pas seulement compte des capacités de traitement du récepteur pour adapter le débit de transmission des contenus. Ainsi que cela a déjà été mentionné, on peut notamment faire intervenir la contenance d'une mémoire tampon pour ajuster le RTT du protocole RTCP, via le DLSR, mais d'autres réalisations sont 20 particulièrement intéressantes.
En particulier, avantageusement, le module d'estimation est capable de déterminer une valeur à atteindre pour le débit du flux de contenus non seulement en fonction des capacités de traitement du 25 récepteur, mais aussi en fonction d'un taux de partage des capacités du récepteur. On peut de cette manière gérer les débits de plusieurs flux traités en parallèle dans le récepteur, en imposant éventuellement des priorités. A titre d'illustration, on peut décider que tel flux ne doit pas consommer plus de 30 % des capacités de traitement (par exemple en terme de partage CPU), 30 les 70 % restants étant répartis équitablement entre les autres flux. -11
Les modules d'entrée et d'estimation sont préférentiellement prévus pour que les capacités de traitement du récepteur comprennent au moins un critère de performance du récepteur choisi parmi une vitesse de traitement de données, un volume mémoire, une consommation d'énergie et une présence de composants dédiés au traitement des contenus.
L'invention concerne aussi un terminal de réception, caractérisé en ce qu'il comprend un dispositif d'ajustement de débit conforme à l'une quelconque des formes de l'invention.
L'invention s'applique également à un procédé d'ajustement de débit d'un flux de contenus en fonction de capacités de traitement d'au moins un récepteur, correspondant au dispositif de l'invention et préférentiellement destiné à être mis en oeuvre au moyen de l'un quelconque 15 des modes de réalisation de l'invention. Avantageusement, ce réseau est un réseau de communication point à point et le flux des contenus est transmis en continu (streaming).
L'invention porte également sur un produit programme 20 d'ordinateur comprenant des instructions de codes de programme pour l'exécution des étapes du procédé d'ajustement selon l'invention lorsque ce programme est exécuté sur un ordinateur. Par " produit programme d'ordinateur ", on entend un support de programme d'ordinateur, qui peut consister non seulement en un espace de stockage contenant le 25 programme, tel qu'une disquette ou une cassette, mais aussi en un signal, tel qu'un signal électrique ou optique.
L'invention sera mieux comprise et illustrée au moyen des exemples suivants de réalisation et de mise en oeuvre, nullement limitatifs, 30 en référence aux figures annexées sur lesquelles: -12 - la Figure 1 est un schéma de principe d'un ensemble d'émission et de réception dans lequel le récepteur comprend un dispositif d'ajustement selon l'invention; - et la Figure 2 détaille le récepteur de la Figure 1.
Sur ces figures, les entités fonctionnelles décrites et illustrées ne correspondent pas nécessairement à des entités physiquement distinctes, mais peuvent par exemple consister en des fonctionnalités d'un même logiciel ou en des circuits d'un même composant. 10 Un ensemble d'émission et de réception à travers un réseau 5 de communication (Figure 1) comprend un émetteur 2 de contenus CONT et un récepteur 1 de ces contenus CONT. Selon un protocole de communication via le réseau 5, le récepteur 1 est prévu pour émettre en retour via le réseau 15 5 vers l'émetteur 2, des données de réception REP (pour " Report ") de ces contenus CONT. En particulier, ces données REP comprennent un ou plusieurs paramètres relatifs à des conditions de communication des contenus CONT dans le réseau 5, ces paramètres étant utilisés par l'émetteur 2 pour modifier le débit du flux de contenus CONT, de façon à 20 remédier à des problèmes de congestion dans le réseau 5.
Le récepteur 1 est pourvu d'un dispositif d'ajustement de débit 10, capable de modifier les paramètres mentionnés plus haut. Ce dispositif d'ajustement 10 est prévu pour estimer un niveau requis pour le débit du flux 25 de contenus CONT en fonction de capacités de traitement du récepteur 1, et pour agir en conséquence sur ces paramètres afin de provoquer un ajustement du débit au niveau de l'émetteur 2.
Plus précisément, le récepteur 1 comprend, outre le dispositif 30 d'ajustement 10, un module de mesure 14 de capacités de traitement du récepteur 1, un module de préparation 15 des données de réception REP, 13 relié à une horloge 20, et un module d'émission 16 de ces données REP. Le dispositif d'ajustement 10 comprend quant à lui: - un module d'entrée 11 d'informations sur les capacités de traitement du récepteur 1, communiquées par le module de mesure 14, - un module d'estimation 12 de niveaux requis pour le débit du flux de contenus CONT, - et un module d'inscription 13 de renseignements d'ajustement de flux dans les données REP, en communication avec le module de préparation 15 et destiné à fournir au module 15 les instructions de 10 modification des paramètres utilisés pour contrôler le débit.
Selon l'exemple d'application décrit, le protocole est RTCP et le réseau est Internet.
Dans un premier exemple d'implémentation, on utilise le calcul du RTT (Round Trip Time) pour remonter à l'émetteur 2 le débit que le récepteur 1 est capable de décoder.
Le RTT est calculé par l'émetteur 2 en particulier à partir du délai 20 DLSR reçu en provenance du récepteur 1 avec les données de réception REP. Le mode de calcul de la durée RTT est donné par le protocole RTCP en substance de la manière suivante: Dernière estampille (" time stamp ") SR (pour " Sender Report ") 25 (LSR pour "Last SR "): 32 bits - les 32 bits moyens des 64 dans l'estampille NTP (..) reçues comme partie du paquet SR le plus récent en provenance de la source SSRCn. Si aucun SR n'a encore été reçu, ce champ est mis à zéro.
Délai depuis le dernier SR (DLSR): 32 bits - le délai, exprimé en unités de 1/65536 de secondes, entre la réception du dernier paquet SR en provenance de la source SSRCn et l'envoi du bloc de rapport de -14 réception. Si aucun paquet SR n'a encore été reçu en provenance de SSRC_n, le champ DLSR est mis à zéro.
La source SSRCn peut calculer le délai de propagation aller5 retour vers SSRCr (récepteur émettant le rapport de réception) en enregistrant l'instant A de réception du bloc de rapport de réception, et en calculant la durée totale d'aller-retour (A - LSR) puis en lui soustrayant le délai DLSR: (A - LSR - DLSR).
Puis les algorithmes de contrôle de congestion déduisent un débit dit TCPfriendly, qui permet de réduire le débit d'émission en cas de congestion tel que l'aurait fait le protocole TCP (pour " Transmission Control Protocol "). L'algorithme donné dans le protocole est le suivant: L'équation de débit est: s R* /(2*b*p/3) + (tRTO * (3*V(3*b*p/8) *,p * (1+ 32*p2))) o: X est le taux de transmission en octets par seconde; s est la taille de paquets en octets; R est la durée de voyage aller-retour en secondes (RTT); p est le taux d'événements de pertes, entre O et 1, donné par le nombre d'événements de pertes comme une fraction du nombre de paquets 25 transmis; t RTO est la valeur de temps mort de retransmission en secondes; b est le nombre de paquets attestés par un unique accusé de réception TCP.
Par incrémentations successives du délai introduit au récepteur (DLSR), on modifie artificiellement le RTT (R) pour "faire croire" à l'émetteur -15 2 que le débit disponible est celui décodable par le récepteur 1 et non pas le débit réseau 5 disponible.
Dans un deuxième exemple d'implémentation, on utilise le calcul 5 du taux de pertes p pour remonter à l'émetteur le débit que le récepteur est capable de décoder. Pour ce faire, on modifie directement p. -16
Claims (12)
1. Dispositif d'ajustement (10) de débit d'un flux de contenus 5 (CONT) en fonction de capacités de traitement d'au moins un récepteur (1), lesdits contenus (CONT) étant transmis par un émetteur (2) vers ledit récepteur (1) via un réseau (5), selon un protocole de communication prévoyant une transmission en retour de données de réception (REP) desdits contenus (CONT) par ledit récepteur (1) vers ledit émetteur (2), ledit 10 dispositif (10) comprenant: - un module d'entrée (11) d'informations relatives aux dites capacités, - un module d'estimation (12) d'un niveau requis pour ledit débit au moins en fonction desdites informations, - et un module d'inscription (13) de renseignements d'ajustement de flux destiné à inscrire lesdits renseignements d'ajustement pour transmission en retour avec lesdites données de réception (REP) vers ledit émetteur (2), lesdits renseignements d'ajustement étant capables de provoquer une modification dudit débit en rapport avec ledit niveau requis, 20 caractérisé en ce que ledit protocole de communication prévoyant une transmission en retour vers ledit émetteur (2) d'au moins un paramètre relatif à des conditions de communication desdits contenus (CONT) dans ledit réseau (5) entre ledit émetteur (2) et ledit récepteur (1), le module 25 d'inscription (13) est destiné à modifier ledit paramètre de façon à l'utiliser pour transmettre lesdits renseignements d'ajustement.
2. Dispositif d'ajustement (10) selon la revendication 1, caractérisé en ce que ledit protocole de communication est le protocole 30 RTCP. -17
3. Dispositif d'ajustement (10) selon l'une des revendications 1 ou 2, caractérisé en ce que ledit paramètre du protocole (DLSR) est prévu pour servir à calculer un délai de transmission aller-retour (RTT) entre ledit émetteur (2) et ledit récepteur (1).
4. Dispositif d'ajustement (10) selon la revendication 3, caractérisé en ce que ledit paramètre du protocole comprend un délai (DLSR) introduit audit récepteur (1) entre un moment de réception desdits contenus (CONT) et un moment d'émission desdites données de réception 10 (REP) par ledit récepteur (1).
5. Dispositif d'ajustement (10) selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit paramètre du protocole comprend un taux de perte (p) de contenus. 15
6. Dispositif d'ajustement (10) selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit module d'inscription (13) est capable de modifier ledit paramètre au moyen de plusieurs variations successives dudit paramètre. 20
7. Dispositif d'ajustement (10) selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit module d'estimation (12) est capable de déterminer une valeur à atteindre pour ledit débit dudit flux de contenus (CONT) aussi en fonction d'un taux de partage desdites 25 capacités dudit récepteur (1).
8. Dispositif d'ajustement (10) selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits modules d'entrée (11) et d'estimation (12) sont prévues pour que lesdites capacités de 30 traitement dudit récepteur (1) comprennent au moins un critère de performance dudit récepteur choisi parmi une vitesse de traitement de -18 données, un volume mémoire, une consommation d'énergie et une présence de composants dédiés au traitement desdits contenus (CONT) .
9. Terminal de réception (1) caractérisé en ce qu'il comprend un 5 dispositif d'ajustement (10) de débit conforme à l'une quelconque des revendications 1 à 8.
10. Procédé d'ajustement de débit d'un flux de contenus (CONT) en fonction de capacités de traitement d'au moins un récepteur (1), lesdits 10 contenus (CONT) étant transmis par un émetteur (2) vers ledit récepteur (1) via un réseau (5), selon un protocole de communication prévoyant une transmission en retour de données de réception (REP) desdits contenus (CONT) par ledit récepteur (1) vers ledit émetteur (2), ledit procédé comprenant les étapes suivantes: - on estime un niveau requis pour ledit débit au moins en fonction d'informations relatives aux dites capacités, et on inscrit des renseignements d'ajustement de flux pour transmission en retour avec lesdites données de réception (REP) vers ledit émetteur (2), lesdits renseignements d'ajustement étant capables de 20 provoquer une modification dudit débit en rapport avec ledit niveau requis, caractérisé en ce que ledit protocole de communication prévoyant une transmission en retour vers ledit émetteur (2) d'au moins un paramètre relatif à des conditions de communication desdits contenus (CONT) dans 25 ledit réseau (5) entre ledit émetteur (2) et ledit récepteur (1), on inscrit lesdits renseignements en modifiant ledit paramètre, de façon à l'utiliser pour transmettre lesdits renseignements d'ajustement, ledit procédé d'ajustement étant préférentiellement destiné à être 30 mis en oeuvre au moyen d'un dispositif d'ajustement conforme à l'une
quelconque des revendications 1 à 8. -19
11. Procédé d'ajustement de débit selon la revendication 10, caractérisé en ce que ledit réseau (5) est un réseau de communication point à point et le flux desdits contenus (CONT) est transmis en continu.
12. Produit programme d'ordinateur comprenant des instructions de codes de programme pour l'exécution des étapes du procédé selon l'une des revendications 10 ou 11 lorsque ledit programme est exécuté sur un ordinateur.
Priority Applications (9)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0300009A FR2849733A1 (fr) | 2003-01-02 | 2003-01-02 | Dispositif et procede d'ajustement de debit d'un flux de contenus et produits associes |
| PCT/EP2003/051012 WO2004062226A1 (fr) | 2003-01-02 | 2003-12-15 | Dispositif et procede d'ajustement de debit binaire d'un flux de contenus |
| MXPA05006837A MXPA05006837A (es) | 2003-01-02 | 2003-12-15 | Dispositivo y proceso para ajustar la velocidad de bitios de una corriente de contenidos y productos asociados. |
| US10/539,431 US7739399B2 (en) | 2003-01-02 | 2003-12-15 | Device and process for adjusting the bit rate of a stream of contents and associated products |
| CNB2003801081330A CN100490443C (zh) | 2003-01-02 | 2003-12-15 | 用于调整内容流的比特率的设备和方法 |
| AU2003299239A AU2003299239A1 (en) | 2003-01-02 | 2003-12-15 | Device and process for adjusting the bit rate of a stream of contents and associated products |
| EP03799572A EP1597891A1 (fr) | 2003-01-02 | 2003-12-15 | Dispositif et procede d'ajustement de debit binaire d'un flux de contenus |
| JP2004564242A JP4384992B2 (ja) | 2003-01-02 | 2003-12-15 | コンテンツ・ストリームのビット・レートを調節する装置及び処理、並びに関連したプロダクト |
| KR1020057012529A KR100982630B1 (ko) | 2003-01-02 | 2003-12-15 | 콘텐츠의 스트림 비트율을 조정하기 위한 디바이스 및프로세스 그리고 관련 제품 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0300009A FR2849733A1 (fr) | 2003-01-02 | 2003-01-02 | Dispositif et procede d'ajustement de debit d'un flux de contenus et produits associes |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2849733A1 true FR2849733A1 (fr) | 2004-07-09 |
Family
ID=32524657
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0300009A Pending FR2849733A1 (fr) | 2003-01-02 | 2003-01-02 | Dispositif et procede d'ajustement de debit d'un flux de contenus et produits associes |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7739399B2 (fr) |
| EP (1) | EP1597891A1 (fr) |
| JP (1) | JP4384992B2 (fr) |
| KR (1) | KR100982630B1 (fr) |
| CN (1) | CN100490443C (fr) |
| AU (1) | AU2003299239A1 (fr) |
| FR (1) | FR2849733A1 (fr) |
| MX (1) | MXPA05006837A (fr) |
| WO (1) | WO2004062226A1 (fr) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1598987A4 (fr) * | 2003-02-27 | 2008-12-24 | Fujitsu Ltd | Procede et dispositif de determination d'etat d'utilisation |
| US8547997B2 (en) * | 2005-04-20 | 2013-10-01 | Jupiter Systems | Capture node for use in an audiovisual signal routing and distribution system |
| US8606949B2 (en) | 2005-04-20 | 2013-12-10 | Jupiter Systems | Interconnection mechanism for multiple data streams |
| US20070009071A1 (en) * | 2005-06-29 | 2007-01-11 | Ranjan Singh | Methods and apparatus to synchronize a clock in a voice over packet network |
| JP3949148B2 (ja) * | 2005-09-06 | 2007-07-25 | 株式会社東芝 | 無線通信装置、受信装置、送信装置および通信制御プログラム |
| FR2895181B1 (fr) * | 2005-12-16 | 2008-12-05 | Mediatvcom Sarl | Procede et systeme de transmission d'un flux de donnees multimedia |
| JP2007201702A (ja) * | 2006-01-25 | 2007-08-09 | Mitsubishi Electric Corp | 受信装置、通信装置および通信方法 |
| JP4407700B2 (ja) | 2007-02-02 | 2010-02-03 | 日本電気株式会社 | 通信端末、通信システム、輻輳制御方法、及び輻輳制御用プログラム |
| TWI396443B (zh) * | 2008-12-22 | 2013-05-11 | Ind Tech Res Inst | 應用於網路串流之影音控制回應及頻寬調適方法與使用該方法之伺服器 |
| US8458328B2 (en) | 2010-11-02 | 2013-06-04 | Net Power And Light, Inc. | Method and system for data packet queue recovery |
| US8667166B2 (en) | 2010-11-02 | 2014-03-04 | Net Power And Light, Inc. | Method and system for resource-aware dynamic bandwidth control |
| US8838787B2 (en) * | 2011-11-30 | 2014-09-16 | Harman International Industries, Incorporated | System for optimizing latency in an AVB network |
| US8854958B2 (en) * | 2011-12-22 | 2014-10-07 | Cygnus Broadband, Inc. | Congestion induced video scaling |
| US9485289B2 (en) | 2013-08-28 | 2016-11-01 | Cisco Technology, Inc. | HTTP streaming client adaptation algorithm based on proportional-integral control |
| TWI505697B (zh) * | 2013-09-26 | 2015-10-21 | Chunghwa Telecom Co Ltd | Audio and video playback method and its system |
| US20150100622A1 (en) * | 2013-10-04 | 2015-04-09 | Comcast Cable Communications, Llc | Network Device Mediation |
| CN114025354A (zh) * | 2021-11-17 | 2022-02-08 | 圆藏(上海)科技有限公司 | 一种降低信息传输误码的通信方法、系统及存储介质 |
Family Cites Families (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB9419611D0 (en) * | 1994-09-29 | 1994-11-16 | Plessey Telecomm | Constant bit rate synchronisation |
| US6072994A (en) * | 1995-08-31 | 2000-06-06 | Northrop Grumman Corporation | Digitally programmable multifunction radio system architecture |
| US6132306A (en) * | 1995-09-06 | 2000-10-17 | Cisco Systems, Inc. | Cellular communication system with dedicated repeater channels |
| US5951645A (en) | 1996-09-25 | 1999-09-14 | Nec Corporation | Network protocol for transferring data between applications running on different clients in a client-server system |
| US6178448B1 (en) * | 1997-06-18 | 2001-01-23 | International Business Machines Corporation | Optimal link scheduling for multiple links by obtaining and utilizing link quality information |
| US6701372B2 (en) * | 1997-08-22 | 2004-03-02 | Canon Kabushiki Kaisha | Data communication apparatus and method |
| US6594699B1 (en) * | 1997-10-10 | 2003-07-15 | Kasenna, Inc. | System for capability based multimedia streaming over a network |
| US6643496B1 (en) * | 1998-03-31 | 2003-11-04 | Canon Kabushiki Kaisha | System, method, and apparatus for adjusting packet transmission rates based on dynamic evaluation of network characteristics |
| US7142506B1 (en) * | 1999-02-02 | 2006-11-28 | Vocaltec Communications Ltd. | Method and apparatus for transmitting packets |
| JP2000270330A (ja) * | 1999-03-18 | 2000-09-29 | Fujitsu Ltd | 映像配信システム及び映像配信方法 |
| US7093028B1 (en) * | 1999-12-15 | 2006-08-15 | Microsoft Corporation | User and content aware object-based data stream transmission methods and arrangements |
| JP3777279B2 (ja) * | 1999-12-20 | 2006-05-24 | 富士通株式会社 | データ通信システム並びにデータ受信端末及びデータ送信端末 |
| FI109393B (fi) * | 2000-07-14 | 2002-07-15 | Nokia Corp | Menetelmä mediavirran enkoodaamiseksi skaalautuvasti, skaalautuva enkooderi ja päätelaite |
| US6807156B1 (en) * | 2000-11-07 | 2004-10-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Scalable real-time quality of service monitoring and analysis of service dependent subscriber satisfaction in IP networks |
| US20020131496A1 (en) * | 2001-01-18 | 2002-09-19 | Vinod Vasudevan | System and method for adjusting bit rate and cost of delivery of digital data |
| US20020136298A1 (en) * | 2001-01-18 | 2002-09-26 | Chandrashekhara Anantharamu | System and method for adaptive streaming of predictive coded video data |
| US20020143969A1 (en) | 2001-03-30 | 2002-10-03 | Dietmar Loy | System with multiple network protocol support |
| EP1284551A1 (fr) * | 2001-08-08 | 2003-02-19 | Siemens Aktiengesellschaft | Marquage de qualité de service d'un transfert d'information dans un réseau de communication |
| US7567575B2 (en) * | 2001-09-07 | 2009-07-28 | At&T Corp. | Personalized multimedia services using a mobile service platform |
| US7218610B2 (en) * | 2001-09-27 | 2007-05-15 | Eg Technology, Inc. | Communication system and techniques for transmission from source to destination |
| US20030069963A1 (en) * | 2001-09-27 | 2003-04-10 | Nikil Jayant | System and method of quality of service signaling between client and server devices |
| US7327676B2 (en) * | 2001-10-11 | 2008-02-05 | Nippon Telegraph And Telephone Corporation | Data transmission control method, program therefor and data transmission unit using the same |
| JP2003169090A (ja) * | 2001-11-30 | 2003-06-13 | Fujitsu Ltd | 伝送システム |
| US20050011365A1 (en) * | 2001-12-11 | 2005-01-20 | Catherine Lamy | System for transmitting additional information via a network |
| US20030115504A1 (en) * | 2001-12-19 | 2003-06-19 | Holliman Matthew J. | Measurement of data degradation using watermarks |
| US7225266B2 (en) * | 2002-12-20 | 2007-05-29 | Nokia Corporation | Adaptive delayed ACK switching for TCP applications |
| EP1593046A2 (fr) * | 2003-02-13 | 2005-11-09 | Nokia Corporation | Procede et dispositif d'adaptation de debit pour la diffusion multimedia |
| AU2003219064A1 (en) * | 2003-03-17 | 2004-10-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for obtaining information about a transmission capability |
| US20050089092A1 (en) * | 2003-10-22 | 2005-04-28 | Yasuhiro Hashimoto | Moving picture encoding apparatus |
| WO2005057865A1 (fr) * | 2003-12-11 | 2005-06-23 | Matsushita Electric Industrial Co., Ltd. | Appareil transmetteur de paquets |
-
2003
- 2003-01-02 FR FR0300009A patent/FR2849733A1/fr active Pending
- 2003-12-15 JP JP2004564242A patent/JP4384992B2/ja not_active Expired - Fee Related
- 2003-12-15 WO PCT/EP2003/051012 patent/WO2004062226A1/fr active Application Filing
- 2003-12-15 MX MXPA05006837A patent/MXPA05006837A/es active IP Right Grant
- 2003-12-15 US US10/539,431 patent/US7739399B2/en active Active
- 2003-12-15 EP EP03799572A patent/EP1597891A1/fr not_active Withdrawn
- 2003-12-15 AU AU2003299239A patent/AU2003299239A1/en not_active Abandoned
- 2003-12-15 KR KR1020057012529A patent/KR100982630B1/ko active IP Right Grant
- 2003-12-15 CN CNB2003801081330A patent/CN100490443C/zh not_active Expired - Fee Related
Non-Patent Citations (2)
| Title |
|---|
| SCHULZRINNE H ET AL: "RFC 1889: RTP: A Transport Protocol for Real-Time Applications", NETWORK WORKING GROUP REQUEST FOR COMMENTS, XX, XX, January 1996 (1996-01-01), pages 1 - 38, XP002229836 * |
| SISALEM, WOLISZ: "MLDA: A TCP-friendly congestion control framework for heterogenous multicast environments", INTERNATIONAL WORKSHOP ON QUALITY OF SERVICE (IWQOS 2000), 5 June 2000 (2000-06-05) - 7 June 2000 (2000-06-07), Pittsburgh, XP002246388 * |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20050091054A (ko) | 2005-09-14 |
| US20060056523A1 (en) | 2006-03-16 |
| US7739399B2 (en) | 2010-06-15 |
| CN100490443C (zh) | 2009-05-20 |
| EP1597891A1 (fr) | 2005-11-23 |
| WO2004062226A1 (fr) | 2004-07-22 |
| JP2006512843A (ja) | 2006-04-13 |
| JP4384992B2 (ja) | 2009-12-16 |
| AU2003299239A1 (en) | 2004-07-29 |
| MXPA05006837A (es) | 2005-08-16 |
| CN1732666A (zh) | 2006-02-08 |
| KR100982630B1 (ko) | 2010-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2849733A1 (fr) | Dispositif et procede d'ajustement de debit d'un flux de contenus et produits associes | |
| US11489781B2 (en) | Bandwidth management | |
| US20050021830A1 (en) | Data communications method and system using buffer size to calculate transmission rate for congestion control | |
| CA2457193C (fr) | Procede et systeme de transmission des donnees pour la transmission de multiples flots de donnees par calcul de bande passante disponible par flot et choix de trains de bits | |
| FR2908576A1 (fr) | Procede,dispositif et application logicielle d'ordonnancement d'une transmission de paquets d'un flux de donnees | |
| EP1908259B1 (fr) | Appareil et procede d'estimation du taux de remplissage des tampons d'entree de clients d'une distribution de contenu temps reel | |
| CN111886875B (zh) | 一种通过网络传送媒体内容的方法及服务器 | |
| FR2863130A1 (fr) | Dispositif et procede de preparation de donnees d'emission et produits correspondants | |
| FR3076158A1 (fr) | Procede de regulation de debit | |
| FR2932938A1 (fr) | Procede et dispositif de transmission de donnees | |
| FR2946820A1 (fr) | Procede de transmission de donnees et dispositif associe. | |
| US11812114B2 (en) | Method and server for audio and/or video content delivery | |
| CN107483990B (zh) | 一种流媒体传输的动态码率调节方法、装置及传输系统 | |
| EP1172958A1 (fr) | Système de communication, émetteur, mèthode de protection contre des erreurs de transmission | |
| FR2923118A1 (fr) | Procede, dispositif et programme d'ordinateur pour la gestion de la quantite de donnees emises par un dispositif d'emission | |
| GB2577610A (en) | Improved congestion response | |
| EP3202061B1 (fr) | Gestion de la profondeur d'un tampon de gigue | |
| FR2917919A1 (fr) | Procede et dispositif de transmission d'images. | |
| GB2572357A (en) | Congestion response for timely media delivery | |
| FR2941110A1 (fr) | Procede et dispositif de prediction d'un etat de pertes d'un reseau de communication | |
| CN112640373A (zh) | 改善的拥塞响应 | |
| CN116684652A (zh) | 音视频拉取方法、装置、存储介质及计算机设备 | |
| FR2926177A1 (fr) | Procede et disositif de transmission de donnees avec partage specifique des ressources de debit d'un reseau. | |
| FR2934918A1 (fr) | Procede d'affichage d'une pluralite d'images sur un dispositif d'affichage video et dispositif associe. | |
| FR3032077A1 (fr) | Procede de diffusion multipoint d'un flux de donnees au format ip |