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

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

Info

Publication number
EP2218256A1
EP2218256A1 EP08842934A EP08842934A EP2218256A1 EP 2218256 A1 EP2218256 A1 EP 2218256A1 EP 08842934 A EP08842934 A EP 08842934A EP 08842934 A EP08842934 A EP 08842934A EP 2218256 A1 EP2218256 A1 EP 2218256A1
Authority
EP
European Patent Office
Prior art keywords
time
packets
adapting
receiving device
indicator
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP08842934A
Other languages
German (de)
English (en)
Inventor
Jean-Noel Cuoq
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sagemcom Broadband SAS
Original Assignee
Sagem Communications SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sagem Communications SAS filed Critical Sagem Communications SAS
Publication of EP2218256A1 publication Critical patent/EP2218256A1/fr
Withdrawn 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4385—Multiplex stream processing, e.g. multiplex stream decrypting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44008—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics in the video stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1059—End-user terminal functionalities specially adapted for real-time communication

Definitions

  • the present invention relates to a device for continuously receiving audio and / or video data packets transmitted over a network from a source server.
  • the invention applies only to the field of data transmitted continuously ("streaming" in English) therefore data that must be played in real time: the invention does not relate to data that are downloaded and recorded in a first time on a receiving device then played next.
  • the invention applies more particularly to the field of devices connected to a data packet transmission network with an unsecured quality of services of the IP ("Internet Protocol") type, the existing IP network architecture, called “best effort" architecture, offering no guarantee of quality of service.
  • IP Internet Protocol
  • the QoS (quality of service) term refers to the ability to provide a service that meets specific requirements, such as response time, bandwidth or packet loss.
  • the invention does not apply to networks of the ATM (Asynchronous Transfer Mode) type offering a QoS adapted to different types of traffic.
  • streaming or streaming is a principle used for sending "live" content. It is widely used on the Internet and can be used to play an audio or video stream (in the case of Video On Demand (VoD) or Digital Television over the Internet) as it is broadcast. It is thus opposed to the broadcast by downloading which requires to recover all the data of a piece or a video extract before being able to listen to it or to look at it.
  • audio and / or video data packets are sent by a server on the Internet network and received by a device such as a digital television decoder or any other type of audio-video data retrieval device ("media player In English) connected to the network (a mobile terminal such as a telephone or a personal assistant for example).
  • a device such as a digital television decoder or any other type of audio-video data retrieval device ("media player In English) connected to the network (a mobile terminal such as a telephone or a personal assistant for example).
  • a device for continuously receiving audio and / or video data packets retrieves these data packets which it places in a buffer memory ("buffer” in English) which corresponds to a part of a RAM type memory (for "Random Access Memory” in English) or any type of fast access memory (hard disk, USB key for example).
  • buffer memory "buffer” in English) which corresponds to a part of a RAM type memory (for "Random Access Memory” in English) or any type of fast access memory (hard disk, USB key for example).
  • This memory will be referred to hereafter as “network buffer”.
  • the presence of a network buffer explains the delay between the moment when the user "calls" (by clicking on a hypertext link for example) the song or movie on the Internet and the beginning of the audio-video file playback . This buffering is required for different reasons:
  • the first hazard requiring this buffering is constituted by jitter ("jitter" in English) which is a phenomenon of fluctuation of the signal. This fluctuation can be a phase shift or a time dispersion.
  • jitter in English
  • the packet receiving device buffers the received data so as to smooth the transmission time and / or bit rate variations. It should be noted further that the data packets do not always arrive in the order and that they should therefore be grouped and arranged in the correct order in the network buffer.
  • FEC Forward Error Correction
  • the FEC consists in adding redundant elements of the digital message to the data transmitted before sending the audio / video signal, so that they can be checked on reception and thus reduce the risk of errors related to the broadcast and which would disturb the reception.
  • FEC C0P # 3 r2 standard of the "Pro MPEG Forum” describes an implementation of the FEC function.
  • FEC encoding typically, by overloading the initial packet amount by about 20%, the number of lost packets is greatly reduced.
  • the introduction of these correction codes entails an additional calculation time during which the data must be buffered (i.e. buffered).
  • RTP real-time transfer protocol
  • Real-time Transfer Protocol a data transmission protocol for the real-time transfer protocol type of real-time broadcast associated with a data flow control protocol of the RTCP type
  • RTP real-time transfer protocol
  • the device receives packets via the RTP protocol; when it detects a missing packet, it sends on a return channel a request compliant with the RTCP protocol to request the missing packet. It is therefore necessary to memorize the rest of the data the time (typically 300 ms) that the missing packet comes back from the server.
  • the RTP and RTCP protocols conform to the descriptions in RFC 3550, 4588 and 4585.
  • the absence of a network buffer for data packets would result in image degradation (screen disturbances such as jittery video or a frozen image) and / or sound (choppy or metallic for example).
  • this network buffer in which the packets are temporarily recorded as they are received by the device implies that a good compromise is found between the buffering time and the quality of the buffer. image and / or sound desired. If we want a very good quality, it takes a long storage time (up to 1s to 3s for a digital television decoder) resulting in a significant occupation of the RAM and an extended connection time for the user.
  • the program change "zapping" or "TV surfing” in English) is also lengthened.
  • the modes of operation advance or fast return (“trick mode” in English), the launch of a video or the launch of a sequence in a list of files (“playlist” in English) are also impacted. These modes are not implemented locally; using the server, they result in longer buffering.
  • a known solution to meet this need for compromise is to adapt the buffering time through exchanges between the server and the receiving device.
  • the receiving device therefore has a variable buffering time. The receiving device sends a request for setting the buffering duration and receives signals from the source server which controls the adaptation of the storage time.
  • the present invention aims at providing a device for continuously receiving audio and / or video data packets transmitted from a source server via a network allowing an efficient adjustment of the network buffering time to compensate for the inherent disturbances. to the network while avoiding the aforementioned problems.
  • the invention proposes a device for continuously receiving audio and / or video data packets transmitted from a source server via a network, the reception device comprising:
  • the network buffer having a variable buffering time
  • the device being characterized in that it comprises means for locally determining the value of at least one quality indicator of service, the means for adapting the buffering time adapting the storage time according to the value of the QoS indicator.
  • the determination of the buffering time is carried out locally by determining at least one QoS indicator without a server control signal: this local processing to the reception device involves the following advantages:
  • the invention is applicable to "multicast” and "unicast” transmission, the user does not have to intervene on the device via configuration menus that can be perceived as complex. It is the device according to the invention which is in charge of determining the best possible compromise between the buffering time, the image quality and / or the desired sound and the connection and navigation time in VoD. Thus, with a very low bufferization time, we will have:
  • the advantage of the device according to the invention is that the adaptation is done dynamically without the subscriber needing to ask the operator to configure the device or to configure itself. even the size of the buffer.
  • the device according to the invention may also have one or more of the features below, considered individually or in any technically possible combination.
  • the buffering time is less than 3 s (preferably less than 2 s) and greater than 100 ms.
  • the quality of service indicator is chosen from the following indicators: the number of missing packets, the latency during the missing packet request (for example in the case of a unicast broadcast with detection of missing packets of the type RTP / RTCP), - audiovisual rendering.
  • the means for adapting the buffering time adapt the buffering time as a function of the ratio between the value of the quality of service indicator and the duration of use of the reception device.
  • the means for adapting the buffering time adapt the time when the value of the quality of service indicator exceeds a critical threshold. This adaptation can be done when the value of the quality of service indicator exceeds the critical threshold for at least a given time.
  • the means for adapting the buffering time are adapted according to the type of data packets, these means being able to react differently depending on whether the data packets are of the video on demand or television type.
  • the data packets are packets corresponding to a television signal
  • the device according to the invention comprising means for detecting a channel more particularly watched by the user and means for adapting the memory storage time. - pon specifically adapting the storage time of the packets corresponding to the detected string.
  • said means for locally determining the value of at least one quality of service indicator comprise means for resetting said value.
  • said means for adapting the buffering time of the packets with a view to improved rendering performance evolve over time by learning.
  • the device according to the invention is particularly suitable for the field of television decoders. Brief description of the figures
  • FIG. 1 is a simplified schematic representation of an architecture using a device according to the invention.
  • FIG. 1 represents an architecture 100 using a device 108 according to the invention.
  • the device 108 is a digital television decoder.
  • the architecture 100 further comprises:
  • a remote source 101 of audio video data such as a remote server.
  • the modem 105 is a modem of the ADSL type ("Asymmetric Digital Subscriber Line") "triple play” offering the user access to the three services that are television or video on demand VoD via the television 119, telephony via the telephone 106 and Internet via the computer 107.
  • ADSL Asymmetric Digital Subscriber Line
  • the server 101 includes an encoder 102 and an encapsulation device 103. Whether it is a VoD or a television signal, it starts from a native audio video signal Si which undergoes compression and encoding. of the MPEG-2 type in the encoder 102 to result in an MPEG-2 signal S2. Although the description is based on the MPEG-2 video coding standard, other similar standards can be used such as MPEG-4 or H263.
  • the signal S2 audio video is not transmitted on the distribution network 104 in its raw format as it appears after the compression and encoding phase in MPEG-2. It is cut into audio video packets, multiplexed between them and encapsulated in a specific stream for transport called MPEG-2 TS ("Transport Stream" in English).
  • This single stream is cut and inserted into Real Time Transport Protocol (RTP) packets, possibly with FEC type error correction systems.
  • RTP Real Time Transport Protocol
  • the packets are then encapsulated in User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) packets integrating all the constituent elements necessary for reconstructing the program themselves transmitted in IP datagrams.
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • the invention applies only to the case of audio video packets transmitted in "streaming" (thus data that must be played in real time on the television 119).
  • the data packets are received by the modem 105 via a not shown DSLAM multiplexer ("Digital Subscriber Line Access Multiplexer") which transmits these packets to a packet receiver 109 of the decoder 108.
  • DSLAM multiplexer Digital Subscriber Line Access Multiplexer
  • the access to the television channels or the VoD requires the use of the decoder 108 whose primary function is to decode the stream of compressed video data in the MPEG 2 format.
  • the digital data receiver 109 and the modem 105 are connected by a Ethernet cable 123. It should be noted that this connection could also be a WiFi or WiMAX connection.
  • the decoder 108 comprises: a network buffer 110
  • microprocessor 116 controlled by programs located in a program memory 117,
  • the decoder 108 receives via the receiver 109 compressed data packets which are transmitted to the network buffer memory 110 and then to the MPEG-2 decoder 111 to be restored to the television 119. via a scart socket 124.
  • the MPEG-2 decoder 111 uses an audio-video buffer (AV) 113.
  • AV audio-video buffer
  • the images P are predicted from the previous I or P images.
  • the images B are also predicted images but they have the particularity of being able to be interpolated from past and / or future I or P images.
  • the decoding of an image B is only possible if the images I or P which serve as its reference (notably the future images) are available.
  • This explains the presence of the AV buffer 113 which temporarily stores the I and P images already decoded by the MPEG-2 decoder 111 for the time that the MPEG-2 decoder 111 decodes the following P and B images.
  • the images are then repositioned in their normal order. It can be seen here that the buffer memory 113 depends on the type of compression algorithm used and that its function is completely different from that of the network buffer 110.
  • the data rate transmitted to the decoder 108 may vary typically between 1.5 Mbit / s and 12 Mbit / s.
  • the packets are temporarily recorded as and when they are received by the network buffer 110 to compensate for various hazards such as: - problems related to jitter,
  • the network buffer memory 110 may be part of a RAM type memory whose overall size is for example 128 or 256 MB for a digital television decoder with typically a size of the order of 512 KB to 5 MB dedicated to the network buffer 110.
  • the buffering time is variable: this time can typically vary between 100 ms and 3 s (preferably less than 2 s or even 1 s) for a digital television decoder with a default value of the order of 300 ms. Incidentally, it may be noted that this default value may vary depending on the destination of the decoders if the operator knows to which countries the decoders are intended.
  • the data memory 118 is particularly intended to store various information, values or parameters necessary for the operation of the decoder.
  • the data memory thus includes variable-value QoS indicators which can be for example: the number of missing packets 135,
  • the number of missing packets is the number of undelivered data packets, mostly due to network congestion. This number of missing packets is provided by a 4-bit "continuity counter" for TP ("Transport Packet") packets defined by the MPEG-2 Systems ISO standard. IEC 13818-1. If the RTP protocol (RFC 3550) is used, the "sequence_number" field (16-bit coded) of the header can also be used.
  • the latency during a missing packet request is determined via the RTP / RTCP protocols: when a missing packet request is issued according to RTP (RFC 3550), the latency corresponds to the time elapsed between the transmission of the request and the return of the missing package via RTCP.
  • the MPEG-2 111 decoder consumes the data more quickly than the latter arrive. If the MPEG-2 111 decoder has no more data, it can no longer decompress the following images and in this case the last image that could be decompressed remains frozen on the TV screen 119.
  • the MPEG-2 decoder 111 raises alarms (interrupts for example) each time it encounters these cases of errors and it is therefore possible to track these errors (and therefore audiovisual rendering) via an indicator.
  • the decoder 108 can indifferently use several indicators or only one.
  • the data memory 118 also includes an indicator 138 providing the duration of use of the decoder 108 by the user (i.e., number of hours of viewing on the television 119).
  • the program memory 117 is particularly intended for managing the various operations to be performed in order to implement various functions of the decoder 108. It comprises several software means (ie applications) some of which are dedicated to the implementation of the invention. . In other exemplary embodiments of the decoder 108, these software means could be replaced by specific electronic circuits.
  • the program memory 117 comprises: means 120 for adapting the buffering time of the packets in view of improved rendering performance,
  • means 122 for calculating the ratio of the average value of the QoS indicator over the display duration.
  • the decoder 108 permanently stores tracking data of at least one QoS indicator 135, 136 and / or 137 continuously via the means 121. After a predetermined period (which may be for example a day, a week or a month), the decoder 108 calculates the ratio of the average value of one of the QoS indicator (for example the number of missing packets 135 138. If this ratio exceeds a certain threshold, the decoder 108 will activate its means 120 in order to increase the storage time in the network buffer 110 of the packets in order to improve the performance of the reproduction of the device. 'picture.
  • the decoder 108 may decide to reduce the storage time in the network buffer 110 in order to improve the "trick mode" delay in the case of the VoD or the connection time (zapping) in the case of a TV stream without a return path.
  • the means 121 for locally determining the value of at least one QoS indicator also comprises means for resetting the QoS value to zero after each adjustment of the bufferization time.
  • Each decoder 108 adapts to the quality of the transmission line according to one or more locally calculated QoS indicators (thus without control of a signal coming from the network); a decoder that has a very good quality of reception (for example because the transmission is done by optical fiber or because the subscriber is located near the DSLAM) will have a "trick mode" almost instantaneous in the case of the VoD, a almost instantaneous connection time in the case of a non-return TV stream and a reduced bufferization time because the QoS indicator will indicate a good quality.
  • the decoder 108 is therefore an "intelligent" system with dynamic and local self-adaptation as a function of the quality of service without any modification of the buffer time which would be controlled by the network.
  • the decoder according to the invention operates by learning.
  • the setting of the bufferization time will be as much finer as the decoder will have a greater history of QoS values (ie the means 120 for adapting the buffering time of the packets for improved rendering performance evolve over time by learning).
  • implementation of the bufferisation time by type of data packets and thus of services provided to the user: thus, depending on whether the service is television (known as "live” in English) or the VoD, the bufferization time can be adjusted differently by means 120.
  • Step 1 - Day J - installation of the device according to the invention by the subscriber
  • Step 4 - Day D + 2
  • bufferization time 1, 2 s.
  • the indicators are as follows: o MPEG-2 group: good QoS indicator and viewing time
  • Step 12 - Day D + 8 the device decides not to modify the parameters because: o MPEG-2 group has a QoS indicator report with significant display duration which is satisfactory o group H264: indicator "too" good (zapping time unnecessarily impacted) but with a non-significant duration of visualization Step 13 - Day D + 20:
  • the device decides a differentiated treatment according to the type of service: o MPEG-2 group: Buffering time slightly increased to 1, 3 s. o group H264: bufferization time decreased to 0.8 s. Step 15 - Day D + 20: - the indicators are reset to 0
  • the indicators are as follows: o MPEG-2 group: good QoS indicator and display duration
  • the adaptation of the network buffering time can be performed at each passing by one of the QoS indicators of a critical threshold; for example, if the audiovisual rendering indicator indicates an image frozen every 5 sec, the means 120 will immediately increase the buffering time and this new buffering time will produce its effects at the next connection of the decoder 108.
  • An even more refined adaptation can be made per television channel, each channel not having the same bit rate and the same level of coding (channels can use more or less Intra images for example which influence the risk of disturbance).
  • the setting of the buffering time may therefore be different depending on the television channel.
  • a specific adaptation of the buffering time for a television channel particularly watched by the user can also be Implementation.
  • the device 108 then comprises means 125 for detecting a chain more particularly watched by the user and the means 120 for adapting the buffering time specifically adapt the storage time of the packets corresponding to the detected string.
  • the invention is not limited to the embodiment just described.
  • the embodiment refers to a continuous packet receiving device which is a digital television decoder.
  • the invention applies equally well to a reception device incorporated in the ADSL modem, or even to an independent packet reception device located between the ADSL modem and the decoder.
  • the invention applies to other types of terminals for receiving streaming data packets such as mobile terminals (telephone or personal assistant).
  • the invention does not concern reception devices having bufferization times greater than 3 s such as microcomputers.

Landscapes

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

Abstract

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

Description

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

Claims

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

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP2218256A1 true EP2218256A1 (fr) 2010-08-18

Family

ID=39367002

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08842934A Withdrawn EP2218256A1 (fr) 2007-10-10 2008-10-06 Dispositif de reception en continu de paquets de donnees audio et/ou video

Country Status (7)

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

Families Citing this family (7)

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

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6377972B1 (en) * 1999-01-19 2002-04-23 Lucent Technologies Inc. High quality streaming multimedia
US6747999B1 (en) * 1999-11-15 2004-06-08 Siemens Information And Communication Networks, Inc. Jitter buffer adjustment algorithm
ES2275481T3 (es) * 2000-04-14 2007-06-16 Alcatel Lucent Una memoria tampon autoadaptiva de fluctuacion.
US20020067730A1 (en) * 2000-12-05 2002-06-06 Starguide Digital Networks, Inc. Method and apparatus for IP multicast content distribution system having national and regional demographically targeted advertisement insertion
US7095729B2 (en) * 2000-12-22 2006-08-22 Intel Corporation Method for multimedia communication over packet channels
US20020085536A1 (en) * 2000-12-29 2002-07-04 Rudrapatna Ashok N. System and method for implementing a wireless isochronous data service
US7130316B2 (en) * 2001-04-11 2006-10-31 Ati Technologies, Inc. System for frame based audio synchronization and method thereof
US20020194609A1 (en) * 2001-06-18 2002-12-19 Tran Thanh T. Video client with dynamically allocable video buffer for efficiently streaming video
EP1349334B1 (fr) * 2002-03-28 2004-09-22 Siemens Schweiz AG Methode pour ajuster la mémoire-gigue dans une passerelle de media
US7810126B2 (en) * 2003-01-31 2010-10-05 Koninklijke Philips Electronics N.V. Inter-application control to improve the performance of playback of stored interactive-TV applications
KR100759954B1 (ko) * 2003-02-13 2007-09-19 노키아 코포레이션 멀티미디어 스트리밍에서 클라이언트 레이트 능력을시그널링하는 방법
US7088741B2 (en) * 2003-05-01 2006-08-08 Genesis Microchip Inc. Using an auxilary channel for video monitor training
KR100782835B1 (ko) * 2005-01-29 2007-12-06 삼성전자주식회사 캡션 정보의 출력시점 및 출력 우선순위를 조절하는 방법및 그 장치
US7616664B2 (en) * 2005-02-18 2009-11-10 Hewlett-Packard Development Company, L.P. System and method of sending video and audio data over a network
FR2888441A1 (fr) * 2005-07-11 2007-01-12 Thomson Licensing Sas Soc Par Appareil et procede d'estimation du taux de remplissage des tampons d'entree de clients d'une distribution de contenu temps reel.
CN100442858C (zh) * 2005-10-11 2008-12-10 华为技术有限公司 分组网络中多媒体实时传输的唇同步方法及其装置
EP1879347B1 (fr) * 2006-07-14 2012-05-30 Sony Europe Limited Système et procédé de transmission audio-vidéo en continu

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2009053595A1 *

Also Published As

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

Similar Documents

Publication Publication Date Title
US10623785B2 (en) Streaming manifest quality control
US9641578B2 (en) Minimizing unicast bandwidth in an adaptive bit rate system
US8135040B2 (en) Accelerated channel change
US9100461B2 (en) Automatically publishing streams to multiple destinations
CA2618328C (fr) Systeme de transmission en continu de video a la demande flexible et multisource pour une communaute d'abonnes entre homologues
EP3348067B1 (fr) Changement de canal rapide dans un réseau de diffusion en continu à débit binaire adaptatif de multidiffusion (mabr) en utilisant des rafales de segment de répétition de multidiffusion dans un tuyau de téléchargement abr progressif partagé
US10812559B2 (en) Just-in-time variable adaptive encoding and delivery of media content
US9113182B2 (en) Selecting a media content source based on monetary cost
US8275233B2 (en) System and method for an early start of audio-video rendering
EP3090523A1 (fr) Acheminement de contenu
US9253545B2 (en) Routing media content based on monetary cost
EP2218256A1 (fr) Dispositif de reception en continu de paquets de donnees audio et/ou video
US10298965B2 (en) Selection of a content source based on performance data
CN117014608A (zh) 视频流码率调整方法、装置、计算机设备和存储介质
US20140267899A1 (en) Methods And Systems For Intelligent Playback
KR101702426B1 (ko) 다시점 비디오 서비스의 시점변경 지연을 줄이기 위한 다중 http 스레드 기반의 비디오 전송 시스템 및 방법
EP1908259B1 (fr) Appareil et procede d'estimation du taux de remplissage des tampons d'entree de clients d'une distribution de contenu temps reel
Okerman et al. Fast startup multicast streaming on operator iptv networks using hesp
EP2129130A1 (fr) Procédé de transmission simplifié d'un flux de signaux entre un émetteur et un appareil électronique
EP2075960B1 (fr) Système et procédé d'adaptation des flux de contenu vidéo à la variabilité des conditions de transmission d'un réseau radiotéléphonique et à la dynamique du contenu de la source vidéo
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
FR2905221A1 (fr) Procede et systemes pour optimiser la transmission d'un flux de donnees.
EP2087733A1 (fr) Procédé de retardement temporel de flux de contenus numériques, dispositif, et produit programme d'ordinateur correspondants
FR2907299A1 (fr) Procede de notification de changement de parametre d'emission et emetteur selon le procede

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100401

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20110517

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20111129