FR2933263A1 - Methode de reception de flux de donnees et methode d'emission correspondante - Google Patents

Methode de reception de flux de donnees et methode d'emission correspondante Download PDF

Info

Publication number
FR2933263A1
FR2933263A1 FR0854400A FR0854400A FR2933263A1 FR 2933263 A1 FR2933263 A1 FR 2933263A1 FR 0854400 A FR0854400 A FR 0854400A FR 0854400 A FR0854400 A FR 0854400A FR 2933263 A1 FR2933263 A1 FR 2933263A1
Authority
FR
France
Prior art keywords
reception
error correction
receiver
data stream
quality
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
Application number
FR0854400A
Other languages
English (en)
Inventor
Thierry Quere
Nicolas Debomy
Jean Claude Colmagro
Gilles Straub
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 FR0854400A priority Critical patent/FR2933263A1/fr
Priority to PL09772405T priority patent/PL2297960T3/pl
Priority to EP09772405.8A priority patent/EP2297960B1/fr
Priority to MX2010013962A priority patent/MX2010013962A/es
Priority to KR1020167006098A priority patent/KR101689789B1/ko
Priority to BRPI0914732-2A priority patent/BRPI0914732B1/pt
Priority to CN2009801254977A priority patent/CN102077593B/zh
Priority to ES09772405T priority patent/ES2754818T3/es
Priority to KR1020107029619A priority patent/KR101604361B1/ko
Priority to US12/737,259 priority patent/US8516345B2/en
Priority to JP2011515415A priority patent/JP5559780B2/ja
Priority to PCT/EP2009/058127 priority patent/WO2010000705A1/fr
Publication of FR2933263A1 publication Critical patent/FR2933263A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2383—Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/154—Measured or subjectively estimated visual quality after decoding, e.g. measurement of distortion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/164—Feedback from the receiver or from the transmission channel
    • H04N19/166—Feedback from the receiver or from the transmission channel concerning the amount of transmission errors, e.g. bit error rate [BER]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/188—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a video data packet, e.g. a network abstraction layer [NAL] unit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/65—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience
    • H04N19/67—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience involving unequal error protection [UEP], i.e. providing protection according to the importance of the data
    • 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2389—Multiplex stream processing, e.g. multiplex stream encrypting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4385—Multiplex stream processing, e.g. multiplex stream decrypting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/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/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
    • 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
    • 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server

Abstract

La présente invention se rapporte au domaine de la réception et de l'émission de flux de données, par exemple audio et vidéo. Plus précisément, l'invention concerne l'utilisation optionnelle de flux de correction d'erreurs associé à un flux de données.

Description

1. Domaine de l'invention. La présente invention se rapporte au domaine de la réception et de l'émission de flux de données, par exemple audio et vidéo. Plus précisément, l'invention concerne l'utilisation optionnelle de flux de correction d'erreurs associé à un flux de données.
2. Arrière-plan technologique.
Selon l'état de la technique, un flux de données, tel qu'un flux audio et/ou vidéo, émis via un réseau de transport de paquets, est associé à un ou plusieurs flux de correction d'erreurs, par exemple FEC (pour Forward Error Correction en anglais, ou correction préventive des erreurs ). Selon l'état de la technique, un récepteur de flux de données est capable d'utiliser un ou plusieurs flux de correction d'erreurs pour la correction d'erreurs qui peuvent être identifiés lors de la réception du flux de données. Un flux de correction d'erreurs associé à un flux de données comprend des données de redondance. Ces dernières permettent à un récepteur de corriger des erreurs à la réception, par exemple des paquets ou données perdus ou reçus avec erreurs. Un récepteur d'un flux de données, recevant un ou plusieurs flux de correction d'erreurs associés, peut ainsi corriger un certain nombre d'erreurs dans le flux de données reçu par une opération comprenant l'utilisation de paquets correctement reçus du flux de données et l'utilisation des données de redondance. La correction d'un flux de données par l'utilisation d'un ou plusieurs flux de correction d'erreurs associé permet de récupérer jusqu'à par exemple 20% de perte de paquets du flux de données sans impacter sur la qualité de rendu d'un flux vidéo, en fonction des paramètres d'encodage du flux de correction d'erreurs au niveau de l'émetteur.
Cette technique permet ainsi d'améliorer considérablement la qualité de rendu d'un flux vidéo en cas de perte de paquets ou en cas de réception de paquets erronés, pour des récepteurs qui sont sujets à ce type de perturbation.
Cependant, la génération d'un flux de correction d'erreurs par un émetteur, ainsi que l'utilisation d'un ou plusieurs flux de correction par un récepteur ont un impact non négligeable pour l'émetteur et pour le récepteur, en terme de charge CPU (de l'anglais Central Processing Unit , ou unité centrale de traitement en français) de délai d'émission, et/ou de délai de décodage , résultant en un délai d'affichage lors d'un changement de canal ou zapping , et/ou encore en terme d'occupation du réseau de transport ou d'utilisation de la bande passante du réseau (ou network bandwidth en anglais), pouvant limiter le nombre de flux de données qui peuvent être émis sur un réseau de transport de paquets.
Le standard pour la transmission de services vidéo et/ou audio DVB-IP disponible à l'ETSI sous le numéro ETSI TS 102 034 ayant pour titre Digital Video Broadcasting (DVB); Transport of MPEG-2 TS based DVB services over IP based networks (DVB-IPI) est un exemple d'utilisation de flux de correction d'erreurs au sein d'un réseau de transport de paquets. Selon l'art antérieur, l'utilisation d'un ou des flux de correction d'erreurs associé à un flux de données est prédéterminée pour un ensemble de récepteurs, même si certains récepteurs rencontrent peu d'erreurs, ce qui pénalise aussi bien l'émetteur que les récepteurs dans les termes exposés ci-dessus (charge CPU, temps de zapping, occupation du réseau de diffusion). Le flux de données et le ou les flux de correction d'erreurs sont bien souvent émis sur des adresses de diffusion multiple, à fin de rendre ces flux disponibles pour un grand nombre de récepteurs. Ainsi, l'état de la technique présente l'inconvénient d'une gestion non optimisée, d'un ou des flux de correction d'erreurs associé à un flux de données, via un réseau de transport de paquets. . Résumé de l'invention. L'invention a pour but de pallier ces inconvénients de l'art antérieur.
Plus particulièrement, l'invention a pour objectif d'optimiser l'utilisation d'un ou des flux de correction d'erreurs associés à un flux de données, émis via un réseau de transport de paquets.
A cet effet, l'invention propose une méthode de réception de flux de données, via un réseau de transport de paquets. Afin d'optimiser la réception, la méthode comprend les étapes suivantes : une étape de réception d'un flux de données ; une étape de réception d'un ou plusieurs flux de correction d'erreurs associé au flux de données ; un étape de changement d'état d'activation, d'une correction d'erreurs par l'utilisation d'un ou plusieurs flux de correction d'erreurs associé au flux de données en fonction d'un ou plusieurs critères de changement d'état d'activation d'une correction d'erreurs.
Selon une variante de la méthode de réception, le critère de 20 changement d'état comprend la qualité de réception du flux de données déterminée par le récepteur.
Selon une variante de la méthode de réception, le critère de changement d'état comprend une réception d'un signal de changement 25 d'état.
Selon une variante de la méthode de réception, le signal de changement d'état est compris dans le flux de données reçu.
30 Selon une variante de la méthode de réception, la qualité de la réception du flux de données comprend un nombre de gels vidéo observés. 3
Selon une variante de la méthode de réception, la détermination de la qualité de la réception du flux de données comprend un nombre de paquets perdus.
L'invention concerne également une méthode d'émission de flux de données, via un réseau de transport de paquets, qui comprend les étapes suivantes : une étape d'émission d'un flux de données comprenant un ou plusieurs flux de correction d'erreurs associé au flux de données vers un ou plusieurs récepteurs; une étape de réception d'une information représentative pour la qualité de réception du flux de données d'un ou plusieurs récepteur s ; une étape d'émission d'un signal de changement d'état d'activation d'une correction d'erreurs par une utilisation d'un ou plusieurs flux de correction d'erreurs, le signal étant émis à destination d'un ou plusieurs récepteurs, en fonction d'une qualité de réception déterminée à partir de l'information représentative pour la qualité de réception reçue d'un ou plusieurs récepteurs.
Selon une variante de la méthode d'émission, la détermination de la 20 qualité de la réception du flux de données comprend le nombre de gels vidéo observés par un ou plusieurs récepteurs. Selon une variante de la méthode d'émission, la détermination de la qualité de la réception dudit flux de données comprend un nombre de paquets perdus. 25 Selon une variante de la méthode d'émission, le signal de changement d'état est compris dans ledit flux de données.
4. Liste des figures. L'invention sera mieux comprise, et d'autres particularités et 30 avantages apparaîtront à la lecture de la description qui va suivre, la description faisant référence aux dessins annexés parmi lesquels : - les figures 1 et 2 présentent un synoptique schématique d'une infrastructure mettant en oeuvre l'invention selon deux modes de réalisation distincts; - la figure 3 présente un exemple d'un émetteur selon l'invention , appartenant à l'une des infrastructures illustrées en regard des figures 1 et 2 ; - la figure 4 présente un exemple d'un récepteur selon l'invention, appartenant à l'une des infrastructures illustrées en regard des figures 1 et 2; - la figure 5 illustre une méthode de réception de flux de données selon l'invention ; - la figure 6 illustre une méthode d'émission de flux de données selon l'invention. 5. Description détaillée de l'invention. La figure 1 présente un synoptique schématique d'une infrastructure 1 mettant en oeuvre l'invention selon un mode de réalisation. L'infrastructure 1 comprend : - une source 11 ; - un émetteur 10 ; - un récepteur 13 ; et - un réseau 12. L'émetteur 10 comprend : - un encodeur 100; - un générateur de flux de correction d'erreurs 102 ; et - une fonction d'affichage (ou monitoring ) de qualité de réception 101. L'encodeur 100 est relié à la source 11 par une connexion 1000 et au réseau 12 par une connexion 1001. Le générateur de flux de correction d'erreurs 102 est relié à l'encodeur 100 par la connexion 1001, et est relié de façon optionnelle au moniteur de qualité de réception par une connexion 1002, et est connecté au réseau 12 par une connexion 1005. Le moniteur de qualité de réception 101 est relié au réseau 12 par les connexions 1003 et 1004. Le récepteur 13 comprend : - une interface réseau 130 ; - une mémoire de réception 131 ; - un décodeur 132 ; - un correcteur d'erreurs de réception 133 ; et - un collecteur de données de qualité de réception 134.
L'interface réseau 130 est reliée au réseau 12 par une connexion 1200. La mémoire de réception est reliée à l'interface réseau 130 par une connexion 1300, par lequel le flux de données est envoyé. Le correcteur d'erreurs 133 est relié à l'interface réseau 130 par deux connexions 1304 et 1305. Le décodeur 132 est relié à la mémoire tampon de réception 131 par une connexion 1301. Le correcteur d'erreurs 133 est relié à la mémoire de réception 131 par une connexion 1306. La sortie du décodeur correspond à une connexion 1302. La source 11 fournit des données à transmettre à l'émetteur 10. L'émetteur 10 reçoit ces données, par exemple des données vidéo, dans un encodeur qui encode les données vidéo vers un flux vidéo comprimé selon par exemple le standard H.264. Le flux comprimé sortant de l'encodeur est fourni au générateur de flux de correction d'erreurs 102, et aussi par le réseau 12 au récepteur 13. Le générateur de flux de correction d'erreurs émet un ou plusieurs flux de correction d'erreurs associé au flux de données au récepteur 13 via le réseau 12 et la connexion 1005. Le moniteur de qualité de réception 101 reçoit l'information représentative pour la qualité de réception du flux de données du récepteur 13 par la connexion 1003. Ensuite, le moniteur 101 émet par la connexion 1004 un signal de changement d'état d'activation d'une correction d'erreurs par l'utilisation d'un ou plusieurs un flux de correction d'erreurs, en fonction d'une qualité de réception déterminée à partir de l'information reçue par le lien 1003.
Le récepteur 13 reçoit le flux de données 1300 et un ou plusieurs flux de correction d'erreurs émis via la connexion 1305 associé au flux de données émis via la connexion 1300. Le récepteur 13 reçoit aussi un signal de changement d'état 1304 émis par l'émetteur 10 via sa connexion 1200 au réseau 12, et peut en retour émettre une information représentative pour la qualité de réception du flux de données 1303, que l'émetteur reçoit via la connexion 1003. La mémoire de réception 131 est utilisée comme zone de tampon ( buffer en anglais), permettant de stocker un certain nombre de paquets. Le flux de paquets sortant de la mémoire de réception 131 alimente un décodeur 132 par une connexion 1301. Le décodeur 132 envoie le flux de données décodé sur le lien 1302. Le correcteur d'erreurs 133 reçoit un ou plusieurs flux de correction d'erreurs associé au flux de données par le lien 1305. Le correcteur d'erreurs et reçoit également un signal de changement d'état d'activation d'une correction d'erreurs par le lien 1304.
Selon l'état du signal, le correcteur d'erreurs 133 corrige ou ne corrige pas les paquets de flux de données dans la mémoire de réception 131, en utilisant ou en n'utilisant pas le ou les flux de correction d'erreurs reçu par la connexion 1305. Ainsi, le récepteur 13 reçoit un flux de données et un ou plusieurs flux de correction d'erreurs associés, et change d'état d'activation du correction d'erreurs en fonction d'un ou plusieurs critère s de changement d'état d'activation d'une correction d'erreurs. Selon une variante de mise en oeuvre de l'invention, le récepteur 13 comprend un collecteur de données de qualité de réception 134 qui lit dans la mémoire de réception via une connexion 1307 pour y collecter de l'information représentative pour la qualité de réception ; cette information est ensuite envoyé à l'émetteur 10 par le lien 1303 qui le relie à l'interface réseau 130. Cependant, il n'est pas nécessaire que tous les récepteurs d'un parc de récepteurs envoient cette information. Pour un émetteur mettant en oeuvre la méthode d'émission de l'invention, il suffit de recevoir l'information d'un ou plusieurs récepteurs (par exemple deux, trois, dix ou de plus). Ainsi, l'émetteur 10 peut déterminer une qualité de réception, à partir de l'information reçue d'un ou plusieurs récepteurs, c'est-à-dire de récepteurs équipés d'un collecteur 134 tel que décrite. Cela a comme avantage, de permettre à l'émetteur 10 de recevoir des informations sur la qualité de réception d'un nombre limité de récepteurs. Cela permet d'alléger le trafic de paquets sur le réseau, et de limiter l'impact sur la charge CPU d'aussi bien l'émetteur (qui traite moins de données) que pour des récepteurs dont, avantageusement, seulement une partie font la collection d'information sur la qualité de réception.
Selon une variante de mise en oeuvre de l'invention, le récepteur envoie l'information représentative de la qualité de réception du flux de données de façon périodique. Ceci a comme avantage pour un émetteur selon l'invention d'être toujours informé de la qualité de réception d'un flux de données par au moins un récepteur.
Selon une variante de mise en oeuvre de l'invention, le récepteur envoie l'information représentative de la qualité de réception du flux de données en cas de changement de qualité de réception. Ceci a comme avantage de limiter le trafic de messages circulant sur le réseau. Selon une variante de mise en oeuvre de l'invention, le récepteur envoie l'information représentative de la qualité de réception du flux de données en cas de dépassement d'un seuil de qualité de réception. Ceci a comme avantage de limiter le trafic de messages circulant sur le réseau. Selon une variante de mise en oeuvre de l'invention, le récepteur envoie l'information représentative pour la qualité de réception du flux de données en cas de zapping. Les variantes citées ci-dessus pour l'envoi de l'information représentative de la qualité de réception du flux de données peuvent bien entendu être combinées pour notamment procurer ainsi l'avantage de proposer un système efficace en terme de limitation du nombre de messages circulant sur le réseau.
Selon une variante de mise en oeuvre de l'invention, le collecteur 134 du récepteur 13 utilise une connexion 1308 qui le relie au décodeur 132, permettant d'observer le nombre de gels vidéo ( video freeze en anglais, ou arrêts vidéo en français), information qui est dans ce cas incluse dans l'information représentative pour la qualité de réception. Selon une variante de mise en oeuvre de l'invention, la détermination de la qualité de réception du flux de données par l'émetteur 10 comprend un nombre de gels vidéo observés par au moins un récepteur, détecté à partir de l'information envoyé via la connexion 1308 entre le décodeur 132 et le collecteur 134. Selon une variante de mise en oeuvre de l'invention, le collecteur de qualité de réception comprend un nombre de macro blocks observés dans un flux vidéo (une macro block est un artefact dans une image vidéo, occasionné par une erreur de décodage, par exemple du à la perte d'un paquet) et détecté à partir de l'information envoyé via la connexion 1308 du décodeur 132 au collecteur 134. Ces variantes ont comme avantage de prendre en compte la perturbation réelle , directement vécue par un ou plusieurs utilisateurs de récepteurs selon l'invention. Selon une variante de mise en oeuvre de l'invention, le collecteur de qualité de réception 134 du récepteur 13 collecte de l'information concernant un nombre de paquets perdus, information qui est dans ce cas incluse dans l'information représentative de la qualité de réception. Cela permet d'avoir une information directe sur la qualité de réception d'un ou des flux de données.
Bien entendu, les variantes d'écrites ci-dessus d'un mode de réalisation de l'invention comprenant un récepteur 13 avec un collecteur de données de qualité de réception 134 peuvent être combinés, pour inclure d'avantage de données dans l'information représentative pour la qualité de réception, envoyé par le récepteur 13.
Selon une variante de mise en oeuvre de l'invention, le moniteur de la qualité de réception 101 de l'émetteur 10 commande le générateur de flux de correction d'erreurs 102 par la connexion 1002, de façon à renforcer ou alléger le flux de correction d'erreurs en fonction de la qualité de réception déterminée. Par exemple, l'émission d'un codage FEC colonne est suffisant pour une qualité de réception déterminée comme étant moyenne, mais un l'émission d'un codage FEC colonne et ligne est nécessaire pour une qualité de réception déterminée comme étant mauvaise. Cela a comme avantage, par exemple, de pouvoir garder l'impact sur l'occupation de la bande passante du réseau 12 limité ainsi que de limiter l'impact de l'utilisation du flux de correction d'erreurs par le récepteur 13, par exemple en termes de délai de zapping. Selon une variante de mise en oeuvre de l'invention, le signal de changement d'état d'activation d'une correction d'erreurs émis par le moniteur 101 est inséré dans le flux de données. Ceci a l'avantage de permettre à un récepteur mettant en oeuvre la méthode de réception de l'invention de ne pas être obligé de faire une connexion spécifique pour la réception d'un signal de changement d'état d'activation de correction d'erreurs. La figure 2 présente un synoptique schématique d'une infrastructure 2 mettant en oeuvre l'invention selon un autre mode de réalisation. La figure 2 comprend des éléments qui ont déjà été décrits pour la figure 1, qui ont une fonction similaire dans la figure 2 et qui portent les mêmes références. L'infrastructure 2 comprend : - une source 11 ; - un émetteur 20 ; - un récepteur 22 ; et - un réseau 12. L'émetteur 20 comprend : - un encodeur 100; et - un générateur de flux de correction d'erreurs 102. Le récepteur 22 comprend : - une interface réseau 130 ; - une mémoire de réception 131 ; - un décodeur 132 ; - un correcteur d'erreurs de réception 133 ; et - un moniteur de qualité de réception 220. A la différence avec l'émetteur 10 de la figure 1, l'émetteur 20 de la figure 2 ne comprend pas de moniteur de qualité de réception 101. Une composante avec une fonction similaire se trouve dans le récepteur 22. A la différence avec le récepteur 13 de la figure 1, le récepteur 22 de la figure 2 comprend un moniteur de qualité de réception 220. Dans le figure 2, c'est le moniteur de qualité de réception 220 qui fournit un signal de changement d'état au correcteur d'erreurs 133 par la connexion 1304 ; dans la figure 1, ce signal est envoyé par l'émetteur 20. Dans ce mode de réalisation, l'émetteur 20 envoie un ou plusieurs flux de correction d'erreurs émis par le générateur de flux de correction d'erreurs 102. Ce flux de correction d'erreurs est associé à un flux de données émis par l'encodeur 100. Le récepteur 22 détermine lui-même la qualité de réception par le moniteur de qualité de réception 220 et effectue un changement d'état d'activation par l'émission d'un signal de changement d'état d'activation au correcteur d'erreurs 133 via la connexion 1304. Ce changement est fait en fonction d'un critère de changement d'état d'activation d'une correction d'erreurs, le critère étant la qualité de réception dans cette mise en oeuvre. Selon l'état de ce signal, le correcteur d'erreurs 133 utilise ou n'utilise pas le ou les flux de correction d'erreurs associé au flux de données. Selon une variante de mise en oeuvre de l'invention, le moniteur de qualité de réception 220 du récepteur 22 comprend une connexion provenant du décodeur 132, lui permettant d'observer le nombre de gels vidéo. Selon une variante de mise en oeuvre de l'invention, le moniteur de qualité de réception 220 comprend le nombre de macro blocks observé dans un flux vidéo. Cette information est dans ce cas prise en compte dans la détermination de la qualité de réception. Selon une variante de mise en oeuvre de l'invention, le moniteur de qualité de réception 220 collecte l'information représentative pour la qualité de réception du flux de données lors d'un zapping. Ainsi, la collecte d'information est faite lors de la connexion au flux de données, ce qui dans la pratique peut donner une bonne idée de la qualité de réception à laquelle un récepteur peut s'attendre, et cela permet d'allumer ou d'éteindre l'utilisation du flux de correction d'erreurs en limitant l'impact sur le décodage, car la prise en compte ou non d'un ou plusieurs flux de correction d'erreurs est dans ce cas faite au moment de la connexion et non pas pendant la connexion, ce qui évite des erreurs de décodage. Selon une variante de mise en oeuvre de l'invention, le moniteur de qualité de réception 220 collecte l'information représentative pour la qualité de réception du flux de façon périodique. Selon une variante de mise en oeuvre de l'invention, le signal de changement d'état est émis par le moniteur de qualité de réception 220 lorsque la qualité de réception déterminée par celui-ci dépasse un seuil prédéterminé. Par exemple, un signal de changement d'état d'activation allumage est envoyé quand le nombre de paquets perdus atteint le seuil de 3%, ou quand le nombre de gels vidéo dépasse le seuil 1 gel vidéo par minute ou encore quand le nombre de macro-blocks dans une image vidéo dépasse 1 macro block par 5 minutes. En revanche, un signal extinction est envoyé quand le nombre de paquets perdus ou le nombre de gels vidéo passe en dessous de ce seuil. Ces critères peuvent être combinés pour augmenter l'efficacité de la méthode de réception selon l'invention. Un délai de changement ou la prise en compte d'une marge dans les seuils peut être mise en oeuvre pour éviter un va-et-vient entre l'envoi d'un signal de changement d'état. Par exemple, une fois que le signal allumage est envoyé, un signal extinction n'est envoyé qu'après un certain délai dans lequel aucun erreur de réception est constaté, ou, une fois que le signal allumage est envoyé après avoir constaté le dépassement d'un seuil de 3% de paquets perdus, le signal extinction ne sera envoyé que quand le pourcentage de paquets perdus passe en dessous le seuil de 1%. Selon une variante de mise en oeuvre de l'invention, le signal de changement d'état est émis lorsque la qualité de réception atteint une valeur prédéterminée, comme par exemple dix paquets perdus, ou un gel vidéo observé. Ces modes de réalisation peuvent être combinées entre eux, par exemple le signal allumage est émis si le nombre de paquets perdus dépasse le seuil de 10%, ou si un gel vidéo est observé. La figure 3 illustre schématiquement l'émetteur 10 de la figure 1 selon un mode particulier de réalisation de l'invention. L'émetteur 10 comprend, reliés entre eux par un bus d'adresses et de données 350 : - un CPU 320 ; - une mémoire non volatile de type ROM (de l'anglais Read Only Memory ) 300 ; - une mémoire vive ou RAM (de l'anglais Random Access Memory ) 310 ; - une interface réseau 330 permettant l'émission et la réception de paquets d'un réseau de transport de paquets ; et - une interface source 340 permettant la réception d'un flux de données à encoder. On observe que le mot registre utilisé dans la description des mémoires décrites ici désigne dans chacune des mémoires mentionnées en regard des figures 3 et 4, aussi bien une zone de mémoire de faible capacité (quelques données binaires) qu'une zone mémoire de grande capacité (permettant de stocker un programme entier ou tout ou partie des données émises ou reçues). La mémoire ROM 300 comprend notamment : - un programme prog 301.
Les algorithmes mettant en oeuvre les étapes du procédé décrit ci-après sont stockés dans la mémoire ROM 300 associée à l'émetteur 10 mettant en oeuvre ces étapes. A la mise sous tension, le microprocesseur 320 charge et exécute les instructions de ces algorithmes.
La mémoire vive 310 comprend notamment : - dans un registre 311, le programme de fonctionnement du microprocesseur 320 qui est chargé à la mise sous tension de l'émetteur 10 ; - un registre 312 comprenant une partie du flux source à encoder; - un registre comprenant une partie du flux de données encodé, dans un registre 313; - un registre comprenant une partie du ou des flux de correction d'erreurs, dans un registre 314 ; - un registre 315 comprenant une information représentative de la qualité de réception ; et - une zone de données 316 permettant le stockage temporaire de données nécessaires pour le bon fonctionnement de l'émetteur 10.
La figure 4 illustre schématiquement un récepteur 13 de la figure 1 selon un mode particulier de réalisation de l'invention. Le récepteur 13 comprend les éléments suivants, reliés entre eux par un bus d'adresses et de données 450 : - un CPU 420,; - une mémoire non volatile de type ROM 400 ; - une mémoire vive ou RAM 410 ; et - une interface réseau 430 permettant l'émission et la réception de paquets d'un réseau de transport de paquets ; La mémoire ROM 400 comprend notamment : - un programme prog 401.
Les algorithmes mettant en oeuvre les étapes du procédé décrit ci-après sont stockés dans la mémoire ROM 400 associée au récepteur 13 mettant en oeuvre ces étapes. A la mise sous tension, le microprocesseur 420 charge et exécute les instructions de ces algorithmes.
La mémoire vive 410 comprend notamment : - dans un registre 411, le programme de fonctionnement du microprocesseur 420 qui est chargé à la mise sous tension du récepteur 13 ; - un registre 412 comprenant une partie du flux de données reçus ; - un registre 413 comprenant une partie du ou des flux de correction d'erreurs; - un registre 414 comprenant l'état d'activation de la correction d'erreurs ; et - une zone de données 415 permettant le stockage temporaire de données nécessaires pour le bon fonctionnement du récepteur 13. D'autres structures que celles décrite en regard des figure s 3 et 4 sont compatibles avec l'invention. En particulier, selon des variantes, l'invention est mise en oeuvre selon une réalisation purement matérielle ("hardware" en anglais), par exemple sous forme d'un composant dédié (par exemple dans un ASIC ou FPGA ou VLSI) (respectivement Application Specific Integrated Circuit en anglais, signifiant Circuit Intégré à vocation d'une application spécifique , Field-Programmable Gate Array en anglais, signifiant Réseau de Portes Programmable ln-Situ , Very Large Scale Integration en anglais, signifiant Intégration à très grande échelle )) ou de plusieurs composants électroniques intégrés dans un appareil ou encore sous forme d'un mélange d'éléments matériels et d'éléments logiciels ( software en anglais).
La figure 5 représente, sous forme d'algorithme, une méthode de réception selon l'invention mise en oeuvre dans le récepteur 13 ou 22.
La méthode de réception commence par une étape 500 au cours de laquelle différentes variables nécessaires à son bon fonctionnement sont initialisées. Ensuite, au cours d'une étape 510, le récepteur 13 ou 22 reçoit un 5 flux de données. Puis, lors d'une étape 520, le récepteur 13 ou 22 reçoit un ou plusieurs flux de correction d'erreurs. Selon des variantes, l'étape 520 est effectuée totalement ou en partie, avant ou en même temps que l'étape 510. Lors d'une étape de test 530, le récepteur 13 ou 22 vérifie si un 10 changement d'état d'activation d'une correction d'erreurs s'avère utile ou nécessaire, par exemple selon les critères tels que cités ci-dessous. Dans l'affirmative, au cours d'une étape 540, un changement d'état d'activation d'une correction d'erreurs est effectué, et l'étape 510 est réitérée. 15 Dans la négative, aucun changement d'état d'activation n'est effectué, et l'étape 510 est réitérée. Selon une variante de mise en oeuvre de l'invention, la méthode de réception comprend une étape de réception d'une requête pour envoi d'information représentative de la qualité de réception du flux de données. 20 Selon un mode de mise en oeuvre avantageuse de l'invention, au moins un critère de changement d'état d'activation d'une correction d'erreurs comprend un ou plusieurs des critères suivants : - un nombre de gels vidéo observé par un ou plusieurs récepteurs; - un nombre de macro blocks observé par un ou plusieurs récepteurs; 25 - un nombre de paquets perdus, constaté par un ou plusieurs récepteurs ; et - un nombre de paquets reçus avec des erreurs, constaté par un ou plusieurs récepteurs. La figure 6 représente, sous forme d'algorithme, une méthode 30 d'émission selon l'invention mise en oeuvre dans l'émetteur 10.
La méthode d'émission commence par une étape 600 au cours de laquelle différentes variables nécessaires à son bon fonctionnement sont initialisées. Ensuite, au cours d'une étape 610, l'émetteur 10 émet un flux de 5 données avec au moins un flux de correction d'erreurs associé. Lors d'une étape 620, l'émetteur 10 reçoit une information représentative de la qualité de réception d'au moins un récepteur. Lors d'une étape de test 630, l'émetteur 10 vérifie si un changement d'état d'activation d'une correction d'erreurs s'avère utile ou 10 nécessaire, en fonction d'au moins un critère de changement d'état d'activation d'une correction d'erreurs. Dans l'affirmative, au cours d'une étape 640, un signal de changement d'état d'activation d'une correction d'erreurs est émis, et l'étape 620 est réitérée. 15 Dans la négative, aucun signal de changement d'état d'activation n'est émis, et l'étape 620 est réitérée. Selon un mode de mise en oeuvre avantageuse de l'invention, au moins un critère de changement d'état d'activation d'une correction d'erreurs comprend un ou plusieurs des critères suivants : 20 - un nombre de gels vidéo observés par un ou plusieurs récepteurs; - un nombre de macro blocks observés par un ou plusieurs récepteurs; - un nombre de paquets perdus, constaté par un ou plusieurs récepteurs, ou même par un ou plusieurs appareils réseau ( network 25 equipment en anglais) ; et - un nombre de paquets reçus avec des erreurs, constaté par un ou plusieurs récepteurs. - le nombre d'équipement réseau ou de récepteurs constatant des pertes de paquets ou constatant la réception de paquets erronés. 30 Ces critères peuvent être combinés entre elles, par exemple pour déterminer la qualité de réception il peut être intéressant de connaître le nombre de récepteurs qui ont constaté une perte de paquets de plus de 1% des flux vidéo reçus. Selon une variante de mise en oeuvre de l'invention, la méthode d'émission comprend une étape d'émission d'une requête pour envoi d'information représentative de la qualité de réception du flux de données. Cela permet aussi de ne recevoir l'information de certains récepteurs, par exemple en particulier de récepteurs étant dans une partie du réseau ou la réception doit être testée plus précisément.
Selon une variante de mise en oeuvre de l'invention illustré par les figures 5 et 6 précédemment décrits, le changement d'état d'activation d'une correction d'erreurs est effectué lors que la valeur d'au moins un critère est supérieure à une valeur maximale d'un ou de plusieurs critères déterminée, ou inférieure à une valeur minimale d'un ou de plusieurs critères déterminée.
Par exemple, si la valeur maximale du nombre de gels vidéo vaut cinq, quand le nombre de gels vidéo dépasse cinq gels vidéo par heure, un changement d'état d'activation d'une correction d'erreurs vers un état allumage est effectué. Si la valeur minimale du nombre de gels vidéo vaut un, quand le nombre de gels vidéo passe en dessous de un gel vidéo par heure, un changement d'état d'activation d'une correction d'erreurs vers un état extinction est effectuée. Selon une variante de mise en oeuvre de l'invention illustrée par les figures 5 et 6, le changement d'état d'activation d'une correction d'erreurs est effectué lors du dépassement d'une valeur relative d'au moins un critère. Par exemple, quand le nombre de paquets perdus devient supérieur à 2% du nombre de paquets de flux de données reçus, un changement d'état d'activation d'une correction d'erreurs vers un état allumage est effectué. Quand le nombre de paquets perdus devient inférieur à o,1% du nombre de paquets de flux de données reçus, un changement d'état d'activation d'une correction d'erreurs extinction est effectuée.
Ces variantes de mise en oeuvre de l'invention peuvent être combinées entre elles, pour augmenter leur efficacité. Si plusieurs critères sont pris en compte, les éventuels conflits peuvent être gérés en attribuant une priorité relative à chaque critère, ou en y attribuant une opération logique : par exemple, si le nombre de gels dépasse le seuil maximale, mais le nombre de paquets perdus est en dessous la valeur minimale, un signal de changement d'état d'activation de correction d'erreurs allumage est effectué, le critère de nombre de gels vidéo étant plus important dans la détermination de la qualité de réception (la priorité la plus haute est donné au critère de nombre de gels vidéo). Si le nombre de paquets perdus passe en dessous du seuil minimal, le changement d'état n'est toutefois pas effectué si le nombre de gels vidéo n'est pas passé en dessous d'un seuil minimal (opération logique AND). La mesure de ces critères peut être faite en continu, ou périodiquement, aléatoirement ou lors d'un évènement (par exemple lors d'un zapping). Ces différentes façons de prendre la mesure pour la qualité de réception peuvent être combinées entre elles.
Bien entendu, l'invention ne se limite pas aux modes de réalisation décrits précédemment. Notamment, plusieurs étapes de la méthode de réception et de la méthode d'émission peuvent être exécutées en parallèle, comme la réception de trames, l'encapsulation, et la transmission, en ajoutant des moyens de communication et des zones de mémoires tampon entre ces étapes. Cela a notamment comme avantage de permettre une séparation de tâches spécifiques. En outre, la méthode de réception, ainsi que la méthode d'émission peut être mise en oeuvre non pas par un seul appareil, mais par un ensemble d'appareils distincts.
L'architecture des infrastructures 1 et 2 tels que décrits par les figures 1 et 2 peut comprendre d'autres appareils nécessaires au bon fonctionnement. Par exemple, plusieurs émetteurs peuvent être nécessaires pour fournir une offre de service étoffée. Par exemple, un serveur de management peut gérer le ou les émetteurs via un réseau interne LAN ( Local Access Network en anglais, pour Réseau à accès local ). Un tel serveur de management peut gérer aussi les suscriptions des utilisateurs des récepteurs à des offres de service. Par exemple, des équipements réseau tel que des routeurs ou des commutateurs ( switches en anglais) et spécifiques pour le protocole de transport utilisé peuvent être nécessaires pour accéder au réseau 12. Par exemple, le réseau 12 est un réseau communement appelé backbone à fibre optique avec protocole ATM, permettant un très haut débit et un débit garanti. Par exemple, les récepteurs sont connectés à ce backbone par des centres de distribution comprenant des DSLAM ( Digital Subscriber Line Access Multiplexer en anglais, pour multiplexeur de ligne numérique d'abonné ). Par exemple, un récepteur accède à un DSLAM par une ligne téléphonique et un modem ADSL ( Asynchronous Digital Subscriber Line en anglais, pour ligne asynchrone numérique d'abonné ). Par exemple, le récepteur accède au réseau 12 par un appareil d'accès spécifique (aussi appelé gateway en anglais) comprenant un modem ADSL, un routeur, un pare-feu ( Firewall en anglais), un émetteur / récepteur sans fil, etc, et peut y connecter plusieurs récepteurs au même temps. Le type de réseau utilisé peut être filaire, comme illustré ici, mais aussi sans-fil, en utilisant des techniques comme le WiFi, le DVB-H (standard DVB pour des appareils portables sans fil), DVB-T (standard DVB pour la réception de la télévision et radio en numérique par voie terrestre), ou DVB-S (standard DVB pour la réception de la télévision et radio en numérique par voie satellitaire) ou encore selon le standard ATSC (Advanced Television Systems Comittee). Mais aussi l'architecture des appareils figurant dans les infrastructures 1 et 2 des figures 1 et 2 peut être différente. Par exemple, plusieurs générateurs de flux de correction d'erreurs peuvent être ajoutés pour fournir un ou des flux de correction d'erreurs particulièrement adaptés à une partie du parc de récepteurs. Par exemple, le correcteur d'erreurs 133 d'un récepteur 13 ou 22 selon respectivement les figures 1 ou 2 relie la mémoire de réception 131 au décodeur 132.
La méthode de réception, ainsi que la méthode d'émission peut être mise en oeuvre en utilisant des protocoles de configuration, d'administration, de contrôle et de diagnostic, selon par exemple le protocole SNMP ou le protocole CWMP et ses extensions (de l'anglais Consumer Premises Equipment û Wide Area Network Management Protocol , pour protocole de gestion d'équipement chez le client au travers d'un réseau longue distance en français). L'invention peut être mise en oeuvre en utilisant le protocole SNMP ( Simple Network Management Protocol ou protocole simple de gestion de réseau en français) en mettant un SNMP manager au niveau de l'émetteur et un SNMP agent dans le récepteur et en ajoutant une MIB (de l'anglais Management Information Base , pour base d'information pour la gestion du réseau en français) avec un attribut spécifique pour la gestion de changement d'état d'activation de la correction d'erreurs par utilisation d'un ou plusieurs flux de correction d'erreurs. Pour cette mise en oeuvre, un attribut MIB peut être ajouté au niveau des récepteurs, du nom de fecConfiguration du type énuméré, admettant les valeurs décrites ci-après, accessible en lecture et en écriture : - FEC_NONE ( valeur d'énumération 0) ; - FEC_FORCED (valeur d'énumération 1) ; et - FEC_AUTO (valeur d'énumération 2).
La valeur FEC_NONE signifie qu'aucune correction d'erreurs par utilisation d'un ou plusieurs flux de correction d'erreurs n'est à faire par le récepteur. La valeur FEC_FORCED signifie que le récepteur doit obligatoirement utiliser le ou les flux de correction d'erreurs. La valeur FEC_AUTO signifie que le récepteur doit déterminer lui-même si un changement d'état d'activation d'une correction d'erreurs par utilisation d'un ou plusieurs flux de correction d'erreurs est à faire, en fonction des critères tel que décrits ici précédemment. Dans les deux premiers cas (FEC_NONE et FEC_FORCED), c'est l'émetteur qui détermine si un changement d'état d'activation d'une correction d'erreurs par utilisation d'un ou plusieurs flux de correction d'erreurs est nécessaire, en fonction d'un ou plusieurs critères tel que celles décrits ici précédemment. L'invention peut également être mise en oeuvre en utilisant le protocole CWMP et en ajoutant un ACS (de l'anglais Auto Configuration Server pour serveur d'auto configuration en français) au niveau de l'émetteur. Dans le récepteur, un agent CWMP est ajouté ainsi qu'un objet dans le récepteur comprenant des attributs spécifiques pour la gestion de changement d'état d'activation de la correction d'erreurs par utilisation d'un ou plusieurs flux de correction d'erreurs. Dans les termes du standard CWMP, le récepteur s'appelle CPE, et pour un CPE il existe alors deux modes d'activation de la correction d'erreurs : un mode forcée et un mode automatique . En mode forcée le CPE change d'état d'activation d'une correction d'erreurs par utilisation d'un ou plusieurs flux de correction en fonction d'un signal de changement d'état, envoyé par un émetteur ; c'est l'émetteur qui détermine le changement d'état en fonction d'au moins un critère de changement. En mode automatique , c'est le CPE lui -même qui change d'état d'activation en fonction d'au moins un critère de changement, déterminé par lui-même. La fonction dans le récepteur qui fait une correction d'erreurs par l'utilisation d'un ou plusieurs flux de correction d'erreurs s'appelle un module FEC ou décodeur FEC .
Pour cette mise en oeuvre, un objet FEC est ajouté dans la structure de données telle que définie par le standard TR-135 (défini par le Broadband Forum). Cet objet FEC fait partie de l'objet .STBService.{i}.Components.FrontEnd.{i}.IP tel que défini dans TR-135. Cet objet FEC contient les quatre paramètres suivants : - Enable ; - ForceFECEnable ; - OperationMode ; - AutoModeFECDecoderStatus. Les deux premiers (Enable, ForceFECEnable) sont des paramètres en accès écriture seulement. Les deux suivants (OperationMode, AutoModeFECDecoderStatus) sont en accès lecture seulement. Le paramètre Enable est de type booléen. Il permet d'activer ou de désactiver le module de FEC. Ecrire la valeur 1 dans le paramètre Enable a pour effet d'activer le module de FEC en mode de fonctionnement automatique. Cela signifie que le récepteur doit déterminer lui-même si un changement d'état d'activation d'une correction d'erreurs par utilisation d'un ou plusieurs flux de correction d'erreurs est à faire, en fonction des critères tel que décrits ici précédemment. Ecrire la valeur 0 dans le paramètre Enable a pour effet désactiver le module de FEC cela signifie qu'aucune correction d'erreurs par utilisation d'un ou plusieurs flux de correction d'erreurs n'est à faire par le récepteur. Ecrire 0 ou 1 dans le paramètre Enable se fait en utilisant la méthode SetParameterValue du protocole CWMP de Tr-069. Il s'agit ainsi d'un appel de fonction à distance qui est encapsulé dans une trame du protocole http. Parmi les paramètres de cet appel de fonction à distance, il y a le nom du paramètre, en l'occurrence ici la chaine de caractères suivante :STBService.{i}.Components.-FrontEnd.{i}.IP.FEC.Enable, ainsi que la valeur à écrire dans le booléen (0 ou 1). ForceFECEnable est un paramètre de type booléen. Ecrire la valeur 1 dans le paramètre Enable a pour effet d'activer le module de FEC en mode de fonctionnement forcé. Cela signifie que le récepteur doit obligatoirement utiliser le ou les flux de correction d'erreurs. Dans les cas ou la FEC est désactivée ou lorsqu'elle est forcée, c'est l'émetteur qui détermine si un changement d'état d'activation d'une correction d'erreurs par utilisation d'un ou plusieurs flux de correction d'erreurs est nécessaire, en fonction d'un ou plusieurs critères tel que celles décrits ici précédemment.
Dans le cas automatique, c'est le récepteur qui décide de l'activation ou non d'une correction d'erreurs par utilisation d'un ou plusieurs flux de correction d'erreurs, en fonction d'un ou plusieurs critères tel que celles décrits ici précédemment.
OperationMode est un paramètre de type énuméré et contient une description sous forme de chaine de caractères du mode de fonctionnement de récepteur. Disabled indique que la FEC n'est pas activée. Auto indique que le mode de fonctionnement de la FEC est automatique (ainsi que décrit précédemment). La valeur Forced indique que l'activation a été forcée. AutoModeFECDecoderStatus indique, dans le cas où le mode de fonctionnement est automatique, si le décodeur de FEC est en cours de fonctionnement ou non. FEC-ON indique que le récepteur utilise les données de FEC pour effectuer une correction d'erreurs. FEC-OFF indique que le récepteur n'utilise pas les données de FEC pour effectuer une correction d'erreurs. Un exemple de définition d'un objet FEC avec ses attributs, la valeur des attributs et leur signification se trouve illustré dans l'annexe. Le protocole SNMP est défini dans une série de documents appelés RFCs (de l'anglais Request For Comment pour demande de commentaires en français), comme la RFC 1157 : A Simple Network Management Protocol . Le protocole CWMP est défini par le document TR-069 et ses différents amendements ainsi que ses extensions (TR-098, TR-104, TR-106, TR-110, TR-111, TR-135, TR-140 et TR-142).
Les modes de réalisation tel que décrits ci-dessus sont des exemples de mise en oeuvre ; d'autres modes de réalisation sont possibles et compatibles avec l'invention. Notamment, en ce qui concerne une mise en oeuvre avec le protocole SNMP, d'autres attributs MIB peuvent être mises en place pour gérer la correction d'erreurs par utilisation d'un ou plusieurs flux de correction d'erreurs. Par exemple un attribut errorCorrection peut être défini, qui peut prendre des valeurs on , off , auto , pour allumé , éteint , c'est-à-dire forcée par un émetteur, et pour automatique , c'est-à-dire à déterminer par le récepteur lui-même. Par exemple, plusieurs attributs MIB peuvent être mise en place, pour gérer la fonction de changement d'état, par exemple en séparant des paramètres qui peuvent être écrits de celles qui peuvent être lus par un émetteur. En outre, en ce qui concerne la mise en oeuvre avec le protocole CWMP, d'autres attributs qu'un objet FEC et d'autres paramètres que celles que décrites peuvent être utilisés pour mettre en oeuvre l'invention. Par exemple, une correction d'erreurs par utilisation d'une ou plusieurs flux de correction d'erreurs peut ne pas utiliser des codes FEC, mais par exemple Reed-Solomon. Par exemple, les paramètres peuvent être combinés entre elles pour simplifier leur usage et limiter le nombre de messages nécessaires entre un récepteur et un émetteur. 5 ANNEXE
Tableau récapitulatif d'une mise en oeuvre de l'invention avec le protocole CWMP : définition des objets, attributs, valeurs et signification. .STBService.{i}.Components. Objet - Paramètres liée à la FrontEnd.{i}.IP.FEC. configuration de AL-FEC. Enable booleen Ecriture Allume ou éteint le fonctionnement du décodeur FEC. La valeur TRUE met le CPE en mode automatique, c'est-à-dire que l'appareil décide lui-même si elle allume un décodeur FEC ou non. La valeur FALSE éteint le décodeur FEC. ForceFECEnable Booleen Ecriture La valeur TRUE force le CPE à utiliser un décodeur FEC. La valeur FALSE n'a pas d'effet. OperationMode chaîne de Lecture Le mode d'opération du caractères décodeur FEC. Enumération de : "Disabled": Inhibé "Auto": Automatique "Forced": Forcé "Error" (OPTIONAL): Erreur (optionnelle) La valeur Error PEUT être utilisé par le CPE pour indiquer une erreur survenue localement. AutoModeFECDecoderStatus chaîne de Lecture L'état du décodeur FEC en caractères mode d'opération "automatique". En ce mode, le CPE decide lui- même de façon autonome s'il allume un décodeur FEC ou non. Cette paramètre indique si le CPE fait tourner un décodeur FEC ou non, au moment de l'interrogation. Enumération de : "FEC-ON": décodeur FEC allumé "FEC-OFF": décodeur FEC éteint "Error" (OPTIONAL): Erreur (optionnelle) La valeur Error PEUT être utilisé par le CPE pour indiquer une erreur survenue localement.

Claims (10)

  1. REVENDICATIONS1. Procédé de réception de flux de données, via un réseau REVENDICATIONS1. Procédé de réception de flux de données, via un réseau de transport de paquets, caractérisée en ce que le procédé comprend les étapes suivantes 5 mises en oeuvre dans un récepteur : - une réception d'un flux de données ; - une réception d'au moins un flux de correction d'erreurs associé audit flux de données ; - un changement d'état d'activation, d'une correction d'erreurs par 10 l'utilisation d'au moins un flux de correction d'erreurs associé audit flux de données en fonction d'au moins un critère de changement d'état d'activation d'une correction d'erreurs.
  2. 2. Procédé selon la revendication 1, caractérisée en ce que le critère de 15 changement d'état comprend une qualité de réception dudit flux de données déterminée par ledit récepteur.
  3. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisée en ce que le critère de changement d'état comprend une réception d'un signal de 20 changement d'état.
  4. 4. Procédé selon la revendication 3, caractérisée en ce que le signal de changement d'état est compris dans le flux de données reçu. 25
  5. 5. Procédé selon l'une quelconque des revendications 2 à 4 , caractérisée en ce que la qualité de la réception dudit flux de données comprend un nombre de gels vidéo observés.
  6. 6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisée en 30 ce que la détermination de la qualité de la réception dudit flux de données comprend un nombre de paquets perdus.
  7. 7. Procédé d'émission de flux de données, via un réseau de transport de paquets, caractérisée en ce que le procédé comprend les étapes suivantes : - une émission d'un flux de données comprenant au moins un flux de correction d'erreurs associé audit flux de données vers au moins un récepteur; - une réception d'une information représentative pour la qualité de réception dudit flux de données dudit au moins un récepteur ; - une émission d'un signal de changement d'état d'activation d'une correction d'erreurs par une utilisation dudit au moins un flux de correction d'erreurs, ledit signal étant émis à destination dudit au moins un récepteur, en fonction d'une qualité de réception déterminée à partir de ladite information représentative pour ladite qualité de réception reçue dudit au moins un récepteur.
  8. 8. Procédé selon la revendication 7, caractérisée en ce que la détermination de la qualité de la réception dudit flux de données comprend le nombre de gels vidéo observés par dudit au moins un récepteur.
  9. 9. Procédé selon l'une quelconque des revendications 7 à 8, caractérisée en ce que la détermination de la qualité de la réception dudit flux de données comprend un nombre de paquets perdus.
  10. 10. Procédé selon l'une quelconque des revendications 7 à 9, caractérisée en ce que le signal de changement d'état est compris dans ledit flux de données.25
FR0854400A 2008-06-30 2008-06-30 Methode de reception de flux de donnees et methode d'emission correspondante Pending FR2933263A1 (fr)

Priority Applications (12)

Application Number Priority Date Filing Date Title
FR0854400A FR2933263A1 (fr) 2008-06-30 2008-06-30 Methode de reception de flux de donnees et methode d'emission correspondante
PL09772405T PL2297960T3 (pl) 2008-06-30 2009-06-29 Sposób odbierania strumieni danych oraz odpowiedni sposób przesyłania
EP09772405.8A EP2297960B1 (fr) 2008-06-30 2009-06-29 Procédé servant à recevoir des flux de données et procédé de transmission correspondant
MX2010013962A MX2010013962A (es) 2008-06-30 2009-06-29 Metodo para recibir secuencias de datos y metodo de transmision correspondiente.
KR1020167006098A KR101689789B1 (ko) 2008-06-30 2009-06-29 데이터 스트림을 수신하기 위한 방법 및 송신을 위한 대응하는 방법
BRPI0914732-2A BRPI0914732B1 (pt) 2008-06-30 2009-06-29 método para recepção de fluxos de dados e método correspondente para transmissão
CN2009801254977A CN102077593B (zh) 2008-06-30 2009-06-29 用于接收数据流的方法以及用于发送的对应方法
ES09772405T ES2754818T3 (es) 2008-06-30 2009-06-29 Método para recibir flujos de datos y método correspondiente para la transmisión
KR1020107029619A KR101604361B1 (ko) 2008-06-30 2009-06-29 데이터 스트림을 수신하기 위한 방법 및 송신을 위한 대응하는 방법
US12/737,259 US8516345B2 (en) 2008-06-30 2009-06-29 Method for receiving data streams and corresponding method for transmission
JP2011515415A JP5559780B2 (ja) 2008-06-30 2009-06-29 データストリームの受信方法及びこれに対応する送信方法
PCT/EP2009/058127 WO2010000705A1 (fr) 2008-06-30 2009-06-29 Procédé servant à recevoir des flux de données et procédé de transmission correspondant

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0854400A FR2933263A1 (fr) 2008-06-30 2008-06-30 Methode de reception de flux de donnees et methode d'emission correspondante

Publications (1)

Publication Number Publication Date
FR2933263A1 true FR2933263A1 (fr) 2010-01-01

Family

ID=40677513

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0854400A Pending FR2933263A1 (fr) 2008-06-30 2008-06-30 Methode de reception de flux de donnees et methode d'emission correspondante

Country Status (11)

Country Link
US (1) US8516345B2 (fr)
EP (1) EP2297960B1 (fr)
JP (1) JP5559780B2 (fr)
KR (2) KR101689789B1 (fr)
CN (1) CN102077593B (fr)
BR (1) BRPI0914732B1 (fr)
ES (1) ES2754818T3 (fr)
FR (1) FR2933263A1 (fr)
MX (1) MX2010013962A (fr)
PL (1) PL2297960T3 (fr)
WO (1) WO2010000705A1 (fr)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9668083B2 (en) 2011-12-22 2017-05-30 Taiwan Semiconductor Manufacturing Co., Ltd. Systems and methods for cooperative applications in communication systems
US10097946B2 (en) * 2011-12-22 2018-10-09 Taiwan Semiconductor Manufacturing Co., Ltd. Systems and methods for cooperative applications in communication systems
EP2449708A4 (fr) * 2009-07-03 2014-08-27 Nokia Corp Procédé, appareils et service pour transmission de médias
JP5899518B2 (ja) * 2012-02-06 2016-04-06 パナソニックＩｐマネジメント株式会社 サーバ装置、システム制御方法及びシステム制御プログラム
CN103686055B (zh) * 2012-09-24 2017-05-10 中兴通讯股份有限公司 电视会议系统中丢包补偿的处理方法及装置
US20150089073A1 (en) 2013-09-25 2015-03-26 Ericsson Television Inc System and method for effectuating fast channel change in an adpative streaming environment
DE102016101023A1 (de) * 2015-01-22 2016-07-28 Sennheiser Electronic Gmbh & Co. Kg Digitales Drahtlos-Audioübertragungssystem
KR101671018B1 (ko) 2015-04-22 2016-10-31 (주)이즈미디어 스큐 자동 보정 방법 및 장치
US10291849B1 (en) * 2015-10-16 2019-05-14 Tribune Broadcasting Company, Llc Methods and systems for determining that a video-capturing device is unsteady
TWI622306B (zh) * 2016-06-08 2018-04-21 Chunghwa Telecom Co Ltd Public wireless local area network circuit quality measurement system and method
US11411989B2 (en) * 2017-04-27 2022-08-09 Arxan Technologies, Inc. Transmitting surreptitious data on an existing communication channel
US10705898B2 (en) * 2017-04-27 2020-07-07 Arxan Technologies, Inc. Transmitting surreptitious data on an existing communication channel
KR102027402B1 (ko) * 2017-10-31 2019-10-02 (주)이씨스 프레임 제어 메시지 슬롯을 이용한 노변 기지국의 통신 영역에 대한 검증 장치 및 방법
US11463747B2 (en) 2018-04-05 2022-10-04 Tvu Networks Corporation Systems and methods for real time control of a remote video production with multiple streams
US10966001B2 (en) * 2018-04-05 2021-03-30 Tvu Networks Corporation Remote cloud-based video production system in an environment where there is network delay
US11212431B2 (en) 2018-04-06 2021-12-28 Tvu Networks Corporation Methods and apparatus for remotely controlling a camera in an environment with communication latency

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1182816A2 (fr) * 2000-08-25 2002-02-27 Agere Systems Guardian Corporation Protection contre les erreurs d'un canal a travers des couches de reseau dans un système de communication
WO2003049449A2 (fr) * 2001-12-05 2003-06-12 Koninklijke Philips Electronics N.V. Hierarchisation a granularite fine mpeg-4 et algorithme de modulation combines destines a la transmission video sans fil
WO2004066706A2 (fr) * 2003-01-28 2004-08-12 Thomson Licensing S.A. Contenu de stockage de diffusion decalee en mode robuste
US20060072837A1 (en) * 2003-04-17 2006-04-06 Ralston John D Mobile imaging application, device architecture, and service platform architecture

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6625776B1 (en) * 1998-09-30 2003-09-23 Northrop Grumman Corporation Adaptive coding scheme for a processing communications satellite
JP2003234687A (ja) * 2002-02-06 2003-08-22 Nippon Telegr & Teleph Corp <Ntt> 無線通信システム
WO2005034521A1 (fr) 2003-10-06 2005-04-14 Koninklijke Philips Electronics, N.V. Transmission de television numerique a correction d'erreurs
AT13387U3 (de) * 2003-12-07 2015-09-15 Adaptive Spectrum & Signal Steuerverfahren und Steuerung für digitale Teilnehmer-Modempaare
US7653014B2 (en) * 2004-03-18 2010-01-26 Intel Corporation Configuring a transmission mode between devices
JP4641791B2 (ja) * 2004-12-15 2011-03-02 パイオニア株式会社 遠隔再生システム、遠隔再生方法およびコンピュータプログラム
JP4573663B2 (ja) 2005-02-16 2010-11-04 富士通株式会社 データ中継装置、データ中継方法、データ送受信装置およびデータ通信システム
JP4666309B2 (ja) * 2006-03-07 2011-04-06 財団法人エヌエイチケイエンジニアリングサービス 送信装置、受信装置、中継装置及びパケット伝送システム
US8170606B2 (en) * 2008-10-15 2012-05-01 Apple Inc. Dynamic thermal control for wireless transceivers

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1182816A2 (fr) * 2000-08-25 2002-02-27 Agere Systems Guardian Corporation Protection contre les erreurs d'un canal a travers des couches de reseau dans un système de communication
WO2003049449A2 (fr) * 2001-12-05 2003-06-12 Koninklijke Philips Electronics N.V. Hierarchisation a granularite fine mpeg-4 et algorithme de modulation combines destines a la transmission video sans fil
WO2004066706A2 (fr) * 2003-01-28 2004-08-12 Thomson Licensing S.A. Contenu de stockage de diffusion decalee en mode robuste
US20060072837A1 (en) * 2003-04-17 2006-04-06 Ralston John D Mobile imaging application, device architecture, and service platform architecture

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
OSTERBERG P ET AL: "Receiver-controlled joint source/channel coding on the application level, for video streaming over WLANs", VTC 2003-SPRING. THE 57TH. IEEE SEMIANNUAL VEHICULAR TECHNOLOGY CONFERENCE. PROCEEDINGS. JEJU, KOREA, APRIL 22 - 25, 2003; [IEEE VEHICULAR TECHNOLGY CONFERENCE], NEW YORK, NY : IEEE, US, vol. 3, 22 April 2003 (2003-04-22), pages 1558 - 1561, XP010862422, ISBN: 978-0-7803-7757-8 *
PASTRANA-VIDAL ET AL: "Métrique perceptuelle de rupture de fluidité vidéo sans référence", 9ÈMES JOURNÉES D'ÉTUDES ET D'ÉCHANGES "COMPRESSION ET REPRÉSENTATION DES SIGNAUX AUDIOVISUELS" (CORESA 2004), LILLE, 25-26 MAI 2004, 26 May 2004 (2004-05-26), XP002354701 *

Also Published As

Publication number Publication date
EP2297960A1 (fr) 2011-03-23
CN102077593A (zh) 2011-05-25
US20110179320A1 (en) 2011-07-21
KR20160033789A (ko) 2016-03-28
PL2297960T3 (pl) 2020-03-31
CN102077593B (zh) 2013-12-18
KR101689789B1 (ko) 2016-12-26
MX2010013962A (es) 2011-02-15
WO2010000705A1 (fr) 2010-01-07
JP5559780B2 (ja) 2014-07-23
EP2297960B1 (fr) 2019-08-21
BRPI0914732A2 (pt) 2015-10-20
KR101604361B1 (ko) 2016-03-25
US8516345B2 (en) 2013-08-20
KR20110039424A (ko) 2011-04-18
BRPI0914732B1 (pt) 2021-01-26
JP2011526750A (ja) 2011-10-13
ES2754818T3 (es) 2020-04-20

Similar Documents

Publication Publication Date Title
FR2933263A1 (fr) Methode de reception de flux de donnees et methode d&#39;emission correspondante
FR2927216A1 (fr) Methode de transmission d&#39;images numeriques et de reception de paquets de transport.
WO2007071560A1 (fr) Procede de transmission de services de television numerique, passerelle et reseau correspondants
FR2906950A1 (fr) Procede et dispositifs pour adapter le debit de transmission d&#39;un flux de donnees en presence d&#39;interferences.
FR2907627A1 (fr) Dispositif de selection de type de canal de transport pour la diffusion de contenus vers des terminaux de communication
FR2925808A1 (fr) Procede de communication dans un reseau comprenant un reseau primaire et un reseau secondaire
FR2888441A1 (fr) Appareil et procede d&#39;estimation du taux de remplissage des tampons d&#39;entree de clients d&#39;une distribution de contenu temps reel.
EP1974540A1 (fr) Passerelle pour la reception de services de diffusion de television numeriques, terminal et methodes correspondantes.
FR2933213A1 (fr) Methode d&#39;affichage d&#39;interface utilisateur et methode d&#39;emission correspondante
EP1977600B1 (fr) Methodes de diffusion ou de reception de services de video numeriques, appareils correspondants
FR2918832A1 (fr) Procedes de transmission de donnees par des noeuds relais dans un reseau de communication synchrone, procede de reception, produit programme d&#39;ordinateur, moyen de stockage et noeuds correspondants.
WO2008096086A2 (fr) Procede de traitement de perte de paquets
EP2025174A1 (fr) Utilisation d&#39;un canal de retour pour la diffusion d&#39;images
WO2022128693A1 (fr) Procédé et passerelle pour détecter et diagnostiquer des lenteurs dans un réseau local de communication sans fil
WO2009095590A1 (fr) Procede de transmission de contenus vod
FR2907297A1 (fr) Procede de notification d&#39;urgence dans un systeme de diffusion de services numeriques, dispositif emetteur et dispositif de reception mettant en oeuvre le procede
WO2021123586A1 (fr) Procede de gestion d&#39;une communication entre terminaux dans un systeme de telecommunications et dispositifs pour la mise en oeuvre du procede
CA3141585A1 (fr) Procede et systeme de detection d&#39;incidents dans au moins un reseau local de communication
FR3045997A1 (fr) Procede de gestion d&#39;un etat de ressources dans un reseau multimedia
FR2932933A1 (fr) Procedes et dispositifs de transmission et de reception de donnees
FR3114720A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu tenant compte de la qualité du signal échangé entre le terminal client et le point d’accès au réseau
FR3096850A1 (fr) Procede de transmission de donnees entre un emetteur et un recepteur dans un reseau de radiocommunications a capacite de bouclage local
WO2010012937A2 (fr) Procédé d&#39;optimisation d&#39;un temps de zapping sur un décodeur de télévision numérique
FR3079705A1 (fr) Communication par video conference
FR3032077A1 (fr) Procede de diffusion multipoint d&#39;un flux de donnees au format ip