JP5755213B2 - Recovering from burst packet loss in internet protocol based wireless networks using stagger casting and cross-packet forward error correction - Google Patents

Description

  The present invention relates to wireless networks, and more particularly to recovery from random and burst packet loss using staggercasting in combination with cross-packet forward error correction.

  Although wireless local area networks (WLANs) were originally designed for data communications, interest and demand for WiFi multimedia applications is growing rapidly. Video multicasting over IEEE 802.11 WLANs allows live video and pre-recorded entertainment programs to be efficiently distributed to multiple receivers simultaneously. However, digital video delivery requires high reliability, limited delay, and bandwidth efficiency. Wireless links become unreliable due to time-varying burst link errors. In particular, in video multicast applications, different receivers of the same video may be subject to different channel conditions. Since the receiver may also leave or join during the session, the network topology changes. In addition, there is no link layer retransmission and link layer adaptation for multicast in the current IEEE 802.11 standard. Incorrect packets are simply discarded. To the application layer, it looks like a packet erased channel. Packet loss can be detected by examining the sequence number in the packet header. Therefore, it is an important and difficult task to support quality of service (QoS) for all receivers of multicast video in a desired service area while efficiently utilizing available WLAN resources. is there.

  In video multicast / broadcast in an IP type wireless network, video data is encapsulated in UDP / IP packets and multicast / broadcast to mobile devices in the wireless network. The IP type wireless network may be a wireless local area network (WLAN), a cellular network, a wireless metropolitan area network (WMAN), and a regional wireless network (WRAN). When a mobile device moves from one cell to another cell, it is handed over / handed off from the currently associated base station (BS) / access point (AP) to another BS / AP. The two BS / APs generally operate at different frequencies / channels. If the mobile device changes operating frequency and is associated with a new BS / AP, multiple packets are lost.

  Typically, the broadcast signal is sent simultaneously to all possible receivers. The multicast signal is sent simultaneously to the selected part (s) of all possible receivers in the group. The multicast used here includes broadcast. That is, the multicast signal may be sent to a selected portion of all possible receivers in the group, and the selected portion may include the entire portion of all possible receivers. That is, the multicast group is all receivers.

  In wireless systems, channel coding is used at the physical layer to protect packets against multipath fading and interference. However, channel coding within a packet cannot recover packet loss during handover / handoff.

  One prior art method provides dual data transmission (staggercasting) time delayed / time shifted from the original data in an ATSC system, improving the robustness of the broadcast system. When a dual time-staggered stream is transmitted, the system can tolerate signal loss up to the duration of the time shift between the two streams. Another prior art method provides that a low bit rate version of the original data (instead of the exact original data) is repeatedly transmitted with a time delay. This approach reduces the bandwidth used by redundant data. However, both of these prior art methods send composite signals and always send signals regardless of whether there is a client / receiver requesting / requiring data.

  Yet another prior art method provides for the use of cross-packet forward error correction (FEC) codes to protect against synchronization loss in ATSC systems. FEC codes are also used to recover lost packets in IP type wireless networks. In general, erroneous packets are discarded by the link layer. FEC codes are applied through data packets at the transport and application layers, and erasure decoding is used to recover lost packets. However, in general, FEC parity packets are transmitted along with data packets. Long handy bursts can occur during handoff / handover. These long false bursts result in the loss of data and parity packets exceeding the FEC function, which makes it impossible to recover lost data packets.

  A large amount of research and theoretical analysis on various application layer forward error correction (FEC) and automatic repeat request (ARQ) algorithms to recover from packet loss and improve transmission reliability in wireless networks A simulation is being performed. Other prior art methods describe an ACK hybrid ARQ algorithm for unicast video transmission and progressive video coding (MDFEC) with FEC for multicast video transmission in WLAN. Yet another prior art method provides a receiver-driven FEC scheme for multicast in a wired Internet environment, where FEC packets are delayed from video packets. However, this method focuses on how to optimize the performance of heterogeneous receivers in a wired Internet environment.

  The method addressed and solved by the present invention is how to recover random and burst packet loss and achieve seamless handoff to ensure high quality video multicast / broadcast over IP-type wireless networks. .

  In wireless networks, mobile devices can experience random and burst packet loss. This may be for handover / handoff from one base station / access point to another base station / access point. Data transmitted during these periods is lost to the receiver / mobile device. The present invention provides a method and apparatus for recovering from data packet loss for seamless handoff / handover by repeatedly transmitting data packets and cross-packet FEC parity packets with time shifting (stagger casting). The prior art considers how to recover if all video packets of a coded block that may occur during packet loss of a burst (eg, during wireless network handoff or as a result of shadowing) are lost. It has not been. In addition, how to synchronize video packets and parity packets in FEC encoded blocks at the receiver, how packet padding information is communicated, and conventional FEC failure for backward compatibility. The prior art does not consider how to support possible receivers.

  The system described herein includes one or more servers / sources / transmitters, radio base stations or access points, Ethernet switches, and receivers. The receiver used here is typically a mobile device. Mobile devices include, but are not limited to, mobile phones, cellular phones, mobile terminals, video players, personal digital assistants (PDAs), and laptops.

  Normal / original data and time-shifted parity data are transmitted backward compatible using different IP multicast groups. That is, even when the mobile device does not have the function provided by the present invention, it can still receive and decode only normal data packets with low system resiliency against packet loss. The delayed parity packet is discarded by the mobile device. This achieves backward compatibility with conventional devices.

  The present invention is an FEC scheme in which the application layer time is shifted to recover from random and burst packet loss. In particular, the present invention provides a seamless service during random and burst packet loss (i.e., no video failure). The present invention takes into account the characteristics of video multicasting and provides an application layer countermeasure for seamless handoff. Even if multiple video packets are completely lost in a burst, the lost packets can be recovered only from the corresponding FEC parity packets.

  A method and system for transmitting data packetizes data, performs forward error correction (FEC) encoding on the packetized data to generate at least one parity packet, and pads at the end of the payload data of the packetized data And adding FEC information and transmitting packetized data and at least one parity packet. A method and system for recovering from packet loss also includes receiving a data packet, receiving at least one parity packet, buffering the received data packet, detecting packet loss, and forwarding at least one parity packet forward. It is described as including error correction decoding, recovering from packet loss using forward error correction information extracted from the data packet and at least one parity packet, and forwarding the recovered packet via an internal socket. The stagger casting method also encodes and compresses a first data sequence, packetizes the compressed encoded data sequence, forms a data packet, and generates a second data sequence for the first data sequence. , Perform forward error correction (FEC) coding on the data packet, add FEC information as padding at the end of the payload data of the data packet, packetize the second data sequence, form a packet, Multicasting to one multicast group and multicasting a packet formed using a second data sequence delayed by an offset time to the second multicast group is described.

Schematic diagram of a multicast system in an internet protocol wireless network using stagger casting Schematic diagram of an exemplary video server / transmitter architecture Exemplary client proxy architecture in accordance with the present invention Example of FEC stagger casting method of the present invention when K = 4 and N = 8 Normal padding scheme for RS encoding RS hybrid normal padding scheme Source RTP packet format according to the present invention capable of supporting hybrid padding Parity RTP packet format Flowchart of an exemplary video server / encoder implementation with parity packets generated by a cross-packet forward error correction (FEC) code in a delay recovery multicast group in accordance with the principles of the present invention. Schematic diagram of an exemplary video server / encoder implementation with parity packets generated by a cross-packet forward error correction (FEC) code in a delay recovery multicast group in accordance with the principles of the present invention. Example of cross-packet coding according to the principles of the present invention Flowchart of an exemplary mobile receiver implementation with parity packets generated by a cross-packet FEC code in a delay recovery multicast group in accordance with the principles of the present invention. Schematic diagram of an exemplary mobile receiver implementation with parity packets generated by a cross-packet FEC code in a delay recovery multicast group in accordance with the principles of the present invention. Luminance SNR (SNR-Y) for each frame of the original 10-second long video sequence Luminance SNR of looped 1 minute long video sequence (SNR-Y) Average SNR-Y of the sequences in Table 1 at various interference levels Corresponding link quality detected by the client in two forms Residual packet loss rate (PLR) at various interference levels Video quality of sequences F and G with different FEC delays and handoff / burst durations Video quality of sequences F and G with different FEC delays and handoff / burst durations Video quality of sequences F and G with different FEC delays and handoff / burst durations Video quality of sequences F and G with different FEC delays and handoff / burst durations Video quality of sequences F and G with different FEC delays and handoff / burst durations Video quality of sequences F and G with different FEC delays and handoff / burst durations Quality comparison between sequences F and G

  The invention is best understood from the following detailed description when read with the accompanying drawing figures. The drawings include the following figures briefly described below. In the drawings, like numbering represents like elements.

  The present invention is directed to staggercasting in a wireless network to recover from random and burst data packet loss. This is realized by transmitting data packets and cross packet FEC parity packets with time shift / time delay. The present invention is independent of the video coding scheme. Although video multicast over a wireless network is used as an example to illustrate the present invention, the present invention can also be used to transmit an audio stream.

  Referring to FIG. 1, an exemplary wireless network according to the present invention is shown. Multiple base stations / access points AP1, AP2 form a cellular network and increase the service area. In order to reduce interference, neighboring radio base stations / access points AP1 / AP2 operate on different frequency carriers / radio channels. At least one video server 105 is connected to a plurality of wireless base stations (BS) or access points (AP) through a high-speed Ethernet LAN or other wired high-speed network. Video server 105 includes, among other components, a video encoder / transcoder and a packetizer. In raw video multicast / broadcast, video content is encoded / transcoded, packetized, and transmitted to multiple mobile clients (110, 115a, 115b, 120a, 120b, 125) through the radio base stations / access points AP1, AP2. Multicast to Pre-encoded video content is also packetized and multicast to multiple mobile clients through the wireless base station / access point.

  When a mobile device (eg, 115a, 120b) moves from one cell to another cell, the mobile device may change from the currently associated base station (BS) / access point (AP) to another BS / AP. Handover / handoff. If the mobile device (115a, 120b) changes its operating frequency and is associated with a new BS / AP, multiple packets may be lost. In order to recover from packet loss and achieve seamless handover, the present invention was generated from data packets with video content (data packets) and FEC codes (eg, time-shifted half-rate Reed-Solomon codes) Provide simultaneous transmission of parity packets. The normal video packet stream is transmitted to all base stations / access points in the IP multicast group (normal video multicast group). Further, the shifted / shifted / delayed FEC stream is transmitted to all mobile devices in another multicast group (delay recovery multicast group). Here, this technique is called staggercasting. Normal video streams and time-shifted FEC streams provide time diversity and improve system robustness in handover / handoff situations. The system transparently tolerates packet loss up to the duration of the time shift.

  A mobile device may participate only in a video group. When a mobile device hands off from a BS / AP to an adjacent BS / AP, if an error is detected, or as soon as a handoff / handover occurs, the mobile device will both have a normal video multicast group and a delayed FEC multicast group. Request to join / subscribe to the new BS / AP. The new BS / AP transmits / multicasts both the normal video packet stream and the delayed FEC packet stream by multicasting over the radio link. The mobile device receives both streams. If the participation time is less than the time shift between the video stream and the FEC parity stream, the corresponding parity packet is received by the mobile device to recover the lost video packet. When the mobile device detects that some packet has been lost in the normal video packet stream, the mobile device switches to a time-delayed FEC packet stream and recovers the lost packet. If the time shift duration / duration between the normal video packet stream and the delayed FEC stream is greater than the handoff time (or burst), the lost video data can be recovered. After the lost data of the normal video packet stream is recovered, the mobile device sends a request to the BS / AP to leave / release / end the delayed FEC multicast group. If the mobile device associated with the BS / AP does not require multicast group data (normal video data or delayed FEC data) (ie, if there are no members of the multicast group), the BS / AP may Discard data without sending group data. This saves radio bandwidth. IGMP (Internet Multicast Management Protocol) or other protocols may be used to request the BS / AP that the mobile device joins or leaves the multicast group. In an alternative embodiment, the mobile device sends a request to join or leave the multicast group to the Ethernet switch. If the mobile device related to the BS / AP does not request data of the multicast group, the Ethernet (registered trademark) switch does not transmit the data of the multicast group to the BS / AP.

  In particular, still referring to FIG. 1, mobile device 115b moves from a cell served / supported by AP2 to a cell served / supported by AP1. When this is done, the mobile device (115a supported by AP1 at this time) requests AP1 to join / join the normal video and delayed FEC multicast group, and the normal video packet stream (stream 1) Both delay / time shift FEC stream (streak 2) is received. If an error is detected in the normal video packet stream (if any packet is lost), the mobile device switches to a time-delayed FEC packet stream and recovers the lost packet. If the time shift duration between the normal video packet stream and the delayed FEC stream is greater than the handoff time, the received corresponding parity packet is used to recover the lost video packet. After the lost data of the normal video packet stream is recovered, the mobile device 115a may send a request to leave / release / end the delayed video multicast group to the BS / AP.

  Similarly, the mobile device 120a moves from a cell serviced / supported by AP1 to a cell serviced / supported by AP2. When this is done, the mobile device (120b supported at this time by AP2) requests AP2 to join / join the normal video and delayed FEC multicast group, and the normal video packet stream (stream 1) Both delay / time shift FEC stream (streak 2) is received. If an error is detected in the normal video packet stream (if any packet is lost), the mobile device switches to a time-delayed FEC packet stream and recovers the lost packet. If the time shift duration between the normal video packet stream and the delayed FEC stream is greater than the handoff time, the received corresponding parity packet is used to recover the lost video packet. After the lost data of the normal video packet stream is recovered, the mobile device 120b may send a request to leave / release / end the delayed video multicast group to the BS / AP.

  Any systematic FEC code (eg, Reed-Solomon (RS) code) may be used with erasure decoding to recover lost packets. In an exemplary embodiment, FEC parity packets generated by cross packet forward error correction coding at a video streaming server are transmitted to a delay recovery IP multicast group. It should be noted that the FEC code is applied through video packets (cross packets) to generate parity packets. This is because when FEC coding is applied in a single packet at the application layer, the erroneous packet is discarded by the receiving MAC layer and is not available for application layer error correction. If an RS (N, K) code is applied through K video packets to generate (NK) parity packets, at least K packets (whether video packets or parity packets) are exactly within each coding block. As long as it is received, the original K video packets can be recovered.

  The FEC code is applied to the video data packet to generate a parity packet. The video packet stream and the parity packet stream are time-shifted and multicast to different IP multicast groups (ie, stagger casting the video stream and the parity stream for time diversity). In particular, the original video packet stream and the further FEC parity packet stream are transmitted to all BS / APs in different IP multicast groups with time shift by Ethernet / video / streaming server (ie video Staggercasting the stream and the FEC parity stream). Each BS / AP transmits a video stream and an FEC parity stream by multicast in the WLAN. Thus, normal video streams and time shifted parity streams provide time diversity and improve video multicast robustness.

  FIG. 2 is a schematic diagram of an exemplary video server / transmitter architecture. FIG. 2 illustrates a video transmitter / server implementation of a video multicast system using staggered FECs according to an embodiment of the present invention. The UDP / IP protocol stack 220 is used for video multicasting. In fact, the protocol stack includes RTP, but the RTP portion (packetization) 205 of the protocol stack is separated from the UDP / IP portion of the protocol stack and is processed before FEC encoding by the FEC encoding module 210. The In this case, the video sequence is pre-compressed and stored in a file in MP4 format. For compression efficiency, H.264 video encoding is used in the exemplary embodiment of the present invention. Other video encoding schemes are possible. The video can also be compressed in real time by a video encoder. The FEC encoding module 210 is placed after the RTP packetization 205 but before the UDP / IP layer 220. The compressed video is packetized by the RTP packetizer 205, and an RTP packet header is added. According to the present invention, FEC-related control information is added to the video packet as padding by the FEC encoding module 210. In a normal video packet (for example, 3GPP packet), the FEC encoded information is inserted after the RTP header and before the RTP payload (video data). By moving the FEC control information as video packet padding, the pad format is ignored by conventional players, so the packet format is backward compatible with conventional players that are not FEC capable.

  The systematic FEC code is applied through the video packet at the FEC encoding module to generate a parity packet. A Reed-Solomon (RS) code constructed using a Vandermonde matrix is used in the exemplary embodiment. In RS (N, K) code, K video packets are grouped together. During encoding, an RS code is applied to the packet group, and one symbol from each packet consists of a code word. (N-K) parity packets are generated from K video packets. In order to enable decoding at the receiver, a header is added to the FEC packet containing FEC information. In an exemplary embodiment, the FEC parameters N and K may be adjusted dynamically in real time.

The video packet is transmitted to the BS / AP through the UDP / IP stack 220 and the Ethernet (registered trademark) interface 225 in the IP multicast group (ordinary video multicast group). The FEC parity packet is stored in the delay buffer 215 during the offset time _Td . The FEC parity packet is sent to the BS / AP after the delay over the UDP / IP stack 220 and the Ethernet interface 225 in another IP multicast group (Delay Recovery (FEC) multicast group).

  Session description protocol (SDP: Session) to indicate video multicast group and FEC multicast group information, including multicast address, video encoding format, FEC encoding scheme, etc., and association between video stream and parity packet stream Description Protocol) is used. The SDP file may be downloaded to the client at the start of the session via the Hyper Text Transfer Protocol (HTTP) or Real Time Streaming Protocol (RTSP), and via the Session Announcement Protocol (Session Announcement Protocol) You may be notified by a streaming server.

  Commercial and freeware video players (eg, Quicktime and VLC players) are available, but these players do not support FEC encoding. Source code is generally not available for commercial players, and FEC support cannot be integrated. It is difficult to integrate FEC encoding support into all freeware players, and it is difficult to maintain and update FEC encoding support even if freeware player source code is available . The present invention is directed to the client proxy architecture 300 shown in FIG. The client proxy architecture 300 of the present invention works with any commercial and freeware video player. The client proxy receives video and FEC packets from different multicast groups, recovers lost video packets, and sends recovered video packets to the player through an internal socket.

  FIG. 3 is an exemplary client proxy architecture according to the present invention. The client proxy may be hardware, software, firmware, application specific integrated circuit (ASIC), reduced instruction set computer (RISC), field programmable gate array (FPGA), or any combination thereof. A client proxy is present in a mobile device such as a video player and forms part of the mobile device. Normal video packets and delayed parity (recovery) packets are received from different multicast groups by the client proxy via the WLAN interface 305 and the UDP / IP protocol stack 310. On the video / streaming server side, the RTP portion (depacketization) 325 of the protocol stack is separated from the UDP / IP portion 310 of the protocol stack. Received video data packets are delayed in buffer 315. This can be achieved, for example, by an initial playout delay. The FEC erasure decoding module 320 is arranged after the UDP / IP stack 310. Incorrect packets are discarded by the link layer. The location of the lost video packet or parity packet is detected by the FEC erasure decoding module 320 through the sequence number in the packet header. The sequence number of the packet header is used for erasure decoding. When packet loss is detected, a request to join the delayed FEC multicast group and obtain the corresponding parity packet is sent to the BS / AP. The FEC header of the parity packet and video packet is used by the FEC decoding module 320 to determine the FEC block information. With RS (N, K) code, FEC erasure decoding is performed by the transmitter as long as any K packets out of N packets of the FEC coding block are correctly received regardless of video data packets or parity packets. The original video packet can be reconstructed in the case of all packets padded to the longest packet during encoding with. FEC erasure decoding is an inverse process of encoding. Encoding is performed through packets, and one symbol from each packet is composed of codewords. The padding is discarded from the recovered video / source packet after the video / source packet loss is recovered using the FEC parity packet. The recovered video packet is sent to the video player 340 via the internal socket and UDP / IP stack 330. The recovered video packet may be received through a single UDP / IP stack (eg, UDP / IP stack 335) by a video player 340 in a loopback configuration. The recovered video / data packet may also be forwarded to other video players. The video file is stored by the RTP depacketizer 325.

  Since the original RTP video source packet is unchanged except for the FEC information used as padding, this FEC mechanism can be used in a mixed multicast scenario with FEC enabled and non-FEC receivers. Padding information should be ignored by non-FEC players based on the RTP specification. If the mobile device does not have the FEC function, it can receive only normal video packets from the video multicast group with low system resiliency against packet loss. Parity packets of different multicast groups are discarded by the protocol stack. This provides backward compatibility.

Burst packet loss may occur during handover of a mobile device. Some or all of the video packets of the coded block are lost during handover / handoff. In order to solve this problem in the present invention, a half-rate RS code is used. In RS code with erasure decoding, each parity packet can recover any one of the lost packets of the encoded block. When a half-rate RS (N, K) code (N = 2K) is applied to K video packets, it generates K parity packets. With a half-rate RS code, even if a video packet is completely lost in a burst during handover, the lost packet can be recovered from only the corresponding parity packet. In this sense, the parity packet stream generated by the half-rate RS code is another description of the original video packet stream. The system can transparently tolerate packet loss of bursts up to the duration of the time shift _Td between the video stream and the parity stream.

FIG. 4 is an example of the FEC stagger casting method for recovering the packet loss of the burst of the present invention when K = 4 and N = 8. Parity packets with RS (8,4) code and NK = 4 are generated from source packets with K = 4, respectively. A rectangular packet belongs to one FEC encoded block, and an elliptical packet belongs to another FEC encoded block. Video and FEC parity packets can be lost during bursts such as handover. The receiver performs FEC erasure decoding on the received video packet and the corresponding parity packet. As long as at least K packets (video or parity packets) are correctly received, the original K source packets can be recovered. If not stagger casting, 6 packets (FEC and video) have been received, so the rectangular block packet can be recovered. However, since only the second packet is received correctly, the elliptical block packet is not recoverable. In the case of stagger casting, since there is a time difference of _Td between the video stream and the parity stream, the position of the lost packet is different. Since at least four packets are received per block, both rectangular and elliptical block packets can be recovered. Stagger casting realizes time diversity between a video stream and a parity stream.

The time shift _Td between the information / video stream and the parity stream is a design parameter. This may be selected based on the expected maximum packet burst loss duration due to handoff or shadowing. The expected length of handoff or shadowing loss should be less than _Td . In a half-rate RS code, the recoverable length of burst loss does not depend on the parameters N and K of the RS code. This provides flexibility in system design. By adjusting the time shift _Td , handover loss or shadowing loss can be recovered.

  In an RS codec implementation, it is advantageous to select a symbol length of 8 bits for fast encoding and decoding. This results in an RS code with a block length N ≦ 255 octets. The exemplary embodiment of the present invention uses 1 byte symbols. A short block length and size RS code may be obtained by puncturing and shortening a mother code with N = 255. The punctured code is the (NL, K) code obtained from the (N, K) mother code, and the shortened code is obtained from the (N, K) mother code (NL, K). KL). The implementation of the present invention is based on the Vandermonde generator matrix for efficient erasure correction. The RS (N, K) codeword is composed of K source symbols and (N-K) parity symbols. During the encoding process, the K × N Vandermonde generator matrix is converted to its systematic version. In the systematic version, the first K columns form an identity matrix, and the RS codeword is calculated by multiplying a vector of K symbols by a systematic generator matrix. Since the code is systematic, the first K encoded symbols are exactly the same as the original source symbols. During decoding, a K × K submatrix is formed from the K columns of the systematic Vandermonde matrix according to the position of the received K symbols in the codeword. The submatrix is inverted and the original K source symbols are recovered by multiplying the vector of K received symbols by the inverted submatrix.

  In order to avoid error propagation, each RTP / UDP / IP packet contains only the compressed data (video frame or slice) of the video coding unit so that the packet size changes. In order to keep decoding complexity low, it is desirable to perform matrix inversion only once per source block. Therefore, the position of the received symbol needs to be the same in all RS codeword rows of the source block. Padding is used to form source blocks and the packet size is constant.

  One padding technique is shown in FIG. Before the FEC code is applied, the short packet of the source coding block is zero-padded so that the length of the short packet is equal to the length of the largest packet of the source coding block. Become. A 2-byte RTP packet size field is inserted before each source packet during FEC encoding, so that the decoder knows the number of padding symbols in the recovered source packet. Note that the packet size field is not transmitted because the packet size can be obtained from the IP layer by the decoder. During encoding, a plurality of codewords are calculated through the padded packet, and each codeword is composed of one symbol from the padded packet. When RS (N, K) codes are used, (N-K) parity packets are generated from K source packets. If the change in packet size is too large, this padding scheme results in a significant amount of padding, so the majority of the FEC overhead is used to protect the padding symbols. Padding symbols are not transmitted, but FEC performance is reduced.

  Another padding technique called hybrid padding is shown in FIG. Large packets are stacked through multiple rows of the matrix. The size of each row of the coding block, called coding unit size U, can be determined to minimize padding overhead. This padding approach reduces the total amount of padding and still has low decoding complexity for variable size packets. Each source packet begins with a new line in the source block. If the packet length is not an integer multiple of the line length, padding symbols are added at the end of the line. Note that padding symbols are used only to calculate parity packets. Padding symbols are removed from the video / source packet before sending the packet by the FEC encoding module. The number of rows in the source block should be less than or equal to K. A 2-byte RTP packet size field is inserted before each source packet during FEC encoding, so that the decoder knows the number of padding symbols in the received video / source packet. The packet size field is not transmitted because the packet size can be obtained from the IP layer by the decoder.

  RS (N, K) codes are applied along the sequence. That is, the code word is composed of one symbol from each column. This padding approach maintains low decoding complexity. Since the position of the lost symbol is the same for all columns of the RS codeword of the source block, only one matrix inversion is required to decode the source block. It should be noted that the standard padding technique is a special case where the row size is equal to the maximum packet length. A parity packet may include one or more rows of encoded parity symbols.

  There is a trade-off in selecting a parity packet size. When the packet size is small, the transmission of parity packets becomes more robust, but the header overhead increases. When large packet sizes are used, packets are easily lost, and loss of a single parity packet results in loss of multiple parity rows. The maximum possible number of rows in each FEC parity packet depends on the row size U, the maximum transmission unit (MTU) of the channel, and the desired level of robustness. The FEC information (used according to the invention as padding for video / source packets) is necessary in order for the receiver to be able to correctly decode the coded block.

  FIG. 7a shows a source RTP packet format that can support hybrid padding according to the packet format of the present invention. The original RTP header and payload fields are unchanged from non-FEC systems. The original RTP header and payload are protected by FEC encoding. A 4-byte FEC control information field is added to indicate the source block number (SBN) of the packet and its position in the block (ie, the starting row number of this packet). FEC information is used as RTP padding. The packet format is similar to that defined by the 3GPP specification, but according to the present invention, FEC related control information is added to the video packet as RTP padding by the FEC encoding module. In a normal video packet, FEC encoding information is inserted after the RTP header and before the RTP payload (video data). By moving FEC information as RTP padding, the packet format becomes backward compatible with non-FEC mobile devices such as video players. When hybrid padding is used, FEC control information is necessary for the FEC decoding module to decode the FEC block. Otherwise, the decoder does not know the number of rows of lost video / source packets. According to RFC 3550 of the RTP standard, if the padding bits are set in the RTP header, the end further padding octets should be ignored by the RTP depacketizer. The last octet of the padding contains a count of how many padding octets, including myself, should be ignored. Conventional players that are not FEC capable of supporting RTP padding may receive only video multicast groups and ignore padding FEC control information. Since the original RTP source packet is unchanged except for some padding information, this FEC mechanism can be used in a mixed multicast scenario with FEC-capable and non-FEC receivers. Padding information should be ignored by non-FEC capable players. Tests with multiple H.264 compatible players show that this method works well with VLC players and Thomson MMAF players. This is because these players support RTP padding. The Quicktime player cannot directly receive a video stream with FEC control information. This is because padding is not supported.

  FIG. 7b shows a parity RTP packet format. Parity FEC packets are also sent using the UDP / IP protocol stack. The payload type (PT) of the FEC parity packet is dynamically assigned using an out-of-band signaling mechanism (eg, SDP file). This is different from the original source payload format. The PT specifies the FEC encoding scheme and its parameters for the payload. To assist in decoding the parity packet at the receiver, an FEC control information header is added after the RTP header to indicate the FEC block information and the encoding parameters. Similar to the format defined in 3GPP, the FEC header of a parity packet includes (1) a source block number (SBN): an ID of a source block to which the source packet belongs, and (2) an encoding unit ID (EUI). : Encoding Unit ID): Start line number of this packet in the encoding block, (3) Source block length (SBL): Number of source lines in the source block (ie, K), and (4) Code Encoding block length (EBL): the total number of lines (ie, N) and (5) encoding unit length (U): the length of the line in bytes. Note that each coding unit here corresponds to a row.

  FEC decoding on the client side is the reverse process of encoding. Received source and parity packets belonging to the source block may be buffered together based on the SBN. If any lost source RTP packet is detected by a sequence number gap, a parity packet with the same SBN can be used to recover the lost video / source packet. If any parity packet is available, the FEC coding parameters (N, K), the size of the source block and the row size may be determined by the FEC control information of the FEC parity packet. An encoded block may be formed with expected lost rows with lost source and FEC parity packets according to the EUI field (ie, source and parity packet starting row numbers). If the number of lost rows is less than (N-K), the lost source rows can be decoded and recovered. It should be noted that before inserting the source RTP packet into the source line, the packet length is appended before the first source line of the parity packet. This is useful for video / source packet recovery. The first two bytes of the recovery packet have its “packet size”. Starting from the third byte, the number of “packet sizes” from the recovered source belongs to the packet. Since the remaining symbols in the row are padding symbols, they are discarded. The padded FEC control information and padding length bytes are removed from the correctly received video / source RTP packet prior to FEC decoding by the FEC decoding module.

FIG. 8a is a flowchart of an exemplary transmitter / server implementation for performing video multicast over a wireless IP network using FEC parity packets in a delay recovery IP multicast group. In 805. Uncompressed video sequence data is received and encoded / transcoded / compressed. At 810, the encoded / transcoded / compressed video sequence data is packetized and a packet header is added. At 815, the packetized encoded / transcoded / compressed video sequence data is FEC encoded to form an FEC parity packet. The FEC code is applied through the video packet to generate a parity packet. The header is added to the FEC packet including FEC information. Extra FEC-related control information is also added to the video data packet. At 825, video data packets are transmitted / multicast to an IP multicast group (normal video multicast group). At 820, the parity packet is stored during the offset time _Td . At 825, the FEC parity packet is multicast / transmitted to another IP multicast group (delay / recovery multicast group) after the delay / time shift _Td .

FIG. 8b is a schematic diagram of an exemplary transmitter / server implementation for performing video multicast over a wireless IP network using FEC parity packets within a delay recovery IP multicast group. The video encoder / transcoder / compressor 830 receives the uncompressed video sequence data and encodes / code converts / compresses the uncompressed video sequence data. The encoded / transcoded / compressed video sequence data is communicated to the packetizer 835, which packetizes the encoded / transcoded / compressed video sequence data to form a data packet. Add a packet header. The packetized encoded / transcoded / compressed video sequence data is communicated to the FEC encoder 840 to form a parity packet. The FEC encoder is placed after the packetizer, but before the protocol stack 850. The FEC code is applied through the video packet to generate a parity packet. The header is added to the FEC packet including FEC information. FEC related control information is also added to the video data packet. The video data packet is immediately transmitted / multicast to the IP multicast group (ordinary video multicast group) through the protocol stack 850 and the Ethernet / WLAN interface 855. The protocol stack 850 includes at least a UDP layer 850a and an IP layer 850b. The parity packet is stored in the delay buffer 845 during the offset time _Td . The FEC parity packet is transmitted / multicast to another IP multicast group (delay / recovery multicast group) via the protocol stack 850 and the Ethernet / WLAN interface 855 after the delay / time shift _Td . The components described herein may be hardware, software or firmware or any combination thereof including RISC, ASIC and / or FPGA.

  For systematic FEC codes, the FEC encoding module waits until enough video / source packets fill the encoded block, and then the FEC encoding module generates parity packets. In another embodiment, the FEC encoding module adds FEC-related control information to the video / source packet and waits until the packet is filled immediately after the packet is passed to the FEC encoding module by the packetizer. It is also possible to send / multicast packets without sending them. The FEC encoding module keeps a copy of this packet in the encoding block buffer. As described above, after the encoding block is filled and the FEC encoding module generates a parity packet, the already transmitted video / source packet is discarded. This is because video / source packets have already been transmitted.

FIG. 9 is an example of cross-packet coding according to the principles of the present invention. As shown in FIG. 9, K video packets are grouped together, and a Reed-Solomon (RS) (N, K) code is applied to the packet group to generate NK parity packets. The header includes which video packet this FEC packet protects and is added to the FEC packet containing FEC information. FEC related control information is also added to the video packet. The video data packet is transmitted to the IP multicast group (ordinary video multicast group) via the UDP / IP stack and the Ethernet (registered trademark) interface. The parity packet is stored in the delay buffer during the offset time _Td . The FEC parity packet is transmitted to another IP multicast group (delay / recovery multicast group) via the UDP / IP and Ethernet® interfaces after the delay / time shift _Td .

  FIG. 10a is a flowchart of an exemplary mobile receiver / device implementation that performs video multicast over an IP-type wireless network using FEC parity packets in a delay / recovery multicast group. At 1005, normal video data packets and delayed parity packets including video sequence data are received from different multicast groups. At 1010, these are separated into video packets and parity packets. At 1015, the received video data packet is stored. Incorrect video and parity packets are discarded by the link layer (WLAN interface). At 1020, FEC erasure decoding is performed. The position of the lost video data packet or parity packet is detected through the sequence number of the packet header by the FEC erasure decoding process. The FEC control information added to the FEC header of the parity packet and the video data packet is used to determine the FEC block information. As long as an RS (N, K) code (whether a video data packet or a parity packet) is correctly received, any F or more of the N packets of the FEC encoded block, the FEC erasure decoding process is The original (normal) video packet can be reconstructed. At 1025, the FEC erasure decoded video data packet is depacketized. At 1030, the depacketized video data packet is video decoded to produce a decoded video for display.

One embodiment uses a half-rate RS code. Half-rate RS codes are used to generate other descriptions of the original data. With RS code in erasure decoding, each parity packet can recover any one lost packet in the coding block. When a half-rate RS (N, K) code (N = 2K) is applied to K video packets, it generates K parity packets. With a half-rate RS code, even if multiple video data packets are completely lost in a burst during handover, the lost data packet can be recovered from only the corresponding parity packet. In this sense, the parity packet stream generated by the half-rate RS code is an alternative to the original (normal) video packet stream. It should be noted that in addition to Reed-Solomon (RS) codes, other FEC codes can also be used to generate parity packets. The present invention with a half-rate RS code can transparently tolerate packet loss up to the duration of the time shift _Td between the original video packet and the FEC parity packet.

  FIG. 10b is a schematic diagram of an exemplary mobile receiver / device implementation that performs video multicast in an IP-type wireless network using FEC parity packets in a delay / recovery multicast group. Normal video data packets and delayed parity packets are received from different multicast groups at the WLAN / Ethernet (registered trademark) interface 1035. These are separated into video data packets and parity packets by the protocol stack 1040. The protocol stack 1040 includes at least a UDP layer 1040a and an IP layer 1040b. Received video data packets are delayed in buffer 1045. Incorrect video and parity packets are discarded by the link layer (WLAN interface). The FEC erasure decoding module 1050 is between depacketization and the UDP layer. The position of the video data packet or parity packet is detected by the FEC erasure decoding module 1050 through the sequence number of the packet header. The FEC erasure decoding module 1050 is used for erasure decoding. The FEC control information added to the FEC header and video packet of the parity packet is used by the FEC erasure decoding module 1050 to determine the FEC block information. For RS (N, K) codes, the FEC erasure decoding module 1050 is as long as any K or more of the N packets of the FEC encoded block (whether video data packets or parity packets) are correctly received. The original (normal) video data packet can be reconstructed. The FEC erasure-decoded video data packet is communicated to the depacketizer 1055, and the depacketizer 1055 depackets the video data packet. The depacketized video data packet is communicated to the video decoding module 1060. The components described herein may be hardware, software or firmware or any combination thereof including RISC, ASIC and / or FPGA.

  If the return radio channel from the mobile device to the BS / AP is not available, and / or if a simple system implementation is preferred, the BS / AP always sends a normal video stream and a delay recovery stream in multicast over the wireless network. May be. The mobile receiver / device receives both streams without requesting it. For recovery of random packet loss, it is also possible to always transmit a specific FEC parity packet in another multicast group without time shifting according to channel conditions. The remaining FEC parity packets are sent in a delay recovery (FEC) multicast group to correct packet loss for bursts.

  Using the ORBIT wireless network testbed, the effects of FEC overhead and delay between video and FEC streams on video quality at different interference levels and mobile handover times were investigated. The effectiveness of the FEC stagger casting of the present invention has been demonstrated using experimental data from an Orbit testbed. All video sequences are encoded in H.264. The video resolution is 720 × 480 and the frame rate is 24 frames per second. There is one I frame every 2 seconds. Instantaneous decoder refresh (IDR) intra pictures are invalid. Slice mode is used in the encoder, each packet carries a unique slice, ensuring that each lost packet does not affect the validity of other correctly received packets and avoids error propagation .

  The intermediate video sequence “Kungfu” was selected for testing. The original video is 10 seconds long, which means that there are 240 frames with 5 I frames. FIG. 11a shows the luminance component signal-to-noise ratio (SNR-Y) of a video sequence after being encoded with I / P frame quantization parameters set to 27 and 450 byte slice sizes. The periodic pulse every 48 frames indicates the position of the I frame and is also shown by a dotted vertical grid. As the motion of the video sequence increases, the SNR-Y of 240 frames decreases gradually. The original video sequence loops 6 times to get a 1440 frame (1 minute) sequence. The SNR of the luminance component of the one-minute sequence shows a seesaw format as shown in FIG. 11b.

  Next, the effectiveness of FEC protection for video multicast in noisy environments was tested using the Orbit testbed. The original 10 second long video sequence is looped 30 times to get a 5 minute long sequence. The video is transmitted by multicast using IEEE 802.11a channel 64 and mode 1. The transmission power is set to 15mW to make it susceptible to noise interference. The noise generator in the Orbit testbed is used to generate AWGN interference centered on channel 64 in the 20 MHz band. The client is associated with the BA / AP to receive FEC protected and non-FEC protected video sequences. Received video data is decoded to compare video quality.

  For a fair comparison, 5 video sequences are encoded from the same raw video using different quantization parameters to obtain similar overall (RTP packet and FEC packet) traffic bit rates at different FEC encoding rates. Table 1 shows the encoding parameters and overall bit rates of the five video sequences used in FIG. The overhead of the UDP / IP / MAC / PHY header is included in the traffic statistics in Table 1.

図１２は、様々な干渉レベルでの表１のシーケンスについての平均SNR-Yを示している。各場合について、干渉が閾値を超えると、急速にビデオ品質が低下する。これは、各符号化ブロックでFECパリティパケットは全ての損失パケットを回復するか、或いは損失パケットを全く回復しないかという理由のためである。ビデオシーケンスに誤り伝搬も存在する。曲線の閾値は、強力なFEC符号では高い干渉レベルで生じる。しかし、ほとんど誤りがない場合、低干渉レベルではSNR-Yは強力なFEC符号でわずかに小さい。これは、強力なFEC符号により必要となる高いオーバーヘッドがビデオソースのレートを低減するからである。実験では、干渉が小さい場合（13dbmの雑音）、FECの冗長性のため、FECオーバーヘッドが高くなるほど、ビデオ品質が低くなることがわかる。しかし、雑音が増加すると、FEC保護はその有効性を示す。雑音が約7dbmに到達すると、受信シーケンスの一部は、大きいパケット損失のため復号化不可能である。実験データは、雑音が6dbmに到達すると、これらの5つの受信シーケンスがもはや復号化不可能であることを示している。雑音が5dbmである場合、BS／APとクライアントとの間の関連付けは時々壊れる。通常では、良好なビデオ品質のソース符号化レートでの動作点と、所望のビデオマルチキャストサービスエリア範囲に基づいてパケットから回復するのに十分なFEC保護とが選択され得る。

FIG. 12 shows the average SNR-Y for the sequence of Table 1 at various interference levels. For each case, video quality degrades rapidly when the interference exceeds a threshold. This is because in each coding block, the FEC parity packet recovers all lost packets or does not recover lost packets at all. There is also error propagation in the video sequence. Curve thresholds occur at high interference levels with strong FEC codes. However, if there are few errors, SNR-Y is slightly smaller with a strong FEC code at low interference levels. This is because the high overhead required by a strong FEC code reduces the rate of the video source. Experiments show that when the interference is small (13dbm noise), the higher the FEC overhead, the lower the video quality due to FEC redundancy. However, as noise increases, FEC protection shows its effectiveness. When the noise reaches about 7 dbm, part of the received sequence cannot be decoded due to large packet loss. Experimental data shows that when the noise reaches 6dbm, these five received sequences are no longer decodable. If the noise is 5dbm, the association between the BS / AP and the client is sometimes broken. Typically, an operating point at a good video quality source coding rate and sufficient FEC protection to recover from the packet based on the desired video multicast service area range may be selected.

  FIG. 13 shows the corresponding link quality detected by the client in two forms (number on 94 scale and received signal strength on dbm). FIG. 13 shows a linear relationship between the interference level and the link quality detected by the client.

  FIG. 14 shows the residual packet loss rate (PLR) at various interference levels. In each case, the PLR increases rapidly when the interference exceeds the threshold. As mentioned above, this is because FEC corrects all errors or not at all. Curve thresholds occur at high interference levels with strong FEC codes.

  In block FEC, the FEC encoder always waits for enough video packets to fill the K symbols of the encoded block, and the FEC encoder generates (NK) parity packets and sends the parity packets To do. Therefore, there is always a spread / delay between the FEC packet transmission time and the source packet transmission time. This depends on the coding unit size T, the number K of source symbols, and the original video traffic pattern. This inherent spread (? Delay) is difficult to manage and calculate. Table 2 shows the sequence used in the staggered FEC experiment. Sequence G has 100% FEC protection, and Sequence F has no FEC protection. For a fair comparison, the two video sequences were encoded from the same “KungFu” raw video using different quantization parameters to obtain similar overall bandwidth usage. The video sequence is looped long enough to accommodate 5 handoffs (burst duration). In this case as well, the UDP / IP / MAC / PHY header is included in the traffic statistics.

ハンドオフ（バースト）持続時間の長さと、ハンドオフ／バーストの間に損失したパケットの性質（Iフレームに属するかPフレームに属するか）とは、受信ビデオ品質に影響を及ぼす２つの重要な要因である。実行されたテストでは、FECパリティストリームは、固有の拡散（?遅延）に加えて、元のビデオストリームに対してそれぞれ0秒、1秒及び2秒の値で遅延している。様々なハンドオフ持続時間での受信ビデオ品質が計算され、時間をずらしたFECマルチキャストの有効性を示すために比較された。図１５（ａ）は、ハンドオフ持続時間が0.2秒であり、FECストリームが0秒の遅延（これはFECパケットが生成時に直ちに送信されることを意味する）である場合のシーケンスF及びGのビデオ品質を示している。FECのないシーケンスFでは、ビデオ品質は、ハンドオフ／バーストの間に急激に低下する。FEC保護のあるシーケンスGは、余計なFEC遅延すらなしに、受信機で完全に回復されている。前述のように、これは、強力なFECの誤り訂正機能と、小さいハンドオフ／バースト持続時間中のパケット損失の比較的短いバーストと、FECパケット送信時間及びソースパケット送信時間の固有の拡散（?遅延）とのためである。

The length of the handoff (burst) duration and the nature of the packet lost during handoff / burst (whether it belongs to I or P frame) are two important factors affecting the received video quality. . In the tests performed, the FEC parity stream is delayed by values of 0 seconds, 1 second, and 2 seconds, respectively, with respect to the original video stream, in addition to the inherent spreading (? Delay). Received video quality at various handoff durations was calculated and compared to show the effectiveness of staggered FEC multicast. FIG. 15 (a) shows sequence F and G videos when the handoff duration is 0.2 seconds and the FEC stream has a delay of 0 seconds (which means that FEC packets are sent immediately upon generation). Shows quality. In sequence F without FEC, the video quality drops off sharply during handoff / burst. The sequence G with FEC protection is fully recovered at the receiver without any extra FEC delay. As mentioned earlier, this is a powerful FEC error correction function, a relatively short burst of packet loss during a small handoff / burst duration, and a unique spread (? Delay) of FEC packet transmission time and source packet transmission time. ) And for.

  Another point of interest shown in FIG. 15 (a) is that even if a handoff / burst loss has begun, until the next I frame (this position is indicated by a vertical dotted line) is correctly received. Video quality is always a complete recovery. This may depend on the error concealment scheme used in the video decoder. Frame copy error concealment is used in the experiment. In FIG. 15 (a), the five handoffs / bursts have the same duration (all are 0.2 seconds), but because of the different handoff / burst start points for the next I frame, the width of the quality impairment is different. . The difference becomes clearer in FIG. 15 (b), with the third handoff / burst, the video quality is fully recovered until the I frame is lost and the next I frame is received correctly after 2 seconds. .

  FIG. 15B shows the video quality of sequences F and G when the handoff interval is 0.5 seconds and the FEC stream has a delay of 0 seconds. In FIG. 15 (b), some of the handoff loss bursts are larger than what the FEC without delay can handle, so there is video quality degradation in the FEC protected video sequence G. As handoff / burst duration increases, many packets are lost during handoff / burst. If there is no delay between the video and parity streams, even with strong FEC, lost packets are not recoverable.

  FIG. 15C shows the video quality of sequences F and G when the handoff duration is 1.8 seconds and the FEC delay is 0 seconds. Another interesting point shown in FIG. 15 (c) is that the last three quality impairments of sequence G (with FEC protection) are smaller than sequence F (without FEC protection). This is because some source RTP packets from two consecutive blocks were lost during handoff / burst. The one from the first block is unrecoverable because the FEC packet was similarly lost during handoff / burst. The one from the second block is recovered because the FEC packet was received correctly.

  FIG. 15 (d) shows a quality comparison between video sequences F and G. The FEC delay has increased to 1 second. FIG. 15d shows that a 1 second FEC delay is sufficient to recover a handoff / burst duration of 0.8 seconds. However, when the handoff / burst duration increases beyond the FEC delay, the received video quality can no longer be guaranteed.

  FIG. 15 (e) shows a quality comparison between video sequences F and G when the handoff / burst duration is set to about 1.8 seconds. In this case, a one second FEC delay is no longer sufficient.

  FIG. 15 (f) shows a quality comparison between video sequences F and G. The FEC delay has increased to 2 seconds. At this time, there is no quality loss of sequence G during handoff / burst. Note that a half-rate RS code (N = 2K) was applied in this handoff / burst experiment. The parity packet stream generated by the half-rate RS code is another description of the original video packet stream. Even if all video packets are lost in bursts during handoff, the lost packets can be recovered only from the corresponding parity packets. The system can guarantee recovery from burst packet loss up to the duration of the time shift between the video stream and the parity stream without further random packet loss.

  The effectiveness of FEC stagger casting is more characteristic when sequences F and G are transmitted in an AWGN environment with a handoff duration of 0.2 seconds. FIG. 16 shows a quality comparison between sequences F and G. In FIG. 16, the video quality of sequence F has completely lost its shape, but the quality of sequence G shows only a small degradation.

  It will be appreciated that the invention can be implemented in various forms of hardware, software, firmware, special purpose processors, or combinations thereof. The present invention is preferably implemented as a combination of hardware and software. Furthermore, the software is preferably implemented as an application program that is embodied in a program storage device. The application program may be uploaded to and executed by a machine having any suitable configuration. The machine is preferably implemented on a computer platform having hardware such as one or more central processing units (CPUs), random access memory (RAM), and input / output (I / O) interfaces. The computer platform also includes an operating system and microinstruction code. The various processes and functions described herein may be part of the microinstruction code executed via the operating system, or part of the application program (or a combination thereof). In addition, various other peripheral devices may be connected to the computer platform such as an additional data storage device and a printing device.

  Since some of the system components and method steps of the components shown in the attached drawings are preferably implemented in software, the actual connections between system components (or processing steps) are programmed with the present invention. It can be further seen that it can vary depending on the method used. Given the teachings herein, one of ordinary skill in the related art will be able to contemplate these and similar implementations or configurations of the present invention.

  The following items are further disclosed with respect to the above embodiments.

(1) A method for transmitting data,
Packetize the data;
Performing forward error correction (FEC) encoding on the packetized data to generate at least one parity packet;
Add FEC information as padding at the end of the payload data of the packetized data,
Transmitting the packetized data and the at least one parity packet.

  (2) The method according to (1), further comprising delaying transmission of the at least one parity packet for a predetermined period.

  (3) The method according to (1), wherein the transmitting operation is realized using a user datagram protocol (UDP) / Internet protocol (IP) stack and a wireless local area network interface.

(4) A system for transmitting data,
Means for packetizing the data;
Means for performing forward error correction (FEC) encoding on the packetized data to generate at least one parity packet;
Means for adding FEC information as padding at the end of the payload data of the packetized data;
Means for transmitting the packetized data and the at least one parity packet.

  (5) The system according to (4), further comprising means for delaying transmission of the at least one parity packet at a predetermined offset time.

  (6) The system according to (4), wherein the means for adding FEC information as padding at the end of the payload of the packetized data is executed by an FEC encoding module.

  (7) The system of (4), wherein means for performing forward error correction (FEC) coding on the packetized data to generate the at least one parity packet is performed by a FEC coding module.

(8) A method for recovering from packet loss,
Receive data packets,
Receive at least one parity packet;
Buffer the received data packet;
Detect packet loss,
Forward error correction decoding the at least one parity packet and recovering from packet loss using forward error correction information extracted from the data packet and the at least one parity packet;
Transferring the recovery packet via an internal socket.

  (9) The method according to (8), further comprising removing padding from the recovery packet.

  (10) The method according to (8), further comprising: depacketizing the recovery packet.

(11) A system for recovering from packet loss,
Means for receiving a data packet;
Means for receiving at least one parity packet;
Means for buffering the received data packet;
Means for detecting packet loss;
Means for forward error correction decoding the at least one parity packet to recover from packet loss using forward error correction information extracted from the data packet and the at least one parity packet;
And a means for transferring the recovery packet via an internal socket.

  (12) The system according to (11), further comprising means for removing padding from the recovery packet.

  (13) The system according to (11), further comprising means for depacketizing the recovery packet.

(14) encoding and compressing the first data sequence;
Packetizing the compressed encoded data sequence to form a data packet;
Performing forward error correction (FEC) encoding on the data packet to generate a second data sequence for the first data sequence;
Add FEC information as padding at the end of the payload data of the data packet,
Packetizing said second data sequence to form a packet;
Multicasting the data packet to a first multicast group;
A stagger casting method comprising multicasting the packet formed using the second data sequence delayed by an offset time to a second multicast group.

  (15) The method according to (14), wherein the second data sequence is a parity packet.

Claims (2)

A method for transmitting data,
Packetize the data;
Performing forward error correction (FEC) coding on the packetized data to generate a parity packet;
FEC control information including a padding length, a source block number, and a coding unit ID is added as padding at the end of payload data of the packetized data, where the padding length is an octet that forms the FEC control information The amount of
Transmitting the packetized data including the FEC control information and the parity packet to enable backward compatibility with non-FEC systems . A system for transmitting data,
Means for packetizing the data;
Means for performing forward error correction (FEC) encoding on the packetized data to generate a parity packet;
A means for adding FEC control information including a padding length, a source block number, and a coding unit ID as padding at the end of payload data of the packetized data , wherein the padding length is an octet forming the FEC control information Means for indicating the amount of
A system comprising: means for transmitting the packetized data including the FEC control information and the parity packet enabling backward compatibility with a non-FEC system.

Images