WO2013098810A1 - Système et procédé de correction d'erreur sans voie de retour (fec) adaptatif - Google Patents

Système et procédé de correction d'erreur sans voie de retour (fec) adaptatif Download PDF

Info

Publication number
WO2013098810A1
WO2013098810A1 PCT/IL2012/000402 IL2012000402W WO2013098810A1 WO 2013098810 A1 WO2013098810 A1 WO 2013098810A1 IL 2012000402 W IL2012000402 W IL 2012000402W WO 2013098810 A1 WO2013098810 A1 WO 2013098810A1
Authority
WO
WIPO (PCT)
Prior art keywords
packets
packet
probe
fec
detector
Prior art date
Application number
PCT/IL2012/000402
Other languages
English (en)
Inventor
Adi ROZENBERG
Original Assignee
Video Flow Ltd.
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 Video Flow Ltd. filed Critical Video Flow Ltd.
Priority to US14/370,030 priority Critical patent/US9577682B2/en
Publication of WO2013098810A1 publication Critical patent/WO2013098810A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/35—Unequal or adaptive error protection, e.g. by providing a different level of protection according to significance of source information or by adapting the coding according to the change of transmission channel characteristics
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/29—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes
    • H03M13/2906—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes using block codes
    • H03M13/2909—Product codes
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/35—Unequal or adaptive error protection, e.g. by providing a different level of protection according to significance of source information or by adapting the coding according to the change of transmission channel characteristics
    • H03M13/353—Adaptation to the channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H04L1/1819—Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of additional or different redundancy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1874—Buffer management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1874—Buffer management
    • H04L1/1877—Buffer management for semi-reliable protocols, e.g. for less sensitive applications like streaming video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1896—ARQ related signaling

Definitions

  • Embodiments of the present invention relate to systems for media stream transmission using an adaptive size FEC matrix and adaptive on demand media packet loss recovery.
  • Standard ProMpeg or SMPTE2022-1 forward error correction (FEC) calls for the use of a constant predefined dimension matrix to be sent between a sender and recipients (see Figure 1).
  • a predefined matrix cannot respond to changes in the network.
  • An adaptive approach where the recipients signals to the sender on errors, can give the sender an option to modify matrix dimension to better handle the current and the next failures.
  • Figure 1 shows a transmitter which sends an original media stream and calculates the Row/Column FEC packets (in accordance with ProMpeg
  • a Receiver attempts to recover any missing packet by using the Row, Column FEC packets.
  • the Row and column FEC packets are sent all the time using special, dedicated UDP ports.
  • the Row and column length is static (e.g. its dimensions are set once and remain the same length for a long duration).
  • transmitter 11 sends serially transmitted packets 123, including data (Dl, D2, D3...) and FEC (Rl. complicat) packets, over a network 12 to a receiver 13.
  • Data in 111 stream is formed into data to be transmitted 112, in matrix form.
  • a FEC encoder 113 processes the data to generate, for example, a FEC packet Rl 114.
  • the data and FEC packets are transmitted through a stack 115.
  • serially received packets 124 arrive at receiver 13, with an exemplary lost data packet (D2).
  • D2 exemplary lost data packet
  • a received FEC packet Rl 134 is transferred to a FEC decoder 133, wherein a recovered D2 packet 137 is generated.
  • the data out, received packets 138 include the lost packet D2, along with the rest of the packets.
  • a standard media delivery system comprises transmitter 11 and receiver 13 devices; and the media stream is transmitted using a Real Time
  • RTP Transmission Control Protocol
  • Embodiments of the present invention improve the efficiency of FEC processing using an adaptive system and method.
  • a system uses an adaptive matrix, wherein resolution changes in response to network errors in media over IP networks.
  • Embodiments of the present invention include means for implementing an adaptive FEC matrix, which can scale up or down, responsive to the error rate in real time.
  • the use of an adaptive size matrix improves the error resilience and the usage of network bandwidth.
  • a corresponding means for using and adapting to variable matrix sizes is required in the transmitters and receivers.
  • the recipient should include means for handling matrix changes between groups of packets.
  • the system uses an adaptive on demand media packet loss recovery to reduce bandwidth.
  • the proposed solution consists of a system made of two blocks, a probe device and a detection block, see Figures 2 and 3.
  • the probe device probes the media/transport stream and uses its transport stream packet information to calculate FEC reference packets.
  • the detection block accepts the transport stream packets and inspects for any lost packets. Upon detection of a lost/missing packet, the detection block will signal the probing block about the missing packet, by using a RTCP message.
  • the Probing device will use the RTCP information to calculate an optimal FEC solution for the next packet transmissions; these FEC packets will assist the Detection block to reconstruct the lost packets based on the FEC information.
  • the present patent application is the first of four applications presently filed by the present applicant and inventor. Embodiments of the inventions disclosed in these applications can be used together in various combinations: 1. Adaptive FEC System and Method
  • Figure 1 illustrates a Prior Art System for transmitting media packets
  • Figure 2 illustrates a new system to protect media streaming in an intrusive implementation.
  • Figure 3 illustrates a new system to protect media streaming in a non-intrusive implementation.
  • Figure 4 illustrates an Adaptive FEC System, high level blocks.
  • Figure 5 illustrates a Probe data flow
  • Figure 6 illustrates a Detection data flow.
  • Figure 7 illustrates a Detection device internal building blocks and data flow.
  • Figure 8 illustrates a Probe device internal building blocks and data flow.
  • Figure 10 illustrates a Flat representation of the stream in Figure 9.
  • Figure 11 illustrates a possible packet recovery method for missing packets with various lengths.
  • Figure 13 illustrates a possible packet recovery method for missing packets with various lengths.
  • Figure 14 illustrates FEC packet calculation and various lengths that the system may call or use to recover lost packets.
  • Figure 15 illustrates a system architecture including both intrusive and non-intrusive deployment topology.
  • Figure 16 illustrates a system architecture using both a public and a private network.
  • Figure 17 illustrates a system architecture wherein a probe and detection means communicate through the network and apply an adaptive FEC Matrix.
  • Figure 18 illustrates an optional improvement of the IP video delivery network using a probe and a detection device.
  • MPEG Moving Picture Experts Group
  • TS MPEG transport stream
  • PSIP Program and System Information Protocol
  • Transport Stream is specified in MPEG-2 Part 1, Systems (formally known as ISO/IEC standard 13818-1 or ITU-T Rec. H.222.0).
  • TS Packet is the basic unit of data in a transport stream. It consists of a sync byte, whose value is 0x47, followed by three one-bit flags and a 13-bit Packet Identifier (PID) . This is followed by a -bit continuity counter. Additional optional transport fields, as signaled in the optional adaptation field, may follow. The rest of the packet consists of payload. Packets are 188 bytes in length. Program Identifier (PID) Each table or elementary stream in a transport stream is identified by a 13-bit packet ID (PID) . A demultiplexer extracts elementary streams from the transport stream in part by looking for packets identified by the same PID.
  • Program Clock Reference is transmitted in the adaptation field of an MPEG-2 transport stream packet.
  • the value of the PCR when properly used, is employed to generate a system_timing_clock in the decoder.
  • the PCR is used by the decoder to present synchronized content, such as audio tracks matching the
  • RTP Real-time Transport Protocol
  • RTP defines a standardized packet format for delivering audio and video over IP networks.
  • RTP is used extensively in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web-based push-to-talk features.
  • RTP is used in conjunction with the RTP Control
  • RTCP RTCP
  • media streams e.g., audio and video
  • RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams.
  • QoS quality of service
  • RTP is originated and received on even port numbers and the associated RTCP communication uses the next higher odd port number.
  • RTP was developed by the Audio-Video Transport Working Group of the Internet Engineering Task Force (IETF) and first published in 1996 as RFC 1889, superseded by RFC 3550 in 2003.
  • IETF Audio-Video Transport Working Group of the Internet Engineering Task Force
  • UDP User Datagram Protocol
  • IP Internet Protocol
  • UDP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the
  • Set-top box is an information appliance device that generally contains an interface to a network and connects to a television set and an external source of signal, turning the signal into content which is then displayed on the television screen or other display device.
  • the set-top box is a small computer providing two-way communications on an IP network and decoding the video streaming media.
  • IP set-top boxes have a built in home network interface which can be Ethernet or one of the existing wire home networking technologies.
  • FEC Forward Error Correction
  • Pro-MPEG - the Professional-MPEG Forum - is an association of broadcasters, program makers, equipment manufacturers, and component suppliers with interests in realizing the
  • SMP E 2022 The Pro-MPEG Forum began initial work on a FEC scheme for video transport. That work, added to by the Video Services Forum, was introduced to SMPTE. This proposed standard is known as SMPTE 2022, and it describes both a FEC scheme and a way to transport constant bit rate video over IP networks.
  • FIGS 2 and 3 illustrate a system for protecting media streaming in an intrusive implementation.
  • a media stream encapsulated in MPEG transport may be packetized in 188 byte packets, each packet with a 8 byte header. Every 1 to 7 transport packets are encapsulated into one UDP packet.
  • the UDP packet may be prefixed with an RTP header that includes information about its position in the stream (Sequence number ) + (coding
  • a RTCP control protocol is running in parallel to the data stream and provides control/status information about the health of the stream, clients and source devices.
  • the invention consists of a probe device and a detection device. Two embodiments are presented: an intrusive system in Figure 2; and a non-intrusive system in Figure 3. There are intrusive and non-intrusive connection options.
  • the RTCP messaging solution applied in an embodiment of the current invention allows the detection device to send one or more packet loss event messages to the Probe device, to alert of lost packet detection.
  • the proposed system may use this, a multi-layered solution, to send one or more requests of missing events, to provide a higher protection assurance (in case the Probe did not receive the original request or the recovery packet did not reach the detection device). Reception of more than one request for the same loss event may result in one or more protective packets to be sent by the Probe device and the receiving device ignores the duplicate packets and treats the event as packet duplication.
  • Fig. 2 depicts an intrusive implementation, in which detection device 15 is responsible of handling the packet recovery process.
  • Fig. 3 detailing the non-intrusive mode, wherein the stream receiver 13 is responsible for recovering packets. The detection device assists by reporting lost packet events to probe device 14.
  • Probe 14 device includes an IP interface, memory buffer, transport processing block and a processor. Any packet received by the IP interface is forwarded to the memory buffer in a sequential order.
  • the processor device calculates a row and or Column FEC reference packet based on a ProMpeg or SMPTE2022-1 standard.
  • the FEC packets are sent through different UDP ports (row and column FEC are sent using different, separate UDP ports).
  • the detection device 15 follows the same probing as the probe device 14.
  • the detection device probes the incoming stream for missing packets and reports by means of an RTCP message.
  • the RTP sequence number is used to generate a list to verify the order of the packets.
  • the processor can change the position of the internal packet back to its original state.
  • the detection device can issue a request for Packet loss intervention to occur.
  • a FEC decoder block 153 receives the sent FEC packets to reconstruct any lost packet.
  • the FEC decoder may inspect each FEC packet, its Row and Column information, to construct the desired row or column packets as needed to reconstruct missing packets, such as D2 158 for example. Any reconstructed packet is return back to the buffered stream.
  • the RTCP missing packet information is gathered by the probe processor to create a map of events (occasional packet loss, burst lost etc.).
  • the processor modifies the row/column dimension to handle the map of events e.g.; on a burst loss the Processor with increase the Row dimension to allow the column FEC to overcome the burst events.
  • the system in Figure 2 comprises a transmitter 11 sending packets through a network 12 to a receiver 13; a probe 14 and a detection device 15.
  • Data in 111 passing through stack 115 is sent as serially transmitted data packets 125, including data (Dl, D2, D3...) serially received packets 126, with an exemplary lost data packet (D2).
  • D2 data
  • the receiver 13 there is a stack 135 and a data buffer 136.
  • Probe 14 includes a FEC encoder 143, FEC packet Fl 144 and buffer 146.
  • Detection device 15 includes a FEC decoder 153 and buffer 156. Also shown are a recovered D2 packet 158, a report packet D2 missing 159 and data out channel with received packets 138.
  • Figure 3 illustrates a new system to protect media streaming in a non-intrusive implementation, comprising a transmitter 11, network 12, receiver 13, probe 14 and detection device 15. In this embodiment of the invention, packets do not pass serially from network 12 to detection device 15 and therefrom to receiver 13, as shown in Figure 2; rather, packets from network 12 are transferred directly to receiver 13, with the detection device also receiving the packets.
  • FIG. 4 illustrates an Adaptive FEC System, with its high level blocks the Probe 14 and its high level component parts, and the Detection device 15 and its high level component parts.
  • An FEC decoder block 232 receives the sent FEC packets to reconstruct any lost packet.
  • the FEC decoder preferably inspects each FEC packet row and column information to construct the desired row or column packets needed to reconstruct missing packets. Any reconstructed packet is return back to the buffered stream.
  • the RTCP missing packet information is gathered by the Probe Processor 213 to create a map of events ( occasional packet loss, burst lost etc. ).
  • Processor 213 modifies the row/column dimension to handle the map of events e.g.; on a burst loss the processor with increase the row dimension to allow the column FEC to overcome the burst events.
  • FIG. 5 illustrates a Probe data flow.
  • RTP packets are stored in a dedicated stream buffer/storage, step 32
  • Figure 6 illustrates a Detection data flow
  • RTP packets are stored in a dedicated stream buffer/storage, step 42
  • a RTCP is sent to a Probe device 4D 4. Packets are read out according to their rate out, step 4B
  • Packets are analyzed to extract their stream, video information and
  • step 4C Calculate any missing packet (if applicable), step 4C
  • Figure 7 illustrates the structure of a Detection device, detailing its internal building blocks and the data flow.
  • Media packets ( Video/media or FEC ) arrive at the Ethernet MAC port 51. Each packet is stored in a memory buffer, step 52.
  • the software assigns a pointer 52E that points to the memory buffer 52B in packet memory management block, step 52.
  • the Software extracts the Sequence number from each Video/media packet header and sends it with the memory pointer 59, 52D to the INPUT processing 58 block.
  • the TS INPUT block 58 copies the packet pointer and Sequence number to the Stream pointer FIFO Pool 54; each entry is indexed according to the Sequence number.
  • the TS INPUT block 58 compares the accepted Packet Sequence number 59 to a previously stored one, to detect an option for missing packets.
  • a Loss Packet detector 57 scans 57A the Stream pointer FIFO pool 54 in the area of the suspected missing packet, to look for additional missing packets. Upon detection of such a packet, the software will issue a RTCP message having the information of one or more missing packets. 7. Packets stored in the Stream pointer FIFO pool 54 may be read by the ETR 290 block 56 according to the pointer, to extract and calculate video information (such as rate, video & Audio codec information, and transport stream performance information according to ETR 290 standard).
  • Play out software block 55 reads packets from the Stream pointer FIFO pool according to a rate calculated from the packet Program Clock Register (PCR) or network rate.
  • PCR Program Clock Register
  • Play out software block 55 reads packets from the Stream pointer FIFO pool according to a rate calculated from the packet Program Clock Register (PCR) or network rate.
  • the rate may be calculated based on statistics calculated in the ETR290 block 56 and supplemented by using the PCR information.
  • the rate may be read from time to time and written to the playout block 55. Any Played packet is then freed from the memory pool 52.
  • PCR Program Clock Register
  • Any new FEC packet received is forwarded 52G to the processor block 53 with a pointer for a free memory block to recover lost packets.
  • the Processor block 53 may read 53 A one or more pointers from the Stream pointer FIFO pool 54 to recalculate the missing packet in conjunction with the FEC packet.
  • the recovered packet pointer and Sequence numbers are written to the Stream pointer FIFO pool 54 according to the Sequence number 53B.
  • the recovered packet is written to the memory pool for further storage 53 C.
  • Figure 8 illustrates a probe device, detailing its internal building blocks and data flow.
  • Media packets Video/media or FEC ) arrive at the Ethernet MAC port 51.
  • Each packet is stored in a memory buffer 52. 2. For each assigned packet, the software assigns a pointer 52E that points to the memory buffer 52B in packet memory management block 52.
  • the Software extracts the Sequence number from each Video/media packet header and sends it with the memory pointer 59,52D to the INPUT processing 58 block.
  • the TS INPUT block 58 copies the packet pointer and Sequence number to the Stream pointer FIFO Pool 54; each entry is indexed according to the Sequence number
  • Any RTCP message received by the INPUT 51 is sent 52G to the Processor block 53 to extract the missing packet information.
  • the Processor block 3 reads the requested Packet 54 A from the Stream pointer FIFO pool 54.
  • the Processor block 3 may read one or more pointers 54 A, 54B from the Stream pointer FIFO pool 54, to calculate the a FEC packet to recover the requested missing packet or packets.
  • the Calculated FEC packet ( one or more ) are sent to the Play out 55 for transmission 53D
  • a Packet stored in the Stream pointer FIFO pool 54 may be read by the ETR 291 block 56 according to the pointer, to extract and calculate video information (which may include a rate, video & Audio codec information, and transport stream performance information according to ETR 290 standard).
  • the matrix as shown in Figure 9 is unrecoverable using standard (prior art) solutions.
  • packets D19, D20, D27, D28 cannot be recovered by standard means because they create an event that more than two packets are lost in either row or column such that No packet may be recovered.
  • Figures 9 and 10 depict the "migration" from a matrix view, as is the case in ProMpeg and SMPTE2022 (Prior Art), to a fiat sequential/continuous view as shown in Figure 10.
  • the stream 125 is riddled with occasional lost packets 1253A- 1253G, which are colored gray in the Figure.
  • Figure 11 illustrates an example, using the present invention, of a packet recovery method for missing packets with various Lengths.
  • the Figure depicts the FEC packet calculation and various lengths that the invention may call/use to recover lost packets.
  • the Length may be of 2, 3... n.
  • the basic assumption is: that received packets are always used as reference for a lost packet. This approach assures that both the detection and probe device have the reference packet stored. The system may also consider to use a 'recovered' packet as a reference too (in case no close reference packet is available ) The stream has lost several packets 1253 A- 1253G, A notice of these lost packets reaches the probe device for processing.
  • the system detects that no previous packet were lost, so it can decide to apply a fix 1251 in column fashion in the length of 2, and a fix 1252 in the same length
  • the system detects that it has several packets till 1253B that were not lost, so it can decide to apply a fix 1253 in column fashion in the length of 3.
  • the system detects that it has several packets till 1253B that were not lost (except 1253C ) , so it can decide to apply a fix 1256 in column fashion in the length of 4 and use the same reference packet as for 1253C.
  • the system detects that it has several packets till 1253B that were not lost (except 1253C.1253D ) , so it can decide to apply a fix 1254 in column fashion in the length of 3.
  • the system detects that no previous packet were lost, so it can decide to apply a fix 1255 in column fashion in the length of 2, and fix 1257 in the same length
  • Figures 9 - 11 also depict the bandwidth savings with an adaptive FEC: the Matrix in figure 9 is 8 x 5 in size, which will correlate to 5+8 protection packets (8 column + 5 row at a constant bandwidth taken all the time ).
  • the solution with adaptive FEC in Figure 10 shows that we need only 8 correction packets (for 1253 A- 1253G ) and may be used only when needed.
  • Figures 13 and 14 depict the ability to process several clients/users, which is an important benefit of embodiments of the present invention:
  • Figure 13 depicts a flat view of the stream, illustrating a received stream 125 in the Detection device clients with missing packets:
  • Client #1 is missing packets 1253A,1235B,1253C
  • Client #2 is missing packets 1254A,1254B,1254C
  • Client #3 is missing packets 1253C and 1255.
  • Figure 14 presents one way to address the problem, so as to solve it:
  • Fix 125 A solves the loss of 1253 A by way of a column in the length of 2
  • Fix 125B solves the loss of 1254 A by way of a column in the length of 3
  • Fix 125C solves the loss of 1254B by way of a column in the length of 3
  • Fix 125D shows two different missing packets: 1255 is missing from client #3 while 1253C is missing for both client #1 and #3.
  • the solution is to do a Row FEC in size 4 and use several reference packet to recover the two lost packets. In this case, a single FEC reference packet will reconstruct 1255 and 1253C.
  • Fix 125E shows two different missing packets: 1253B is missing from client #1 while 1254 is missing for client #2.
  • the solution is to do column FEC in size 4 and use a combination of 1253B + 1254 and reference packet to generate a single FEC reference packet will reconstruct 1253B and 1254.
  • a means in the network for calculating one common FEC packet supporting (referring to) packets sent from two or more transmitters (clients). This option for addressing together the needs of different clients saves bandwidth, because of the elimination of additional packets for each client.
  • a prior art system needs 13 packets (8 columns + 5 rows sent at constant bandwidth taken all the time); whereas in an embodiment of the present invention, using the adaptive FEC as shown in Figure 14, only 5 correction packets are needed, and it may be used only when needed.
  • Figures 12, 13 and 14 illustrate an example of one embodiment of a packet recovery method for missing packets with various Lengths.
  • Figures 12 and 1 depict the "migration" from a matrix view, as is the case in
  • ProMpeg and SMPTE2021 (Figure 12), to a flat sequential/continuous view ( Figure 13). Two types of lost packets are depicted; client #1 lost packets are colored gray while client #2 are highlighted with black borders 1124.
  • Figure 14 depicts the FEC packet calculation and various lengths that an embodiment of the current the invention may call or use to recover lost packets.
  • the Length may be of 2,3..n.
  • a single FEC packet can recover D14 and D18, which reduce the over head bandwidth.
  • the matrix as shown in Figure 12 is unrecoverable by standard (prior art) solutions (e.g. packets D19,D20,D27,D28 cannot be recovered by standard means).
  • Figure 15 illustrates a system architecture including both intrusive and non-intrusive deployment topology. The figure shows a system description and the various options for deploying Probe and Detection devices.
  • Probe #1 14 is connected in a non-intrusive mode (in parallel with transmitter #1 11), whereas Probe #2 14B is connected in an intrusive mode (in series with transmitter #2 1 IB).
  • the Detection device #1 15 is connected in an intrusive mode (in series with receiver #1 13), whereas the Detection devices #2 15B and #3 15C are connected in a non-intrusive mode (in parallel with receivers #2 13B and #3 13C respectively).
  • the Intrusive devices ( Probe #2, Detection #1 ) have at least one input and one output interface. Data flows from input to output with added processing in the device itself.
  • a benefit of using an intrusive probe device is a simpler data flow through each element; data flow from Transmitter #2 through Probe #2 allows for easy connection and a clear traffic flow, so that the Probe device will be assured to get all the packets from the transmitter into his packet buffer.
  • a benefit of using a Detection device in an intrusive mode is a larger buffer, which can shield/buffer the Receiver device from network artifacts such as jitter, packet reorder and packet loss.
  • Another benefit of the intrusive mode is that it allows the Detection device (see Detection #1 15) to recover packets without the knowledge of the receiver (Receiver #1 13) and perform a rate adjust.
  • the non-intrusive device (Probe #1 14, Detection #2 15B and #3 15C) are devices which have only a common input and output interface, Data flow in and out of the device with added processing in the device.
  • a benefit of using a non-intrusive device is an ability to put it anywhere in the network in a seamless fashion, so that it does not disturb the original network traffic.
  • the devices can be simply added to the network and add their capabilities.
  • Probe #1 14 is added in parallel to the Transmitter #1 11 ; it is up to the network operator to duplicate/direct the traffic from Transmitter #1 11 to allow Probe #1 14 to capture the packets in its memory buffer.
  • Detection #2 15B and #3 15C may be placed somewhere along the network 12 to allow them to detect packet loss events and alert the Probe device 14 or 14B to take action.
  • the system and method described hereinabove may be used in conjunction with: a system which consists of adaptive FEC block + network j itter reduction and/or with a system which consist of adaptive FEC matrix block + network jitter reduction.
  • Embodiments of the present invention comprise system solution to protect a media network from artifacts of packet loss and improve use of network bandwidth.
  • the system consists of a probe device (Probe #1 ,#2 ) connected in an intrusive or non- intrusive mode, and a Detection device (Detection #1 ), connected in a intrusive mode, see Figure 15.
  • the detection device performs two major tasks: Adaptive FEC packet correction and Network jitter reduction.
  • a novel feature of this solution is that the detection device shields the network artifacts from the receiver device (receiver #1 13) to allow it to receive a media stream free of lost packets and with a minimal jitter—which are crucial to media reception solutions.
  • Embodiments of the present invention comprise a system solution to protect a UDP streaming network from artifacts of packet loss and network jitter; the system consists of a probe device ( Probe #1 ,#2 ) connected in an intrusive or non-intrusive mode and a detection device ( Detection #1 ) connected in an intrusive mode.
  • a probe device Probe #1 ,#2
  • Detection #1 a detection device connected in an intrusive mode.
  • Figure 16 illustrates a system architecture using both a public and a private network.
  • the stream passes through the public network 12 to the detection device 15, while corrective action passes through a private VPN network 12D (which preferably should be error free or may have a lower error rate).
  • a private VPN network 12D which preferably should be error free or may have a lower error rate.
  • a probe device connects to the stream for media packet buffering and to a VPN 12D connection for RTCP and Recovery packets.
  • a detection device may connect in an intrusive mode to both the data stream and a VPN connection. The detection device will buffer the received packets in its packet memory buffer and use the VPN connection to request and receive correction packets (this feature can be used for example in adaptive FEC, Adaptive matrix,
  • the Detection device 15 will shield/buffer the network jitter from the receiver device (Receiver #1 13).
  • This system may be used to stream a UDP media stream from one transmitter 11 to a one or more Receivers 13 ( see Figure 17 ).
  • the incoming stream is buffered in the probe ( probe #1 14) Packet buffer.
  • Each UDP packet is converted by the Probe device 14 from an UDP protocol to a RTP protocol, for example by adding a RTP header and a virtual time stamp to each UDP packet,
  • the Probe 14 and the Detection 15 devices may then use an additional method to recover loss packets in the stream between them.
  • the major benefit is the ability to convert from an unrecoverable streaming protocol to a recoverable one and back to a system that does not support RTP protocol.
  • Figure 17 illustrates a system architecture wherein a probe 14 and detection means 15 communicate through the network 12 and apply an adaptive FEC/Matrix, for a transmission from the transmitter #1 11 to the receiver #1 13.
  • the UDP stream entering the Probe 14 is first converted to RTP, while the detection device 15 converts back from RTP to UDP.
  • the detection device 15 buffers the received packets and applies a correction to recover lost packets.
  • the detection device 15 strips the RTP header from each packet to convert it back to a UDP and transmit it to the receiver (receiver #1 13).
  • the Packets are sent using the rate jitter reduction patent to reduce the network jitter.
  • This feature may be used with an adaptive FEC method and system, and or a jitter reduction system and method, to stream over a public internet.
  • the solution includes re-multiplexing each stream into 1-N different UDP ports, wherein each carries a portion of the packets (e.g. 1/N, N number of selected paths ).
  • Each path may be protected using an Adaptive FEC system and method to protect against packet loss in that specific path.
  • Figure 18 illustrates an optional improvement of the ⁇ video delivery network, using a probe 14 and a detection device 15.
  • a transmitter 11 sends packets through a probe 14, a network 12 and a detection device 15, to a receiver 13.
  • This optional improvement uses adaptive FEC packets/matrix for streaming over a public internet.
  • the system uses re-multiplexing each stream into 1- N different UDP ports; each carrying a portion of the packets ( e.g. 1/N, N number of selected paths ).
  • Each path will be protected by an Adaptive FEC patent to protect against packet loss in that specific path.
  • the Probe 14 splits the original stream into multiple smaller streams (up to N) while the detection device 15 receives the stream and applies an adaptive FEC/Matrix to each smaller stream.
  • the detection device 1 then re-multiplexes these streams into a single stream which is sent to the receiver #1 13.
  • Probe device 14 may include an additional block module to re-multiplex the stream into partial streams send on different ports.
  • the multiplexing may be according to a modulo N basis (e.g. each packet will be assigned to a port according to its Sequence number) or any other priority scheme.
  • each 'new' stream shouldbe assigned with at least 5 UDP ports (1 data, + 1 RTCP, +2 Column FEC , +4 Row FEC ).
  • Probe other modules are left unchanged (e.g. packet buffer, processor ) and the only addition is a block to re-multiplex the stream; any RTCP message is considered as a request from a detection device and will be handled with no change.
  • Probe device 14 should preferably be connected in an intrusive fashion (in series with the transmit path, see Figure 2) so that the transmitting device need not be aware of the re- multiplexing of the original stream.
  • Detection device 15 may have an additional module for multiplexing back the partial streams before being stored in the packet memory buffer. Detection device 15 may have to maintain N clients for each partial stream. Each client passes the received packet to the packet buffer memory. Each client maintains a missing packet detection process for each partial stream. In the event of a missing packet detection, the client issues a RTCP message associated with that stream UDP port number. Each client transfers the FEC packet to the processor to recover the lost packet. Detection device 15 may perform a jitter reduction method to send the packet to the original destination.
  • the method described hereinabove may be used in a Cloud

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne, dans un réseau de transfert fiable de paquets d'un émetteur à un récepteur, au moyen d'un Protocole Internet (IP), un système de récupération de paquets comprenant un bloc de détection (détecteur) pour la détection de perte de paquets et un dispositif de sonde (sonde) pour la transmission de paquets à correction d'erreurs sans voie de retour (FEC), le détecteur comprenant des moyens pour envoyer un rapport de paquet manquant à la sonde lors de la détection d'un paquet manquant, la sonde comprenant des moyens pour stocker les paquets reçus, envoyer les paquets FEC et adapter la taille des paquets FEC à un taux d'erreur calculé à partir des rapports de paquet manquant, la taille des paquets FEC étant augmentée ou réduite en réponse à respectivement l'augmentation ou la diminution du taux d'erreur, et la sonde se trouvant à proximité de l'émetteur pour la réception de paquets fiable et le détecteur se trouvant à proximité du récepteur pour détecter de manière fiable la perte de paquets dans un environnement du récepteur.
PCT/IL2012/000402 2012-01-01 2012-12-31 Système et procédé de correction d'erreur sans voie de retour (fec) adaptatif WO2013098810A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/370,030 US9577682B2 (en) 2012-01-01 2012-12-31 Adaptive forward error correction (FEC) system and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IL217307A IL217307A (en) 2012-01-01 2012-01-01 Continuous error correction (fec) system and method
IL217307 2012-01-01

Publications (1)

Publication Number Publication Date
WO2013098810A1 true WO2013098810A1 (fr) 2013-07-04

Family

ID=45855249

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL2012/000402 WO2013098810A1 (fr) 2012-01-01 2012-12-31 Système et procédé de correction d'erreur sans voie de retour (fec) adaptatif

Country Status (3)

Country Link
US (1) US9577682B2 (fr)
IL (1) IL217307A (fr)
WO (1) WO2013098810A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017127000A1 (fr) 2016-01-20 2017-07-27 Telefonaktiebolaget Lm Ericsson (Publ) Procédés, système et équipement utilisateur d'un réseau de communication sans fil pour déterminer des conditions de transmission pour un flux multimédia en temps réel

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL217304A0 (en) * 2012-01-01 2012-02-29 Video Flow Ltd Media stream rate reconstruction system and method
US9578319B2 (en) * 2012-03-02 2017-02-21 Broadcom Corporation Transmission variable delay and jitter indication
US9386067B2 (en) * 2013-12-30 2016-07-05 Sonic Ip, Inc. Systems and methods for playing adaptive bitrate streaming content by multicast
WO2016009902A1 (fr) 2014-07-18 2016-01-21 ソニー株式会社 Dispositif de réception, procédé de réception, et programme informatique
CN104811651B (zh) * 2015-03-20 2017-08-25 中国人民解放军信息工程大学 电路域骚扰电话无感替换方法
TWI573147B (zh) * 2015-11-05 2017-03-01 大心電子股份有限公司 解碼方法、記憶體儲存裝置及記憶體控制電路單元
US10594661B1 (en) * 2017-06-13 2020-03-17 Parallels International Gmbh System and method for recovery of data packets transmitted over an unreliable network
TWI665893B (zh) * 2017-12-05 2019-07-11 財團法人工業技術研究院 無線通訊方法及應用其之通訊終端裝置
US10714098B2 (en) 2017-12-21 2020-07-14 Dolby Laboratories Licensing Corporation Selective forward error correction for spatial audio codecs
US11689323B2 (en) 2020-02-16 2023-06-27 Video Flow Ltd. Efficient on-demand packet recovery for broadcast and multicast networks system and method
JP7139371B2 (ja) * 2020-03-19 2022-09-20 アンリツ株式会社 誤り率測定装置及びデータ分割表示方法
US11303954B1 (en) 2021-01-04 2022-04-12 Sony Corporation Long duration error correction with fast channel change for ATSC 3.0 real-time broadcast mobile application
US11451853B1 (en) 2021-08-06 2022-09-20 Sony Group Corporation Measuring ATSC 3 RF environment using autonomous vehicle

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020053062A1 (en) * 2000-03-31 2002-05-02 Ted Szymanski Transmitter, receiver, and coding scheme to increase data rate and decrease bit error rate of an optical data link
US20090193318A1 (en) * 2002-01-04 2009-07-30 Scientific-Atlanta, Inc. Forward error correction and interleaving of network frames
US20090222709A1 (en) * 2008-02-28 2009-09-03 Ip Video Communications Coporation Universal packet loss recovery system for delivery of real-time streaming multimedia content over packet-switched networks
US20100023842A1 (en) * 2008-07-25 2010-01-28 Nortel Networks Limited Multisegment loss protection
US20100318870A1 (en) * 2009-06-16 2010-12-16 Canon Kabushiki Kaisha Transmission apparatus, receiving apparatus, method, and storage medium
US20110261145A1 (en) * 2010-04-27 2011-10-27 Kamath P Raghavendra Determining Buffer Size Based on Forward Error Correction Rate

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3757857B2 (ja) * 2001-12-12 2006-03-22 ソニー株式会社 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
JP4000905B2 (ja) * 2002-05-22 2007-10-31 ソニー株式会社 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム
US8351400B2 (en) * 2004-05-05 2013-01-08 Qualcomm Incorporated Method and apparatus for overhead reduction in an enhanced uplink in a wireless communication system
US20090168708A1 (en) * 2007-12-26 2009-07-02 Motorola, Inc. Techniques for maintaining quality of service for connections in wireless communication systems
US8165091B2 (en) * 2008-06-27 2012-04-24 Nix John A Efficient handover of media communications in heterogeneous IP networks using LAN profiles and network handover rules

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020053062A1 (en) * 2000-03-31 2002-05-02 Ted Szymanski Transmitter, receiver, and coding scheme to increase data rate and decrease bit error rate of an optical data link
US20090193318A1 (en) * 2002-01-04 2009-07-30 Scientific-Atlanta, Inc. Forward error correction and interleaving of network frames
US20090222709A1 (en) * 2008-02-28 2009-09-03 Ip Video Communications Coporation Universal packet loss recovery system for delivery of real-time streaming multimedia content over packet-switched networks
US20100023842A1 (en) * 2008-07-25 2010-01-28 Nortel Networks Limited Multisegment loss protection
US20100318870A1 (en) * 2009-06-16 2010-12-16 Canon Kabushiki Kaisha Transmission apparatus, receiving apparatus, method, and storage medium
US20110261145A1 (en) * 2010-04-27 2011-10-27 Kamath P Raghavendra Determining Buffer Size Based on Forward Error Correction Rate

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017127000A1 (fr) 2016-01-20 2017-07-27 Telefonaktiebolaget Lm Ericsson (Publ) Procédés, système et équipement utilisateur d'un réseau de communication sans fil pour déterminer des conditions de transmission pour un flux multimédia en temps réel
EP3567769A1 (fr) 2016-01-20 2019-11-13 Telefonaktiebolaget LM Ericsson (publ) Procédés, équipement utilisateur et système d'un réseau de communication sans fil permettant de déterminer les conditions de transmission pour un flux multimédia en temps réel
US10707998B2 (en) 2016-01-20 2020-07-07 Telefonaktiebolaget Lm Ericsson (Publ) Methods, system and user equipment of a wireless communication network for determining transmission conditions for a real-time media flow
US11463199B2 (en) 2016-01-20 2022-10-04 Telefonaktiebolaget Lm Ericsson (Publ) Methods, system and user equipment of a wireless communication network for determining transmission conditions for a real-time media flow

Also Published As

Publication number Publication date
US20140317475A1 (en) 2014-10-23
IL217307A0 (en) 2012-02-29
US9577682B2 (en) 2017-02-21
IL217307A (en) 2015-09-24

Similar Documents

Publication Publication Date Title
US9577682B2 (en) Adaptive forward error correction (FEC) system and method
US9641588B2 (en) Packets recovery system and method
US9565482B1 (en) Adaptive profile switching system and method for media streaming over IP networks
US11374681B2 (en) Video quality assessment method and device
KR101972951B1 (ko) 오버헤드를 최소화한 헤더를 가지는 패킷 기반의 미디어 데이터 전송 방법
US20200029130A1 (en) Method and apparatus for configuring content in a broadcast system
US7796598B2 (en) Synchronizing redundant video streams encapsulated in IP/UDP packets
US9781488B2 (en) Controlled adaptive rate switching system and method for media streaming over IP networks
US8301982B2 (en) RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows
JP2017130955A (ja) デジタル放送システムにおけるデータを受信する装置
US20090213728A1 (en) Apparatus and method for packet redundancy and recovery
US9363684B2 (en) Determining loss of IP packets
EP2667625A2 (fr) Appareil et procédé de transmission de données multimédias dans un système de diffusion
US9647951B2 (en) Media stream rate reconstruction system and method
JP5296224B2 (ja) インターネットプロトコルに基づくテレビジョンシステムにおけるテレビジョンデータの伝送中の信頼性を確保する方法およびデバイス
WO2013098812A1 (fr) Transport sur système et procédé
KR102093408B1 (ko) 동일 포트에 멀티플렉싱 된 다중 패킷 스트림의 패킷오류 구분을 선택적으로 수행하는 방법 및 그 장치
US20190191195A1 (en) A method for transmitting real time based digital video signals in networks
Fernando MMT: the next-generation media transport standard
US20090158376A1 (en) Method and apparatus of building ip-based video service system in hybrid fiber coax network
Mammi et al. Evaluation of AL-FEC performance for IP television services QoS
WO2012173391A2 (fr) Procédé de transmission de données multimédia par paquets comprenant un en-tête dans lequel le surdébit est réduit au minimum
Bartolin et al. Reliable real-time video delivery over IP networks
Laabs SDI over IP
Update From Video into Packets Encapsulation MPEG Stream Types Case Study: Uncompressed Video over IP

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12861866

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14370030

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12861866

Country of ref document: EP

Kind code of ref document: A1