ES2754818T3 - Método para recibir flujos de datos y método correspondiente para la transmisión - Google Patents

Método para recibir flujos de datos y método correspondiente para la transmisión Download PDF

Info

Publication number
ES2754818T3
ES2754818T3 ES09772405T ES09772405T ES2754818T3 ES 2754818 T3 ES2754818 T3 ES 2754818T3 ES 09772405 T ES09772405 T ES 09772405T ES 09772405 T ES09772405 T ES 09772405T ES 2754818 T3 ES2754818 T3 ES 2754818T3
Authority
ES
Spain
Prior art keywords
receiver
error correction
mode
data stream
flow
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.)
Active
Application number
ES09772405T
Other languages
English (en)
Inventor
Thierry Quere
Nicolas Debomy
Jean-Claude Colmagro
Gilles Straub
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital CE Patent Holdings SAS
Original Assignee
InterDigital CE Patent Holdings 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 InterDigital CE Patent Holdings SAS filed Critical InterDigital CE Patent Holdings SAS
Application granted granted Critical
Publication of ES2754818T3 publication Critical patent/ES2754818T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/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 encoded video stream packets from an IP network
    • H04N21/4385—Multiplex stream processing, e.g. multiplex stream decrypting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/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

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Quality & Reliability (AREA)
  • Communication Control (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Método para la recepción de un flujo de datos, a través de una red de transporte de paquetes, que comprende: - recepción por un receptor de un flujo de datos; - recepción por dicho receptor de al menos un flujo de corrección de errores asociado con dicho flujo de datos; - recepción por dicho receptor de una señal representativa de una selección de al menos uno de los siguientes modos: un modo de auto-determinación, o un modo forzado, o un modo de uso de corrección sin error; - si dicho modo es dicho modo de auto-determinación, dicho receptor auto-determina usar dicho al menos un flujo de corrección de errores según al menos un criterio, o, si dicho modo es dicho modo forzado, dicho receptor usa por la fuerza dicho al menos un flujo de corrección de errores, o, si dicho modo es dicho modo de uso de corrección sin error, dicho receptor no usa dicho al menos un flujo de corrección de errores.

Description

DESCRIPCIÓN
Método para recibir flujos de datos y método correspondiente para la transmisión
1. Alcance de la invención
La presente invención se refiere al campo de la recepción y transmisión de flujos de datos, por ejemplo, audio y vídeo. Más precisamente, la invención se refiere al uso opcional de flujos de corrección de errores asociados con un flujo de datos.
2. Antecedentes tecnológicos
Según el estado de la técnica, un flujo de datos, como un flujo de audio y/o vídeo, transmitido a través de una red de transporte de paquetes, está asociado con uno o varios flujos de corrección de errores, por ejemplo FEC (corrección de errores de reenvío). Según el estado de la técnica, un receptor de flujo de datos es capaz de usar uno o varios flujos de corrección de errores para corregir errores que pueden identificarse durante la recepción del flujo de datos.
Un flujo de corrección de errores asociado con un flujo de datos incluye datos de redundancia. Estos datos le permiten al receptor corregir errores en la recepción, por ejemplo paquetes o datos perdidos o recibidos con errores. Un receptor de flujo de datos, que recibe uno o varios flujos de corrección de errores asociados, puede corregir entonces un número de errores en el flujo de datos recibidos utilizando una operación que comprende el uso de paquetes recibidos correctamente del flujo de datos y el uso de datos de redundancia.
Una corrección de flujo de datos mediante el uso de uno o varios flujos de corrección de errores asociados permite la recuperación de hasta, por ejemplo, el 20% de la pérdida de paquetes en el flujo de datos sin afectar la propiedad de representación de un flujo de vídeo, según los parámetros de codificación del flujo de corrección de errores en el nivel del transmisor.
Por lo tanto, esta técnica permite una mejora considerable de la calidad de representación de un flujo de vídeo en el caso de pérdida de paquetes o en el caso de recepción de paquetes erróneos, para receptores que están sometidos a este tipo de perturbaciones.
Sin embargo, la generación de un flujo de corrección de errores por un transmisor, así como el uso de uno o varios flujos de corrección por un receptor tienen un impacto no despreciable para el transmisor y el receptor, en términos de carga de CPU (Unidad Central de Procesamiento), retraso de transmisión y/o retraso de decodificación, que da como resultado un retraso de visualización durante un cambio de canal o "zapping", y/o también en términos de ocupación de la red de transporte o de uso del ancho de banda de la red, lo que puede limitar el número de flujos de datos que se pueden transmitir en una red de transporte de paquetes.
La norma para la transmisión de servicios de vídeo y/o audio "DVB-IP" está disponible en el ETSI con el número ETSI TS 102 034 cuyo título es “Digital Video Broadcasting (DVB); Transport of MPEG-2 TS based DVB services over IP based networks (DVB-IPI)” es un ejemplo del uso de flujos de corrección de errores en una red de transporte de paquetes.
Según la técnica anterior, el uso de uno o varios flujos de corrección de errores asociados con un flujo de datos está predeterminado para un conjunto de receptores, incluso si algunos receptores encuentran pocos errores, lo que penaliza tanto al transmisor como a los receptores en relación con los términos anteriormente descritos (carga de CPU, tiempo de descarga, ocupación de la red de difusión). El flujo de datos y el flujo o flujos de corrección de errores a menudo se transmiten en direcciones de difusión de multidifusión, para que estos flujos estén disponibles para un gran número de receptores.
El documento P. Osterberg et al., "Receiver-controlled joint source/ channel coding on the application level, for video streaming over WLANs", PROCEEDINGS OF THE 57TH IEEE SEMIANNUAL VEHICULAR TECHNOLOGY CONFERENCE, JEJU, COREA, 22 - 25 de abril de 2003, volumen 3, páginas 1558-1561, describe un receptor capaz de autodeterminar el uso de uno o varios flujos de corrección de errores dependiendo de la tasa de pérdida de paquetes de medida o SNR.
Por lo tanto, el estado de la técnica tiene la desventaja de una gestión no optimizada, del flujo o flujos de corrección de errores asociados con un flujo de datos, a través de una red de transporte de paquetes.
3. Compendio de la invención
El fin de la invención es superar las desventajas de la técnica anterior.
Más particularmente, el fin de la invención es optimizar el uso del flujo o los flujos de corrección de errores asociados con un flujo de datos, transmitidos a través de una red de transporte de paquetes.
Para este fin, la invención propone un método, un receptor y un dispositivo transmisor según las reivindicaciones adjuntas.
4. Lista de figuras
La invención se entenderá mejor y surgirán otras características y ventajas específicas al leer la siguiente descripción, haciendo referencia la descripción a los dibujos anexos en los que:
- las figuras 1 y 2 muestran un diagrama de bloques de una infraestructura que implementa la invención según dos realizaciones diferentes,
- la figura 3 muestra un ejemplo de un transmisor según la invención que pertenece a una de las infraestructuras ilustradas en las figuras 1 y 2,
- la figura 4 muestra un ejemplo de un receptor según la invención que pertenece a una de las infraestructuras ilustradas por las figuras 1 y 2;
- la figura 5 ilustra un método para la recepción de un flujo de datos según la invención;
- la figura 6 ilustra un método para la transmisión de un flujo de datos según la invención.
5. Descripción detallada de la invención
La figura 1 muestra un diagrama de bloques de una infraestructura 1 que implementa la invención según una realización.
La infraestructura 1 comprende:
- una fuente 11,
- un transmisor 10,
- un receptor 13, y
- una red 12.
El transmisor 10 comprende:
- un codificador 100,
- un generador 102 de flujo de corrección de errores, y
- una función para mostrar (o "monitorizar") la calidad 101 de recepción.
El codificador 100 está conectado a la fuente 11 por una conexión 1000 y a la red 12 por una conexión 1001. El generador 102 de flujo de corrección de errores está conectado al codificador 100 por la conexión 1001, y está conectado opcionalmente al monitor de calidad de recepción por una conexión 1005. El monitor 101 de calidad de recepción está conectado a la red 12 mediante las conexiones 1003 y 1004.
El receptor 13 comprende:
- una interfaz 130 de red,
- una memoria 131 de recepción,
- un decodificador 132,
- un corrector 133 de errores de recepción, y
- un recopilador de datos 134 de calidad de recepción.
La interfaz 130 de red está conectada a la red 12 por una conexión 1200. La memoria de recepción está conectada a la interfaz 130 de red por una conexión 1300, por la cual se envía el flujo de datos. El corrector 133 de errores está conectado a la interfaz 130 de red por dos conexiones 1304 y 1305. El decodificador 132 está conectado a la memoria intermedia 131 de recepción por una conexión 1301. El corrector 133 de errores está conectado a la memoria intermedia 131 de recepción por una conexión 1306. La salida del decodificador corresponde a una conexión 1302. La fuente 11 proporciona datos para transmitirse al transmisor 10. El transmisor 10 recibe estos datos, por ejemplo datos de vídeo, en un codificador que codifica datos de vídeo a un flujo de vídeo comprimido, por ejemplo, según la norma H.264. El flujo comprimido que se emite del codificador se proporciona al generador 102 de flujo de corrección de errores, y también a través de la red 12 al receptor 13. El generador de flujo de corrección de errores transmite uno o varios flujos de corrección de errores asociados con el flujo de datos al receptor 13 a través de la red 12 y la conexión 1005. El monitor 101 de calidad de recepción recibe el elemento de información representativo de la calidad de recepción del flujo de datos del receptor 13 por la conexión 1003. A continuación, el monitor 101 transmite por la conexión 1004 una señal que indica un cambio en el estado de activación de una corrección de errores mediante el uso de uno o varios flujos de corrección de errores, según una calidad de recepción determinada a partir del elemento de información recibido por la conexión 1003.
El receptor 13 recibe el flujo 1300 de datos y uno o varios flujos de corrección de errores transmitidos a través de la conexión 1305 asociada con el flujo de datos transmitidos a través de la conexión 1300. El receptor 13 también recibe una señal de cambio en el estado de activación 1304 transmitido por el transmisor 10 a través de su conexión 1200 a la red 12, y a cambio puede transmitir un elemento de información representativo de la calidad de recepción del flujo 1303 de datos, que el transmisor recibe a través de la conexión 1003. La memoria 131 de recepción se usa como memoria intermedia, permitiendo que se almacene una cierta cantidad de paquetes. El flujo de paquetes que sale de la memoria 131 de recepción alimenta un decodificador 132 por una conexión 1301. El decodificador 132 envía el flujo de datos decodificado en el enlace 1302. El corrector 133 de errores recibe uno o varios flujos de corrección de errores asociados con el flujo de datos a través de la conexión 1305. El corrector de errores también recibe una señal de cambio en el estado de activación de una corrección de errores a través del enlace 1304. Según el estado de la señal, el corrector 133 de errores corrige o no corrige los paquetes de flujo de datos en la memoria 131 de recepción, utilizando o no el flujo o flujos de corrección de errores recibidos a través de la conexión 1305.
Entonces, el receptor 13 recibe un flujo de datos y una o varias correcciones de errores asociadas, y cambia el estado de activación de una corrección de error según uno o varios criterios de cambio en el estado de activación de una corrección de error.
Según una implementación variante de la invención, el receptor 13 incluye un colector 134 de datos de calidad de recepción que lee en la memoria de recepción a través de una conexión 1307 para recopilar allí un elemento de información representativo de la calidad de recepción, este elemento de información se envía a continuación al transmisor 10 por la conexión 1301 que lo conecta a la interfaz 130 de red. Sin embargo, no es necesario que todos los receptores de un conjunto de receptores envíen este elemento de información. Para un transmisor que implementa el método de transmisión según la invención, es suficiente recibir el elemento de información de uno o varios receptores (por ejemplo, dos, tres, diez o más). Entonces, el transmisor 10 puede determinar una calidad de recepción, a partir del elemento de información recibido de uno o varios receptores, es decir, de receptores equipados con un colector 134 como se describe. La ventaja de esto es permitir que el transmisor 10 reciba información sobre la calidad de recepción de un número limitado de receptores. Esto permite una reducción del tráfico de paquetes en la red y limita el impacto en la carga de la CPU del transmisor (que procesa menos datos) así como de los receptores, solo una parte de los cuales, ventajosamente, recopilan información sobre la calidad de la recepción.
Según una implementación variante de la invención, el receptor envía periódicamente el elemento de información representativo de la calidad de recepción del flujo de datos. Esto tiene la ventaja de que al menos un receptor informa constantemente a un transmisor según la invención sobre la calidad de recepción de un flujo de datos.
Según una implementación variante de la invención, el receptor envía el elemento de información representativo de la calidad de recepción del flujo de datos en caso de cambio de calidad de recepción. Esto tiene la ventaja de limitar el tráfico de mensajes que circulan en la red.
Según una implementación variante de la invención, el receptor envía el elemento de información representativo de la calidad de recepción del flujo de datos si se supera un umbral de calidad de recepción. Esto tiene la ventaja de limitar el tráfico de mensajes que circulan en la red.
Según una implementación variante de la invención, el receptor envía el elemento de información representativo de la calidad de recepción del flujo de datos en caso de hacer zapping.
Por supuesto, las variantes descritas anteriormente para enviar el elemento de información representativo de la calidad de recepción del flujo de datos pueden combinarse para, en particular, proporcionar de esta manera la ventaja de proponer un sistema eficiente en términos de limitación del número de mensajes que circulan en la red.
Según una implementación variante de la invención, el colector 134 del receptor 13 usa una conexión 1308 que lo conecta al decodificador 132, permitiendo que se observe el número de congelaciones de vídeo, un elemento de información que, en este caso, se incluye en el elemento de información representativa de la calidad de recepción.
Según una implementación variante de la invención, la determinación de la calidad de recepción del flujo de datos por el transmisor 10 incluye un número de congelaciones de vídeo observadas por al menos un receptor, detectadas a partir del elemento de información enviado a través de la conexión 1308 entre el decodificador 132 y el colector 134.
Según una implementación variante de la invención, el colector de calidad de recepción comprende un número de macrobloques observados en una secuencia de vídeo (un macrobloque es un artefacto de imagen de vídeo, debido a un error de decodificación, por ejemplo debido a una pérdida de paquetes) y detectados desde el elemento de información enviado a través de la conexión 1308 desde el decodificador 132 al colector 134. Estas variantes tienen la ventaja de tener en cuenta la perturbación "real", experimentada directamente por uno o varios usuarios del receptor según la invención.
Según una implementación variante de la invención, el colector 134 de calidad de recepción del receptor 13 recopila un elemento de información sobre un número de paquetes perdidos, este elemento de información está incluido en este caso en el elemento de información representativo de la calidad de recepción. Esto permite tener información directa sobre la calidad de recepción de uno o varios flujos de datos.
Por supuesto, las implementaciones variantes de la invención descritas anteriormente que comprenden un receptor 13 con un colector 134 de datos de calidad de recepción se pueden combinar para incluir más datos en el elemento de información representativo de la calidad de recepción, enviado por el receptor 13.
Según una implementación variante de la invención, el monitor 101 de calidad de recepción del transmisor 10 controla el generador 102 de flujo de corrección de errores a través de la conexión 1002, para reforzar o aligerar el flujo de corrección de errores según la calidad de recepción determinada. Por ejemplo, la transmisión de una codificación FEC de columna es suficiente para una calidad de recepción determinada como promedio, pero la transmisión de una codificación FEC de columna y línea es necesaria para una calidad de recepción determinada como mala. Esto tiene la ventaja, por ejemplo, de permitir el impacto en la ocupación del ancho de banda de la red 12, así como de limitar el impacto del uso del flujo de corrección de errores por parte del receptor 13, por ejemplo, en términos de tiempo de zapping.
Según una variante de implementación de la invención, la señal de cambio en el estado de activación de una corrección de errores transmitida por el monitor 101 se inserta en el flujo de datos. Esto tiene la ventaja de no obligar a que un receptor implemente el método de recepción de la invención para establecer una conexión específica para la recepción de una señal de cambio en el estado de activación de la corrección de errores.
La figura 2 muestra un diagrama de bloques de una infraestructura 2 que implementa la invención según otra realización. La figura 2 comprende algunos elementos que ya se han descrito para la figura 1, que tienen una función similar en la figura 2 y que tienen las mismas referencias.
La infraestructura 2 comprende:
- una fuente 11,
- un transmisor 20,
- un receptor 22, y
- una red 12.
El transmisor 20 comprende:
- un codificador 100, y
- un generador 102 de flujo de corrección de errores.
El receptor 22 comprende:
- una interfaz 130 de red,
- una memoria 131 de recepción,
- un decodificador 132,
- un corrector 133 de errores de recepción, y
- un monitor 220 de calidad de recepción.
En una variación del transmisor 10 de la figura 1, el transmisor 20 de la figura 2 no incluye un monitor 101 de calidad de recepción. Un componente con una función similar se coloca en el receptor 22. A diferencia del receptor 13 de la figura 1, el receptor 22 de la figura 2 incluye un monitor 220 de calidad de recepción. En la figura 2, es el monitor 220 de calidad de recepción el que proporciona una señal de cambio de estado al corrector 133 de errores a través de la conexión 1304; en la figura 1, esta señal se envía por el transmisor 20.
En esta realización, el transmisor 20 envía uno o varios flujos de corrección de errores transmitidos por el generador 102 de flujo de corrección de errores. Este flujo de corrección de errores está asociado con un flujo de datos transmitido por el codificador 100. El receptor 22 determina por sí mismo la calidad de recepción utilizando el monitor 220 de calidad de recepción y realiza un cambio en el estado de activación a través de la transmisión de un cambio en el estado de la señal de activación al corrector 133 de errores a través de la conexión 1304. Este cambio se realiza según un criterio de cambio en el estado de activación de una corrección de errores, siendo el criterio la calidad de recepción en esta implementación. Según el estado de esta señal, el corrector 133 de errores utiliza o no el flujo o los flujos de corrección de errores asociados con el flujo de datos.
Según una implementación variante de la invención, el monitor 220 de calidad de recepción del receptor 22 comprende una conexión procedente del decodificador 132, que le permite observar el número de congelaciones de vídeo. Según una implementación variante de la invención, el monitor 220 de calidad de recepción comprende el número de macrobloques observados en una secuencia de vídeo. Este elemento de información se tiene en cuenta en este caso en la determinación de la calidad de recepción.
Según una implementación variante de la invención, el monitor 220 de calidad de recepción recopila el elemento de información representativo de la calidad de recepción del flujo de datos durante un zapping. A continuación, la recopilación de información se realiza durante la conexión al flujo de datos, lo que en la práctica puede proporcionar una buena idea de la calidad de recepción que puede esperar un receptor, y esto permite que el uso del flujo de corrección de errores se active o desactive y limite impacto en la decodificación, porque tener en cuenta o no uno o varios flujos de corrección de errores se realiza en este caso en el momento de la conexión y no durante la conexión, lo que evita errores de decodificación.
Según una implementación variante de la invención, el monitor 220 de calidad de recepción recopila el elemento de información representativo de la calidad de recepción del flujo de una manera periódica.
Según una variante de implementación de la invención, la señal de cambio en el estado de activación se transmite por el monitor 220 de calidad de recepción cuando la calidad de recepción determinada por este supera un umbral predeterminado. Por ejemplo, se envía una señal de cambio en el estado de activación "encendido" cuando el número de paquetes perdidos alcanza el umbral del 3 %, o cuando el número de congelaciones de vídeo supera el umbral de 1 congelación de vídeo por minuto, o cuando el número de macrobloques en una imagen de vídeo supera 1 macrobloque cada 5 minutos. Sin embargo, se envía una señal de "apagado" cuando el número de paquetes perdidos o el número de congelaciones de vídeo es inferior a este umbral. Estos criterios se pueden combinar para aumentar la eficacia del método de recepción según la invención. Se puede implementar un retardo de cambio o tener en cuenta un margen en los umbrales para evitar un cambio de ida y vuelta entre el envío de una señal de cambio de estado. Por ejemplo, una vez que se envía la señal de "encendido", se envía una señal de "apagado" solo después de un cierto tiempo durante el cual no se observa ningún error de recepción, o, una vez que se envía la señal de "encendido" después de haber notado que se ha superado un umbral del 3 % de los paquetes perdidos, la señal de "apagado" se enviará solo cuando el porcentaje de los paquetes perdidos va por debajo del umbral del 1 %.
Según una variante de realización de la invención, la señal de cambio de estado se transmite cuando la calidad de recepción alcanza un valor predeterminado, tal como por ejemplo diez paquetes perdidos, o cuando se observa una congelación de vídeo.
Estas realizaciones se pueden combinar entre sí, cuando, por ejemplo, la señal de "encendido" se transmite si el número de paquetes perdidos supera el umbral del 10 %, o si se observa una congelación de vídeo.
La figura 3 ilustra esquemáticamente el transmisor 10 de la figura 1 según una realización particular de la invención. El transmisor 10 comprende, interconectados por una dirección y un bus de datos 350:
- una CPU 320,
- una memoria no volátil de tipo ROM (memoria de solo lectura) 300,
- una memoria de acceso aleatorio o RAM 310,
- una interfaz 330 de red que permite transmitir y recibir paquetes de una red de transporte de paquetes, y
- una interfaz 340 fuente que permite codificar la recepción de un flujo de datos.
Cabe señalar que la palabra "registro" utilizada en la descripción de las memorias descritas aquí designa en cada una de las memorias mencionadas con respecto a las figuras 3 y 4, un área de memoria de baja capacidad (algunos datos binarios), así como un área de memoria de gran capacidad (que permite almacenar un programa completo o la totalidad o parte de los datos transmitidos o recibidos).
La memoria ROM 300 incluye entre otros:
- un programa "prog" 301.
Los algoritmos que implementan las etapas del método descrito a continuación se almacenan en la memoria ROM 300 asociada con el transmisor 10 que implementa estas etapas. Cuando se enciende, la CPU 320 carga y ejecuta las instrucciones de estos algoritmos.
La memoria 310 de acceso aleatorio comprende de manera destacable:
- en un registro 311, el programa operativo de la CPU 320 que se carga con el encendido del transmisor 10, - un registro 312 que comprende una parte del flujo fuente a codificar,
- un registro que comprende una parte del flujo de datos codificados, en un registro 313,
- un registro que comprende una parte del flujo o flujos de corrección de errores, en un registro 314,
- un registro 315 que comprende información representativa de la calidad de recepción, y
- un área 316 de datos que permite el almacenamiento temporal de la fecha requerida para el correcto funcionamiento del transmisor 10.
La figura 4 ilustra esquemáticamente un receptor 13 de la figura 1 según una realización particular de la invención. El receptor 13 comprende los siguientes elementos, conectados entre sí por un bus 450 de direcciones y de datos: - una CPU 420,
- una memoria 400 de tipo ROM no volátil,
- una memoria de acceso aleatorio o RAM 410, y
- una interfaz 430 de red que permite la transmisión y recepción de paquetes desde una red de transporte de paquetes.
La memoria ROM 400 comprende de manera destacable:
- un programa "prog" 401.
Los algoritmos que implementan las etapas del método descrito a continuación se almacenan en la memoria ROM 400 asociada con el receptor 13 que implementa estas etapas. Al encenderse, la CPU 420 carga y ejecuta las instrucciones de estos algoritmos.
La memoria 410 de acceso aleatorio comprende de manera destacable:
- en un registro 411, el programa operativo de la CPU 420 que se carga al encender el receptor 13,
- un registro 412 que comprende una parte del flujo de datos recibido,
- un registro 413 que comprende una parte del flujo o flujos de corrección de errores,
- un registro 414 que comprende el estado de activación de la corrección de errores, y
- un área 415 de datos que permite el almacenamiento temporal de datos necesarios para el correcto funcionamiento del receptor 13.
Son compatibles con la invención otras estructuras distintas de las descritas con respecto a las figuras 3 y 4. En particular, según las variantes, la invención se implementa según una realización de hardware puro, por ejemplo, en forma de un componente especializado (por ejemplo, en un ASIC (Circuito Integrado Específico de la Aplicación) o FPGA (Campo de Matrices de Puertas Programables) o VLSI (Integración a Muy Gran Escala) o de varios componentes electrónicos integrados en un aparato o incluso en forma de una combinación de elementos de hardware y elementos de software.
La figura 5 representa, en forma de algoritmo, un método de recepción según la invención implementado en el receptor 13 o 22.
El método de recepción comienza con una etapa 500 durante la cual se inicializan diferentes variables requeridas para su correcto funcionamiento.
A continuación, durante una etapa 510, el receptor 13 o 22 recibe un flujo de datos.
A continuación, durante una etapa 520, el receptor 13 o 22 recibe uno o más flujos de corrección de errores. Según las variantes, la etapa 520 se lleva a cabo total o parcialmente, antes o al mismo tiempo que la etapa 510.
Durante una etapa de prueba 530, el receptor 13 o 22 verifica si un cambio en el estado de activación de una corrección de errores sería útil o necesario, por ejemplo, según criterios tales como los citados a continuación.
En caso afirmativo, durante una etapa 540, se lleva a cabo un cambio en el estado de activación de una corrección de errores, y se reitera la etapa 510.
En caso negativo, no se lleva a cabo ningún cambio de estado de activación, y se reitera la etapa 510.
Según una implementación variante de la invención, el método de recepción comprende una etapa de recepción de una solicitud para enviar información representativa de la calidad de recepción del flujo de datos.
Según un modo de implementación ventajoso de la invención, al menos un cambio en el estado de activación de un criterio de corrección de errores comprende uno o más de los siguientes criterios:
- un número de congelaciones de vídeo observadas por uno o más receptores,
- un número de macrobloques observados por uno o más receptores,
- un número de paquetes perdidos, observados por uno o más receptores, y
- un número de paquetes recibidos con errores, observados por uno o más receptores.
La figura 6 representa, en forma de algoritmo, un método de transmisión según la invención implementado en el transmisor 10.
El método de transmisión comienza con una etapa 600 durante la cual se inicializan diferentes variables requeridas para su correcto funcionamiento.
A continuación, durante una etapa 610, el transmisor 10 transmite un flujo de datos con al menos un flujo de corrección de errores asociado.
Durante una etapa 620, el transmisor 10 recibe un elemento de información representativo de la calidad de recepción de al menos un receptor.
Durante una etapa de prueba 630, el transmisor 10 verifica si un cambio en el estado de activación de una corrección de errores sería útil o necesario, según al menos un criterio de cambio en el estado de activación de una corrección de errores.
En caso afirmativo, durante una etapa 640, se transmite un cambio en el estado de activación de una señal de corrección de errores, y en la etapa 620 se reitera.
En caso negativo, no se transmite ninguna señal de cambio en el estado de activación, y se reitera la etapa 620.
Según una implementación ventajosa de la invención, al menos un criterio de cambio en el estado de activación de una corrección de errores comprende uno o más de los siguientes criterios:
- un número de congelaciones de vídeo observadas por uno o más receptores,
- un número de macrobloques observados por uno o más receptores,
- un número de paquetes perdidos, observados por uno o más receptores, o incluso por uno o más elementos de equipos de red, y
- un número de paquetes recibidos con errores, observados por uno o más receptores.
- el número de elementos del equipo de red donde los receptores observan la pérdida de paquetes u observan la recepción de paquetes con errores.
Estos criterios se pueden combinar, por ejemplo, para determinar la calidad de recepción, podría ser interesante conocer el número de receptores que han observado una pérdida de paquetes de más del 1 % de las transmisiones de vídeo recibidas.
Según una implementación variante de la invención, el método de transmisión comprende una etapa de transmisión de una solicitud de transmisión de información representativa de la calidad de recepción del flujo de datos. Esto también permite recibir solo información de ciertos receptores, por ejemplo en receptores particulares que están en una parte de la red donde la recepción debe probarse con mayor precisión.
Según una implementación variante de la invención ilustrada por las figuras 5 y 6 descritas anteriormente, el cambio en el estado de activación de una corrección de errores se lleva a cabo cuando el valor de al menos un criterio es mayor que un valor máximo de uno o más criterios, o menor que un valor mínimo de uno o más criterios determinados. Por ejemplo, si el valor máximo del número de congelaciones de vídeo es igual a cinco, cuando el número de congelaciones de vídeo supera cinco congelaciones de vídeo por hora, se realiza un cambio en el estado de activación de una corrección de error a un estado de "encendido". Si el valor mínimo del número de congelaciones de vídeo es igual a uno, cuando el número de congelaciones de vídeo pasa por debajo de un congelamiento de vídeo por hora, se realiza un cambio en el estado de activación de una corrección de error a un estado de "apagado".
Según una implementación variante de la invención ilustrada por las figuras 5 y 6, el cambio en el estado de activación de una corrección de errores se lleva a cabo cuando se supera un valor relativo a al menos un criterio. Por ejemplo, cuando el número de paquetes perdidos es mayor que el 2 % del número de paquetes del flujo de datos recibidos, se realiza el cambio en el estado de activación de una corrección de error a un estado de "encendido". Cuando el número de paquetes perdidos es inferior al 0,1 % del número de paquetes del flujo de datos recibidos, se realiza un cambio en el estado de activación de un "apagado" de corrección de errores.
Estas implementaciones variantes de la invención se pueden combinar juntas, para aumentar su eficacia.
Si se tienen en cuenta varios criterios, se pueden gestionar los posibles conflictos atribuyendo un nivel de prioridad relativo a cada criterio, o atribuyendo una operación lógica: por ejemplo, si el número de congelaciones supera un umbral máximo, pero el número de paquetes perdidos se encuentra por debajo del valor mínimo, se realiza un cambio en el estado de activación de corrección de errores "encendido", siendo el criterio del número de congelaciones de vídeo más importante en la determinación de la calidad de recepción (se da la máxima prioridad al criterio para el número de congelaciones de vídeo). Si el número de paquetes perdidos pasa por debajo de un umbral mínimo, sin embargo, el cambio en el estado de activación no se lleva a cabo si el número de congelaciones de vídeo no ha pasado por debajo de un umbral mínimo (operación lógica Y).
La medición de estos criterios se puede hacer de forma continua, periódica, aleatoria o durante un evento (por ejemplo, durante el zapping). Estas diferentes formas de medir la calidad de recepción se pueden combinar juntas.
Naturalmente, la invención no está limitada a las realizaciones descritas previamente.
En particular, varias etapas del método de recepción y del método de transmisión se pueden ejecutar en paralelo, como la recepción de tramas, la encapsulación y la transmisión, agregando medios de comunicación y zonas de memoria intermedia entre estas etapas. Esto tiene notablemente la ventaja de permitir una separación de tareas específicas.
Además, el método de recepción, así como el método de transmisión pueden implementarse no solo por un solo dispositivo, sino por un conjunto de dispositivos distintos.
La arquitectura de las infraestructuras 1 y 2 como se describe en las figuras 1 y 2 puede comprender otros dispositivos necesarios para un funcionamiento correcto. Por ejemplo, se pueden requerir varios transmisores para proporcionar una oferta de servicio enriquecida. Por ejemplo, un servidor de administración puede administrar el transmisor o los transmisores a través de una red interna lAn (Red de Acceso Local). Un servidor de administración de este tipo también puede administrar las suscripciones de usuarios de receptores a diferentes ofertas de servicios. Por ejemplo, elementos de equipos de red como enrutadores y conmutadores y específicos para el protocolo de transporte utilizado pueden ser necesarios para acceder a la red 12. Por ejemplo, la red 12 es una red comúnmente llamada "red troncal" de fibra óptica con protocolo ATM, que permite una tasa de bits muy alta y una tasa de bits garantizada. Por ejemplo, los receptores están conectados a esta red troncal por centros de distribución que comprenden DSLAM (Multiplexor de Acceso de Línea de Abonado Digital). Por ejemplo, un receptor accede a un DSLAM a través de una línea telefónica y un módem ADSL (Línea Asíncrona de Abonado Digital). Por ejemplo, el receptor accede a la red 12 a través de un dispositivo de acceso específico (puerta de enlace) que comprende un módem ADSL, un enrutador, un cortafuegos, un transmisor/receptor inalámbrico, etc., y puede conectar más de un receptor al mismo tiempo.
El tipo de red utilizada puede ser alámbrica, como se muestra aquí, pero también inalámbrica, utilizando técnicas como WiFi, DVB-H (norma DVB para dispositivos portátiles inalámbricos), DVB-T (norma DVB para la recepción de televisión y radio digital a través de señal terrestre), o DVB-S (norma DVB para la recepción de televisión digital y radio vía señal satelital) o de nuevo según el estándar ATSC (Comité de Sistemas de Televisión Avanzados).
Además, la arquitectura de los dispositivos que figuran en las infraestructuras 1 y 2 de las figuras 1 y 2 puede ser diferente. Por ejemplo, se pueden agregar varios generadores de flujos de corrección de errores para proporcionar flujo o flujos de corrección de errores particularmente adaptados a una sección del conjunto de receptores. Por ejemplo, el corrector 133 de errores de un receptor 13 o 22 según las figuras 1 o 2 respectivamente conecta la memoria 131 de recepción al decodificador 132.
El método de recepción, así como el método de transmisión se pueden implementar utilizando protocolos de configuración, administración, control y diagnóstico, según, por ejemplo, el protocolo SNMP o el protocolo CWMP y sus extensiones (Equipo de Instalaciones del Consumidor -Protocolo de Gestión de Red de Área Amplia). La invención puede implementarse utilizando el protocolo SNMP (Protocolo simple de administración de red) que coloca un "administrador" SNMP al nivel del transmisor y un "agente" SNMP en el receptor y agrega una MIB (Base de Información de Administración) con un atributo específico para la gestión del cambio en el estado de activación de una corrección de errores mediante el uso de uno o más flujos de corrección de errores. Para esta implementación, se puede agregar un "atributo MIB" a nivel de los receptores, conocido como "fecConfiguration" del tipo enumerado, admitiendo los valores descritos a continuación, accesibles en lectura y escritura:
- FEC_NONE (valor de enumeración 0),
- FEC_FORCED (valor de enumeración 1) y
- FEC_AUTO (valor de enumeración 2).
El valor FEC_NONE significa que el receptor no debe corregir el error mediante el uso de uno o más flujos de corrección de errores. El valor FEC_FORCED significa que el receptor necesariamente debe usar el flujo o flujos de corrección de errores. El valor FEC_AUTO significa que el receptor debe determinar por sí mismo si se va a realizar un cambio en el estado de activación de una corrección de errores mediante el uso de uno o más flujos de corrección de errores, según los criterios descritos anteriormente aquí. En los primeros dos casos (FEC_NONE y FEC_FORCED), es el transmisor el que determina si es necesario un cambio en el estado de activación de una corrección de errores mediante el uso de uno o más flujos de corrección de errores, según uno o más criterios como se ha descrito aquí previamente.
La invención también se puede implementar utilizando el protocolo CWMP y agregando un ACS (Servidor de Configuración Automática) a nivel del transmisor. En el receptor, se agrega un agente CWMP, así como un objeto en el receptor que comprende los atributos específicos para la gestión del cambio en el estado de activación de una corrección de errores mediante el uso de uno o más flujos de corrección de errores. En los términos de la norma CWMP, el receptor se denomina CPE, y para un CPE hay dos modos de activación de corrección de errores: un modo "forzado" y un modo "automático". En modo "forzado", el CPE cambia el estado de activación de una corrección de errores mediante el uso de una o más corrientes de corrección según una señal de cambio de estado, enviada por un transmisor; es el transmisor el que determina el cambio de estado según al menos un criterio de cambio. En el modo "automático", es el CPE mismo el que cambia el estado de activación según al menos un criterio de cambio, determinado por sí mismo. La función en el receptor que realiza una corrección de errores de uno o más flujos de corrección de errores se denomina "módulo FEC" o "decodificador FEC"
Para esta implementación, se agrega un objeto FEC en la estructura de datos como se define por la norma TR-135 (definida por el Foro de Banda Ancha). Este objeto FEC es parte del objeto .STBService.{i}.Components.FrontEnd. {i}.IP como se define en TR-135.
Este objeto FEC contiene los siguientes cuatro parámetros:
- Enable,
- ForceFECEnable,
- OperationMode,
- AutoModeFECDecoderStatus.
Los dos primeros (Enable, ForceFECEnable) son parámetros en acceso de solo escritura. Los dos siguientes (OperationMode, AutoModeFECDecoderStatus) están en acceso de solo lectura.
El parámetro Enable es de tipo booleano. Permite la activación o desactivación del módulo FEC. La escritura del valor 1 en el parámetro Enable provoca la activación del módulo FEC en modo de funcionamiento automático. Esto significa que el receptor debe determinar por sí mismo si se va a realizar un cambio en el estado de activación de una corrección de errores mediante el uso de uno o más flujos de corrección de errores, según los criterios descritos anteriormente aquí. Escribir el valor 0 en el parámetro Enable hace que el módulo FEC se desactive, lo que significa que el receptor no debe realizar ninguna corrección de errores mediante el uso de uno o más flujos de corrección de errores. La escritura 0 o 1 en el parámetro Enable se realiza utilizando el método SetParameterValue del protocolo CWMP de Tr-069. Implica el uso de una función remota que se encapsula en un marco según el protocolo http. Entre los parámetros de esta función remota, se encuentra el nombre del parámetro, en este caso, la siguiente secuencia de caracteres: STBService.{i}.Components.FrontEnd.{i}.IP.FEC.Enable, así como el valor a escribirse en booleano (0 o 1).
ForceFECEnable es un parámetro de tipo booleano. Escribir el valor 1 en el parámetro Habilitar provoca la activación del módulo FEC en modo de operación forzada. Esto significa que el receptor necesariamente debe usar el flujo o flujos de corrección de errores.
En el caso de que el FEC esté desactivado o cuando sea forzado, es el transmisor el que determina si es necesario un cambio en el estado de activación de una corrección de errores mediante el uso de uno o más flujos de corrección de errores, según uno o más criterios como los descritos aquí anteriormente.
En el caso automático, es el receptor el que decide sobre la activación o no de una corrección de errores mediante el uso de uno o más flujos de corrección de errores, según uno o más criterios como los descritos aquí anteriormente.
OperationMode es un parámetro de tipo enumerado y contiene una descripción en forma de cadena de caracteres del modo operativo del receptor. "Desactivado" indica que el FEC no está activado. "Auto" indica que el modo de funcionamiento del FEC es automático (como se describió anteriormente). El valor "Forzado" indica que la activación fue forzada.
AutoModeFECDecoderStatus indica, en el caso de que el modo operativo sea automático, si el decodificador FEC está funcionando o no. "FEC-ON" indica que el receptor utiliza los datos de FEC para realizar una corrección de errores. "FEC-OFF" indica que el receptor no utiliza los datos de FEC para realizar una corrección de errores.
En el apéndice se ilustra un ejemplo de definición de un objeto FEC con sus atributos, el valor de los atributos y su importancia.
El protocolo SNMP se define en una serie de documentos llamados RFC (Solicitud de Comentarios), como RFC 1157: "Un protocolo simple de administración de red". El protocolo CWMP está definido por el documento TR-069 y sus diversas modificaciones y extensiones (TR-098, TR-104, TR-106, TR-110, TR-111, TR-135, TR-140 y TR-142).
Las realizaciones descritas anteriormente son ejemplos de implementaciones, otras realizaciones son posibles y compatibles con la invención.
En particular, en lo que respecta a una implementación con el protocolo SNMP, se pueden establecer otros atributos MIB para gestionar la corrección de errores mediante el uso de uno o más flujos de corrección de errores. Por ejemplo, se puede definir un atributo "errorCorrection", que puede tomar los valores "on", "off', "auto", para "encender", "apagar", es decir, forzado por un transmisor, y para 'automático", es decir, determinado por el propio receptor. Por ejemplo, se pueden establecer varios atributos MlB para gestionar el cambio en la función de estado, por ejemplo, separando los parámetros que pueden escribirse de aquellos que pueden leerse por un transmisor
Además, en lo que respecta a la implementación con el protocolo CWMP, se pueden usar otros atributos que no sean un objeto FEC y otros parámetros distintos de los descritos para implementar la invención. Por ejemplo, una corrección de errores mediante el uso de uno o más flujos de corrección de errores no puede usar códigos FEC, sino, por ejemplo, Reed-Solomon. Por ejemplo, los parámetros se pueden combinar para simplificar su uso y limitar el número de mensajes necesarios entre un receptor y un transmisor.
Apéndice
Tabla resumen de una implementación de la invención con el protocolo CWMP: definición de objetos, atributos, valores y significado.
Figure imgf000011_0001
Figure imgf000012_0001

Claims (14)

REIVINDICACIONES
1. Método para la recepción de un flujo de datos, a través de una red de transporte de paquetes, que comprende: - recepción por un receptor de un flujo de datos;
- recepción por dicho receptor de al menos un flujo de corrección de errores asociado con dicho flujo de datos; - recepción por dicho receptor de una señal representativa de una selección de al menos uno de los siguientes modos: un modo de auto-determinación, o un modo forzado, o un modo de uso de corrección sin error;
- si dicho modo es dicho modo de auto-determinación, dicho receptor auto-determina usar dicho al menos un flujo de corrección de errores según al menos un criterio, o, si dicho modo es dicho modo forzado, dicho receptor usa por la fuerza dicho al menos un flujo de corrección de errores, o, si dicho modo es dicho modo de uso de corrección sin error, dicho receptor no usa dicho al menos un flujo de corrección de errores.
2. Método según la reivindicación 1, caracterizado por que el al menos un criterio comprende una calidad de recepción de dicho flujo de datos determinada por dicho receptor.
3. Método según la reivindicación 2, caracterizado por que la señal está comprendida en el flujo de datos recibido.
4. Método según la reivindicación 2 o 3, caracterizado por que la calidad de recepción de dicho flujo de datos comprende un número de congelaciones de vídeo observadas.
5. Método según cualquiera de las reivindicaciones 2 a 4, caracterizado por que la determinación de la calidad de recepción de dicho flujo de datos comprende un número de paquetes perdidos.
6. Método para la transmisión de flujo de datos, a través de una red de transporte de paquetes, que comprende las siguientes etapas:
- transmisión de un flujo de datos a al menos un receptor;
- transmisión de al menos un flujo de corrección de errores asociado con dicho flujo de datos a dicho al menos un receptor;
- recepción de información representativa de una calidad de recepción de dicho flujo de datos desde al menos uno de dicho al menos un receptor;
- transmisión de una señal destinada a dicho al menos un receptor, según una calidad de recepción determinada a partir de dicha información recibida de dicho al menos un receptor, siendo dicha señal representativa de una selección de al menos uno de los siguientes modos: un modo de auto-determinación en el que dicho al menos un receptor auto-determina usar dicho al menos un flujo de corrección de errores, o un modo forzado en el que dicho al menos un receptor usa por la fuerza dicho al menos un flujo de corrección de errores, o un modo de uso de corrección sin errores en el que dicho al menos un receptor no utiliza dicho al menos un flujo de corrección de errores.
7. Método según la reivindicación 6, caracterizado por que la determinación de dicha calidad de recepción de dicho flujo de datos comprende un número de congelaciones de vídeo observadas por dicho al menos un receptor.
8. Método según cualquiera de las reivindicaciones 6 a 7, caracterizado por que la determinación de la calidad de recepción de dicho flujo de datos comprende un número de paquetes perdidos.
9. Método según cualquiera de las reivindicaciones 6 a 8, caracterizado por que la señal de cambio de estado está comprendida en dicho flujo de datos.
10. Un dispositivo receptor para la recepción de un flujo de datos a través de una red de transporte de paquetes, que comprende un procesador (420), una memoria (410) y una interfaz (430) de red configurados para:
recibir un flujo de datos;
recibir al menos un flujo de corrección de errores asociado con dicho flujo de datos;
recibir una señal representativa de una selección de al menos uno de los siguientes modos: un modo de auto­ determinación, o un modo forzado, o un modo de uso de corrección sin error;
auto-determinar usar dicho al menos un flujo de corrección de errores según al menos un criterio si dicho modo es dicho modo de auto-determinación, o, usar por la fuerza dicho al menos un flujo de corrección de errores si dicho modo es dicho modo forzado, o no usar dicho al menos un flujo de corrección de errores si dicho modo es dicho modo de uso de corrección sin errores.
11. El dispositivo receptor según la reivindicación 10, en el que dicho procesador, dicha memoria y dicha interfaz de red están configurados además para determinar una calidad de recepción de dicho flujo de datos para obtener dicho al menos un criterio.
12. El dispositivo receptor según la reivindicación 11, en el que dicho procesador, dicha memoria y dicha interfaz de red están configurados además para determinar dicha calidad de recepción de dicho flujo de datos en función de un número de congelaciones de vídeo observadas.
13. El dispositivo receptor según la reivindicación 11 o 12, en el que dicho procesador, dicha memoria y dicha interfaz de red están configurados además para determinar dicha calidad de recepción de dicho flujo de datos como una función de un número de paquetes perdidos.
14. Un dispositivo transmisor para la transmisión de flujo de datos a través de una red de transporte de paquetes, que comprende un procesador (320), una memoria (310) y una interfaz (330) de red configurados para:
transmitir un flujo de datos a al menos un receptor;
transmitir al menos un flujo de corrección de errores asociado con dicho flujo de datos a dicho al menos un receptor; recibir información representativa de una calidad de recepción de dicho flujo de datos de al menos uno de dicho al menos un receptor;
transmitir una señal destinada a dicho al menos un receptor, según una calidad de recepción determinada a partir de dicha información recibida de dicho al menos un receptor, siendo dicha señal representativa de una selección de al menos uno de los siguientes modos: un modo de auto-determinación en el que dicho al menos un receptor auto-determina usar dicho al menos un flujo de corrección de errores, o un modo forzado en el que dicho al menos un receptor usa por la fuerza dicho al menos un flujo de corrección de errores, o un modo de uso de corrección sin errores en el que dicho al menos un receptor no utiliza dicho al menos un flujo de corrección de errores.
ES09772405T 2008-06-30 2009-06-29 Método para recibir flujos de datos y método correspondiente para la transmisión Active ES2754818T3 (es)

Applications Claiming Priority (2)

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
PCT/EP2009/058127 WO2010000705A1 (en) 2008-06-30 2009-06-29 Method for receiving data streams and corresponding method for transmission

Publications (1)

Publication Number Publication Date
ES2754818T3 true ES2754818T3 (es) 2020-04-20

Family

ID=40677513

Family Applications (1)

Application Number Title Priority Date Filing Date
ES09772405T Active ES2754818T3 (es) 2008-06-30 2009-06-29 Método para recibir flujos de datos y método correspondiente para la transmisión

Country Status (11)

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

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10097946B2 (en) * 2011-12-22 2018-10-09 Taiwan Semiconductor Manufacturing Co., Ltd. Systems and methods for cooperative applications in communication systems
US9668083B2 (en) 2011-12-22 2017-05-30 Taiwan Semiconductor Manufacturing Co., Ltd. Systems and methods for cooperative applications in communication systems
EP2449708A4 (en) * 2009-07-03 2014-08-27 Nokia Corp METHOD, DEVICE AND SERVICE FOR MEDIA TRANSMISSION
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
US9916835B2 (en) * 2015-01-22 2018-03-13 Sennheiser Electronic Gmbh & Co. Kg Digital wireless audio transmission system
KR101671018B1 (ko) 2015-04-22 2016-10-31 (주)이즈미디어 스큐 자동 보정 방법 및 장치
WO2017066737A1 (en) * 2015-10-16 2017-04-20 Tribune Broadcasting Company, Llc Video-production system with metadata-based dve feature
TWI622306B (zh) * 2016-06-08 2018-04-21 中華電信股份有限公司 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 (주)이씨스 프레임 제어 메시지 슬롯을 이용한 노변 기지국의 통신 영역에 대한 검증 장치 및 방법
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
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
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

Family Cites Families (13)

* 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
US6757860B2 (en) * 2000-08-25 2004-06-29 Agere Systems Inc. Channel error protection implementable across network layers in a communication system
US6909753B2 (en) * 2001-12-05 2005-06-21 Koninklijke Philips Electronics, N.V. Combined MPEG-4 FGS and modulation algorithm for wireless video transmission
JP2003234687A (ja) * 2002-02-06 2003-08-22 Nippon Telegr & Teleph Corp <Ntt> 無線通信システム
EP1588548B1 (en) * 2003-01-28 2010-10-13 Thomson Licensing Robust mode staggercasting
US20060072837A1 (en) * 2003-04-17 2006-04-06 Ralston John D Mobile imaging application, device architecture, and service platform architecture
ATE513417T1 (de) * 2003-10-06 2011-07-15 Ipg Electronics 503 Ltd Digitalfernsehübertragung mit fehlerkorrektur
JP4891779B2 (ja) * 2003-12-07 2012-03-07 アダプティブ スペクトラム アンド シグナル アラインメント インコーポレイテッド 適応マージン制御及び適応帯域制御
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

Also Published As

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

Similar Documents

Publication Publication Date Title
ES2754818T3 (es) Método para recibir flujos de datos y método correspondiente para la transmisión
US7865581B2 (en) Remote management method of a distant device, and corresponding video device
US8996946B2 (en) Application of fountain forward error correction codes in multi-link multi-path mobile networks
US11962816B2 (en) Method and device for live-streaming with opportunistic mobile edge cloud offloading
ES2810859T3 (es) Maximización de la calidad de servicio para la difusión en continuo de vídeos que se adaptan a la QOS a través de la configuración dinámica de la tasas de flujo en la capa de aplicaciones
EP2314005B1 (en) A method and system for adapting forward error correction in multicast over wireless networks
ES2621240T3 (es) Procesado de datos multimedia
WO2017215468A1 (zh) 确定视频质量的方法和装置、定位网络故障的方法和装置
Baccichet et al. Content-aware P2P video streaming with low latency
Ali et al. Bandwidth efficient adaptive forward error correction mechanism with feedback channel
EP2194667A1 (en) Error control on-demand
JP5423888B2 (ja) 伝送装置、帯域制御方法及びコンピュータプログラム
Karande et al. Analysis and modeling of errors at the 802.11 b link layer
ES2401964T3 (es) Método y dispositivo para suministrar datos a un descodificador
Singh et al. IPTV over wirelesslan: Promises and challenges
Permatasari et al. Real-time liquid wireless transport for video streaming in rural and agricultural applications
Markakis et al. Dynamic differentiated services provision in a Backhaul DVB/IP networking environment
Barsocchi et al. Quality of experience in multicast hybrid networks: avoiding bandwidth wasting with a double-stage FEC Scheme
Pisa Improving Service Support in Wireless Community Networks
Wang et al. FEC-based scalable multiple description coding for overlay network streaming
Chen et al. A cloud-assisted network coded packet retransmission approach for wireless multicasting
Mohammed et al. An inter-burst UEP-scheme for DVB-H using redundant transmission
Barsocchi et al. A novel approach for multicast video streaming in hybrid networks
Kwon et al. Reliable overlay multicast with loosely coupled TCP connections
Fracchia et al. P2ProxyLite: effective video streaming in wireless ad-hoc networks