WO2007045141A1 - Procede de prise en charge de transmission de donnees multimedias avec tolerance aux erreurs - Google Patents

Procede de prise en charge de transmission de donnees multimedias avec tolerance aux erreurs Download PDF

Info

Publication number
WO2007045141A1
WO2007045141A1 PCT/CN2006/001846 CN2006001846W WO2007045141A1 WO 2007045141 A1 WO2007045141 A1 WO 2007045141A1 CN 2006001846 W CN2006001846 W CN 2006001846W WO 2007045141 A1 WO2007045141 A1 WO 2007045141A1
Authority
WO
WIPO (PCT)
Prior art keywords
error correction
forward error
data
correction coding
real
Prior art date
Application number
PCT/CN2006/001846
Other languages
English (en)
Chinese (zh)
Inventor
Zhong Luo
Bin Song
Original Assignee
Huawei Technologies Co., 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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2007045141A1 publication Critical patent/WO2007045141A1/fr

Links

Classifications

    • 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/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
    • 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/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0017—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy where the mode-switching is based on Quality of Service requirement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS

Definitions

  • the present invention relates to the field of multimedia communication technologies, and in particular, to a multimedia data transmission method supporting fault tolerance and flexibility. Background technique
  • Real-time streaming is a real-time transmission, especially for live events. Real-time streaming must match the connection bandwidth, which means that the image shield will be degraded due to the reduced network speed to reduce the need for transmission bandwidth.
  • the concept of "real time" means that the delivery of data in an application must be kept in precise time relationship with the generation of the data.
  • video communication is gradually becoming one of the main services of communication.
  • Two-way or multi-party video communication services such as video telephony, video conferencing, and mobile terminal multimedia services, impose strict requirements on the transmission of multimedia data streams and the quality of services. Not only does network transmission require better real-time performance, but equivalently requires video data compression coding to be more efficient.
  • the ITU-T Telecommunication Standardization Sector In view of the current demand for media communication, the ITU-T Telecommunication Standardization Sector officially released ⁇ .264 in 2003 after the development of video compression standards such as ⁇ 261, ⁇ 263, ⁇ .263+. standard.
  • This is an efficient compression coding standard jointly developed by ITU-T and the Moving Picture Experts Group (MPEG) of the International Standardization Organization (ISO) to adapt to the new phase of network media transmission and communication requirements. It is also the main content of Part 10 of the MPEG-4 standard.
  • MPEG Moving Picture Experts Group
  • the purpose of the H.264 standard is to improve video coding efficiency and its adaptability to the network more effectively. In fact, due to its superiority, the H.264 video compression coding standard has gradually become the mainstream standard in multimedia communication.
  • H.264 multimedia real-time communication products such as conference TV, videophone, 3G mobile communication terminal
  • network streaming products have been published. Whether to support H.264 has become the key to determining product competitiveness in this market segment. factor. It can be predicted that with the official promulgation and widespread use of H.264, multimedia communication based on IP networks and 3G and 3G wireless networks will inevitably enter a new stage of rapid development.
  • multimedia communication not only requires high efficiency of media compression coding, but also requires real-time transmission of the network.
  • multimedia streaming basically adopts Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP).
  • RTP is a transport protocol for multimedia data streams over the Internet, published by the Internet Engineering Task Force (IETF).
  • IETF Internet Engineering Task Force
  • RTP is defined to work in one-to-one or one-to-many transmissions with the goal of providing time information and stream synchronization.
  • the typical application of RTP is based on the User Datagram Protocol (UDP), but it can also work on other protocols such as TCP (Transport Control Protocol) or Asynchronous Transfer Mode (ATM). .
  • UDP User Datagram Protocol
  • ATM Asynchronous Transfer Mode
  • RTP itself only guarantees the transmission of real-time data, and does not provide a reliable transmission mechanism for transmitting packets in sequence, nor does it provide flow control or congestion control. It relies on RTCP to provide these services.
  • RTCP is responsible for managing the transmission quality to exchange control information between current application processes.
  • each participant periodically transmits RTCP packets, which contain statistics such as the number of transmitted packets and the number of lost packets. Therefore, the server can use this information to dynamically change the transmission rate, even Change the payload type.
  • RTP and RTCP work together to optimize transmission efficiency with effective feedback and minimal overhead, making it suitable for delivering real-time data on the network.
  • H.264 multimedia data is transmitted over the IP network, also based on UDP and its upper layer RTP protocol.
  • RTP itself is structurally applicable to different media data types, but different high-level protocols or media compression coding standards in multimedia communication (eg H.261, H.263, MPEG-1/-2/-4, MP3) Etc), the IETF will develop an RTP net for the agreement.
  • the specification file of the Payload packaging method which specifies the method of encapsulating large packets of RTP, is optimized for this specific protocol.
  • the corresponding IETF standard for H.264 is RFC 3984: RTP Payload Format for H.264 Video. This standard is currently the main standard for H.264 video stream transmission over IP networks, and is widely used. In the field of video communication, the products of major manufacturers are based on RFC 3984, and it is currently the only H.264/RTP transmission method.
  • H.264 defines a new layer, called Network Abstract Layer (NAL), which is a standard that makes it standard.
  • NAL Network Abstract Layer
  • the interface opens up the underlying business capabilities and shields the underlying network from the differences and abstracts the business capability layer.
  • VCL Video Coding Layer
  • H.264 brings greater application flexibility and defines a new layer of NAL.
  • the early ITU-T video compression coding protocols such as H.261, H.263/H.263+/H.263++ were not available.
  • RTP better for H.264, practical, and worthy of study.
  • the method of RTP carrying H.264 NAL layer data proposed by RFC3984 is the current mainstream transmission method.
  • RTP protocol RTC 3550
  • the scheme encapsulates NAL layer data in RTP payload for bearer.
  • the NAL layer is located between the VCL and the RTP, and specifies that the video stream is divided into a series of network abstraction layer data units (NALUs, NAL Units) according to defined rules and structures.
  • NALUs, NAL Units network abstraction layer data units
  • the encapsulation format of the RTP payload for NALU is defined in RFC3984. The following is a brief introduction to the RTP frame format and the NALU packaging method in the prior art.
  • RTP Real-time multimedia conferencing and continuous data storage, interactive distributed simulation, control and measurement applications.
  • RTP is typically carried over the UDP protocol to take advantage of its multiplexing and parity functions. If the underlying provides multipoint distribution, RTP supports multi-address delivery.
  • RTP includes: payload type identification, sequence numbering, timestamp, and transmission monitoring.
  • RTP packages the NA. package of H.264 into RTP. Packet flow.
  • the NALU is mainly defined in the RFC 3984 file, and based on this, the encapsulation and packing format of the H.264 layer NAL data in the RTP is given.
  • the RTP encapsulation format of this NALU is shown in Figure 2. '
  • Figure 1 shows the encapsulation structure of a NALU in the payload of the RTP.
  • the first byte in the previous byte is the NALU header information, followed by the data content of the NALU.
  • the multiple NALUs are filled end-to-end into the payload of the RTP packet.
  • RTP padding which is specified in the RTP packet format. In order to make the length of the RTP packet meet certain requirements (such as reaching a fixed length), the optional RTP padding data is generally filled with zeros.
  • the NALU header information is the first byte, also known as the octet (Octet), which has three fields.
  • the meaning and full name are respectively described as follows:
  • the F field is defined as a forbidden bit (forbidden-zero-bit), which is 1 bit, used to identify grammatical errors, etc., and is set to 1 if there is a syntax conflict.
  • a forbidden bit forbidden-zero-bit
  • the I field is defined as the NAL reference identifier (nal_ref_idc), which is 2 bits, used to indicate
  • NALU data whose value is 00 means that the content of the NALU is not used to reconstruct the inter-predicted reference picture, while the non-00 indicates that the current NALU is a slice or sequence parameter set belonging to the reference frame (SPS, Sequence Parameter Set), image parameter set (PPS, Picture Parameter Set) and other important data.
  • SPS Sequence Parameter Set
  • PPS Picture Parameter Set
  • the Type field is defined as NALU type (Nal_unitjype), a total of 5 bits, which can have
  • the information given in one byte of the NALU header information mainly contains the validity and importance level of the NALU. Based on this information, the importance of the data carried by the RTP can be determined.
  • H.264 video is the main protocol for multimedia communication in the future.
  • the network of future multimedia communication applications is mainly the packet switching network and wireless network represented by IP. Neither of these two types of networks can provide good quality of service (QoS) guarantees. Therefore, video transmission on the network is bound to be affected by various transmission errors and packet loss, resulting in lower communication quality.
  • the IP network implements "best effort" transmission, it does not guarantee the QoS of the transmitted video signal.
  • the best-effort transmission on the IP network does not guarantee the QoS of real-time video communication, which is manifested in three aspects: packet loss, delay, and delay jitter. Among them, packet loss has the greatest impact on the quality of recovered video.
  • H.264 compression coding algorithm uses motion estimation and motion compensation technology, once there is packet loss, it not only affects the current decoded image, but also affects the subsequent decoded image. Error spread. The effect of error spread on recovering video quality is very large. Only when the combination of the encoding end and the decoding end is combined with error resistance can the error spread be completely avoided.
  • Error Resilience refers to the ability of the transmission mechanism to prevent errors from occurring or to be corrected with certain ability after the error occurs. (The error strength can be completely corrected within a certain range; if it exceeds a certain range, it can only be partially corrected). Extensive in the future (can be said to be omnipresent) In a multimedia communication environment, it is critical that a video delivery mechanism is resilient to fault.
  • FEC Forward Error Correction
  • ARQ Automatic Retransmission Request
  • JSCC Source Channel Joint Coding
  • Interleaving and elimination of bit error spread.
  • FEC Forward Error Correction
  • ARQ Automatic Retransmission Request
  • JSCC Source Channel Joint Coding
  • Interleaving and elimination of bit error spread.
  • FEC Forward Error Correction
  • ARQ Automatic Retransmission Request
  • JSCC Source Channel Joint Coding
  • Interleaving elimination of bit error spread.
  • H.264 video to be transmitted over a packet network FEC is a very practical technique that works well.
  • This method mainly uses a variety of error correction coding to encode the data to be protected, which essentially forms data redundancy, thereby increasing the ability to resist errors.
  • the main error of the packet on the network is the packet loss error, which is called Erasure Error in the error correction coding theory.
  • Error correction codes for deletion errors are a large class called Erasure Codes.
  • the so-called erasure code is to divide the data stream sequence into segments of the same size (Unit), also called data nodes (Data Nodes). For convenience of presentation, it is assumed that there are n data nodes. Then, according to certain mathematical operation rules, these data nodes are calculated to generate a check node (? 1: In order to enhance the protection capability, the check nodes may continue to generate the second layer check node according to the same or different mathematical operation rules, and so on, and the third layer, the fourth layer, and the Nth layer check may be generated. node.
  • Layer node structure It can be visually represented as a pyramid that turns 90 degrees to the right. The leftmost side is the data node layer, and the right side is the first layer check node, the second layer check node, ..., the Nth layer check node.
  • linear time characteristic linear-time I and many other erasure codes such as famous The Reed-Solomon code requires much more time complexity and is on the order of n*log2n*log(logn). Therefore, linear time-based erasure codes are much better used in real-time communication.
  • Tornado code is a kind of one that appeared around 1998. New erasure code. Tornado code is simple in structure and efficient in operation because it has linear time and strong protection. In practical applications, good results have been obtained. It has been widely used. 1" The latest ITU-T dynamics, where SG16 is currently considering the possibility of standardizing Error Control Codes technology, mainly for video and audio network transmission protection. Tornado code and its many variants are very May be an important technology among them.
  • multiple check node layers are generated layer by layer from the data node. Both the check node and the data node are sent by the sender to the receiver over the network. If some nodes are lost during the network transmission process, because the upper node participates in the generation of the lower node, the information of the upper node is already included in the lower node and the lower node, so the information of the lost node can pass the lower level of sufficient majority. The node or lower node is fully recovered. If each node is a packet, the lost packet can be fully recovered by other packets that are correctly received. Let the number of data nodes be n, and the number of generated check nodes is L.
  • Figure 3 shows a typical Tornado code data node and the relationship between the check nodes of each layer.
  • the connection between the nodes in the figure is called the edge, and the node on the left side of the edge participates in the calculation of the right node. It can be seen that there is a many-to-many logical relationship between the two nodes before and after.
  • the most commonly used calculation method in the Tornado code generation process is the XOR operation, because the XOR operation has a convenient recovery function, and any node can be recovered by all the remaining nodes after it is lost. Since the scaling factor of the last layer of check nodes is different, it is generally calculated using a conventional error correction coding scheme, such as a Reed-Solomon code.
  • erasure codes In fact, the range of erasure codes is very large. Tornado codes are only one of them. In addition, there are RS (Reed-Solomon) codes and Low Density Parity Codes (LDPC).
  • RS Random-Solomon
  • LDPC Low Density Parity Codes
  • An important performance indicator of the erasure code is its error correction capability (or protection capability), which is directly reflected in the maximum number of lost packets allowed under the packet loss error (under the total number of precursors of a certain packet), or when The packet loss is higher than this maximum allowable number, and the percentage of the packet can be corrected correctly.
  • the protection is higher and the redundancy is the same under other conditions. The higher the rate.
  • the protection capability is not only applicable to erasure codes, but on a larger scale, all FEC codes can be measured by protection capabilities.
  • some data are relatively important, such as structural parameters of video sequences, structural parameters of images, header information, etc.
  • Other data are relatively less important, such as image content data.
  • FEC FEC
  • a code with stronger protection is used for relatively important data, and a code with weak protection for relatively unimportant data. This balances protection and efficiency.
  • the protection capability cannot be adjusted blindly because it leads to high redundancy and the P-bar is inefficient.
  • This method of FEC protection based on the relative importance of data for different protection capabilities is called Unequal Protection (UEP), and QoS guarantee for video communication services is easily realized by unequal protection.
  • the RTP protocol for transmitting video multimedia data does not support fault-tolerant flexibility and is provided by a higher application layer.
  • the erasure code protection is generally used to achieve elastic fault tolerance.
  • the measures taken by the prior art scheme are: - The sender is at the NALU level of H.264, and directly uses some type of erasure code for the NALU data unit, and then the result (including the data node and the checksum) The node) is directly encapsulated in the RTP packet and then transmitted.
  • the receiving end After receiving the RTP data packet, the receiving end performs decapsulation to extract the data node and the check node. If packet loss occurs, that is, some or some RTP data packets are lost, then according to which data nodes are encapsulated in the lost packets. Or verifying the node, it can be judged whether the correctly received data node and the check node can be used to completely recover or partially recover the lost node, and the recovery operation is performed.
  • the prior art performs erasure coding on the multimedia data such as NALU at the upper layer and then transmits the data in the RTP, and performs corresponding erasure decoding on the receiving end.
  • the transmitting and receiving parties generally negotiate and decide what forward error correction coding scheme to use and the parameter settings adopted by the scheme, such as H.323/H.245 and other protocol channels.
  • the two sides negotiated.
  • the fault-tolerant and flexible mechanisms in the prior art solutions are implemented at the upper layer of the RTP.
  • the two parties negotiate or inform the type of the erasure code to be used and its parameter settings need to be implemented through other logical channels, which seriously affects the multimedia transmission efficiency.
  • the network bandwidth resource is consumed.
  • the fault-tolerant resiliency mechanism is transparent. Therefore, the RTP layer cannot know the structure of the encoded multimedia data generated by the FEC codec scheme, and thus cannot perform targeted encapsulation and encapsulation. , unable to reorganize the transport hierarchy, lengthen network transmission delays, and the transmission equipment becomes complicated;
  • the multimedia data is always transmitted according to the scheme.
  • the unequal protection mechanism cannot be implemented, and the fault-tolerant elastic mechanism cannot be implemented. To achieve QoS guarantee.
  • the prior art implements a fault-tolerant elastic mechanism such as FEC at a high level, and does not utilize the RTP protocol and its encapsulation. Therefore, the transmitting and receiving parties need to establish another logical channel or use a specific application layer protocol, such as some in the H.323 protocol system.
  • Protocol H.245 to negotiate or inform the FEC encoding type, structural parameters and other information used; no fault-tolerant resiliency related details are involved in the RTP layer, and no RTP data packet is encapsulated to encapsulate the data nodes and check nodes generated by FEC protection; There is also no choice of FEC codec scheme according to the network condition and the importance of multimedia data, and there is no mechanism for providing FEC protection for different protection capabilities with different relative importance data, that is, unequal protection cannot be achieved. Summary of the invention
  • the main purpose of the present invention is to provide a real-time transmission method for a multimedia data network that supports fault-tolerant resilience, so that a fault-tolerant elastic mechanism for real-time transmission of multimedia data can be implemented at a transmission protocol level.
  • U of the present invention is implemented for Unequal protection mechanisms and hierarchical protection mechanisms for different data and network conditions.
  • a real-time transmission method for a multimedia data network supporting fault tolerance resilience includes:
  • the transmitting end selects a forward error correction coding mode to perform forward error correction coding on the multimedia data
  • the transmitting end encapsulates the encoded multimedia data by using a fault-tolerant elastic real-time transmission protocol, and And carrying the forward error correction coding mode related information in the header information of the fault tolerant elastic real-time transmission protocol data packet, and sending the information to the receiving end;
  • the receiving end decapsulates the received fault-tolerant elastic real-time transport protocol data packet, and extracts the forward error correction coding mode related information from the header information of the fault-tolerant elastic real-time transport protocol data packet;
  • the receiving end selects the forward error correction decoding mode to perform forward error correction decoding according to the forward error correction coding mode related information, Restoring or partially recovering the lost multimedia data.
  • the forward error correction encoded multimedia data includes a data node and a check node.
  • the transmitting end selects a forward error correction coding mode according to a current network transmission condition or/and a service quality level of the multimedia data to be transmitted, wherein the service volume level is determined according to the relative importance of the data.
  • the packet fault information of the fault tolerant elastic real-time transport protocol includes:
  • a forward error correction coding type field configured to indicate a forward error correction code type used
  • a forward error correction coding subtype field configured to indicate a related parameter setting of the forward error correction coding mode
  • a packet length field configured to indicate a length of a node obtained after correcting the forward error correction code for the multimedia data
  • a packet number field used to indicate the number of the data nodes carried by the fault tolerant elastic real-time transport protocol data packet.
  • the transmitting end divides at least one of the H.264 network abstraction layer units into at least one data node of equal length, and then performs the foregoing. Encoding to the error correction to obtain at least one calibration node; the transmitting end encapsulates the data node and the verification node packet in at least one of the fault tolerant elastic real-time transmission protocol packets for transmission;
  • the receiving end After receiving the fault tolerant elastic real-time transport protocol packet, the receiving end decapsulates the data node and the check node;
  • the receiving end is according to the school
  • the node performs forward error correction decoding on the data node, and divides and obtains the H.264 network abstraction layer unit.
  • the transmitting end and the receiving end negotiate to determine the value of the fault tolerant forward error correction code subtype field and the related parameter setting of the forward error correction code indicated. Correspondence relationship.
  • the sending end and the receiving end both establish a correspondence table according to the indication correspondence relationship of the forward error correction coding subtype field, and configured to perform, according to the forward error correction coding type field and the forward error correction coding
  • the forward type error correction coding or forward error correction decoding processing module corresponding to the subtype field query;
  • the transmitting end invokes a corresponding forward error correction coding processing module to perform forward error correction coding; the receiving end invokes a corresponding forward error correction decoding processing module to perform forward error correction decoding. Determining, by the sending end, the relative importance of the corresponding data according to the network abstraction layer reference identifier field or/and the network abstraction layer unit type field in the header information of the H.264 network abstraction layer unit, determining the quality of service level, selecting Corresponding forward error correction coding mode determines the forward error correction coding type field and the forward error correction coding subtype field.
  • the transmitting end evaluates the network transmission status according to the transmission report fed back by the receiving end, and further selects the forward error correction coding mode, and determines the forward error correction coding type field and the forward error correction coding subtype field. .
  • the forward error correction coding type field is located after the contribution source identifier list; the forward error correction coding subtype field is located after the forward error correction coding type field;
  • the data packet length field is located after the forward error correction coding subtype field; the data packet number field is located after the data packet length field.
  • the forward error correction coding mode uses an improved "Tornado" erasure code; the improved “Tornado” erasure code generates only one layer of the check node for a set of said data nodes.
  • an ER TP transmission that can carry information related to the forward error correction coding scheme is provided on the basis of the existing RTP. Sending a layer encapsulation format, so that the multimedia data is transmitted on the ERRTP while marking its corresponding forward error correction coding scheme information, thereby integrating the error resilience mechanism into the transport layer;
  • various alternate forward error correction coding schemes can be selected according to factors such as current network conditions and multimedia data importance levels, thereby achieving the purpose of unequal protection and hierarchical protection, achieving protection capability and transmission. Balance of efficiency;
  • the fault-tolerant elastic mechanism in the transport layer greatly simplifies the fault-tolerant elastic transmission structure, which saves the network transmission bandwidth.
  • the realization of the unequal protection achieves the balance between protection capability and transmission efficiency, facilitating the realization of QoS guarantee for multimedia transmission; H.264 data
  • the implementation of the specific transmission scheme can greatly improve the performance and user satisfaction of H.264-based multimedia communication products such as conference television, videophone application on IP networks.
  • 1 is a schematic diagram of a package format of an RTP packet payload to NALU data
  • FIG. 2 is a schematic diagram showing the structure of a header information of an RTP data packet
  • Figure 3 is a schematic diagram of the Tornado erasure code principle
  • FIG. 4 is a schematic structural diagram of an EERTP packet header according to a first embodiment of the present invention
  • FIG. 5 is a flow chart of a H.264 multimedia data transmission method according to a second embodiment of the present invention.
  • FIG. 6 is a schematic diagram of a H.264 NALU partitioning codec process according to a second embodiment of the present invention. detailed description
  • the present invention proposes an improved RTP protocol supporting fault tolerance resilience, which aims to integrate a fault-tolerant elastic mechanism into a transport layer protocol, which not only simplifies the transmission structure and reduces complexity, but also improves the fault-tolerant elastic mechanism. Flexibility enhances transmission reliability. Due to its fault-tolerant flexibility, this improved RTP protocol is called a fault-tolerant elastic real-time transport protocol. ( ERRTP /ER2TP, Error Resilience Real-time Transport Protocol ).
  • ERRTP /ER2TP Error Resilience Real-time Transport Protocol
  • the main difference between ERRTP and RTP is that the ERTP protocol packet header information extension can carry information about the forward error correction codec scheme, such as FEC type, protection capability, and coding parameters.
  • the present invention conveniently realizes unequal protection. Firstly, various protection measures with different protection capabilities are available for selection, and then the sender can collect information such as network status and importance of multimedia data. These factors are used to select appropriate protection measures to achieve the goal of unequal protection and to achieve a balance between protection capability and transmission efficiency. Since the FEC related information is carried on each ERRTP data packet, the transmitting end only needs to fill in the information of the selected scheme into the ERRTP header information, and the receiving end can correctly recover or correct the error according to it. .
  • the specific implementation method based on erasure code protection is given, including the steps of dividing, generating, encapsulating and decapsulating the data node and the check node.
  • a series of NALUs are equally divided into several data nodes, and then the check nodes are generated by Tornado codes. All of these nodes are distributed in several ERRTP packets, and the receiving end performs this inverse process.
  • the format of the RTP packet is briefly introduced:
  • the basic option of the RTP header information occupies 12 bytes (minimum case), and the header information of the IP protocol and the UDP protocol respectively occupy 20 bytes and 8 words. Therefore, the RTP packet is encapsulated in the UDP packet and then encapsulated in the IP packet.
  • the detailed structure of the header information of the RTP packet is shown in Figure 2.
  • the front-to-back RTP header information shown in Figure 2 is:
  • the first byte (byte 0) is some field about the header information structure itself
  • the second byte (byte 1) is the defined payload type
  • the third 4 bytes (bytes 2, 3) are the sequence number (Sequence Number)
  • the 5th-8th byte is the timestamp (timestamp)
  • the 9th-12th byte is the synchronous contribution source identifier (SSRC ID, Synchronous Source) Identifier )
  • SSRC ID Synchronous Source
  • CSRC Ids Contributing Source Identifiers
  • the first 12 bytes appear in all different types of RTP packets, while other data in the header information, such as the contribution source identifier, is only available when the mixer is inserted. therefore CSRC is generally used when there is media mixing. For example, in multi-party conferences, audio needs to be mixed, and video can also provide multi-screen functions in this way.
  • the synchronization source identifier SSRC is actually the identifier of the carried media stream.
  • the P field is a padding flag (Padding), which occupies 1 bit. If P is set, it indicates that the packet contains one or more padding bytes (Padding) at the end, and the padding is not part of the payload;
  • the X field is an extension identification bit (Extension), which occupies 1 bit. If X is set, the RTP header must be followed by a variable-length header extension (if there is a CSRC list, the header extension is followed), mainly Retaining the case where the header information field is not sufficient for some application environments, the header extension includes a 16-bit length field to count how many 32-bit words in the extension, and the first 16 bits of the header extension are left-open. In order to distinguish between identifiers and parameters, the 16-bit format is defined by a specific level specification, which is described in detail in section 5.3.1 of RFC 3550, which is not given here;
  • the CC field is the number of contributing sources (CSRC Count), which is 4 bits s, indicating the number of CSRC identifiers at the end of the header information, and the receiving CC field can determine the length of the CSRC IDs list following the header information;
  • the M field is a marker bit (Marker), which occupies 1 bit.
  • the interpretation of the identifier bit is defined in a specific profile, which allows identification of important events in the packet stream.
  • One layer can define additional identification bits or regulations. There is no identification bit.
  • the so-called level here refers to the specific application environment setting, which is specifically agreed by the communication parties and is not limited by the agreement;
  • the PT field is the payload type (PT, Payload Type), a total of 7 bits s, identifies the format of the RTP payload and determines his interpretation in the application; the flag bit and the payload type share a layer of specified information, this byte may It will be redefined by specific levels to suit different needs.
  • a so-called profile can be defined, which is actually a set of static (ie communication). The two parties agree on the corresponding relationship in advance, and the different values of the FT bits are associated with different media formats.
  • dynamic negotiation can also be used to define the relationship between the FT value and the media format through signaling other than RTP.
  • the RTP source can change the PT.
  • the following field is the serial number of a total of 16 bits. Each time an RTP data packet is sent, the serial number value is incremented by one, so that the receiver can use it to detect the data packet loss and recover the data packet sequence.
  • the initial value of the serial number in one communication can be given randomly. , does not affect communication.
  • the timestamp occupies 32 bits, which reflects the sampling time of the first byte in the RTP packet.
  • the sampling time here must be derived from a monotonically increasing clock, and the receiver adjusts the media playback time or synchronizes according to it.
  • the synchronization source SSRC ID occupies 32 bits, and its specific value can be randomly selected. However, to ensure the uniqueness in the same RTP session, it can uniquely identify a media source. If a source changes the source transmission address, a new SSRC must be selected. The identifier.
  • the source CSRC list can be 0-15 items as needed, each item occupying 32 bits s, and the length of the list, ie the number of CSRC IDs, is exactly indicated by 4 bits of the CC field.
  • the CSRC identifier used to identify a media source is identical to the SSRC identifier of its corresponding contribution source, except that the role of the different receivers is different and is set to SSRC or CSRC.
  • the CSRC ID is inserted by the mixer.
  • the sending and receiving parties implement unequal protection based on ER TP.
  • the main steps are as follows:
  • the transmitting end selects the forward error correction coding scheme to perform erasure coding on the multimedia data, encapsulates the encoded multimedia data with ER TP, and carries relevant information of the forward error correction coding scheme in the ER TP header information, and then sends the information to the receiving end;
  • the receiving end encapsulates the received ERRTP packet, and extracts the relevant information of the forward error correction coding scheme from the ERRTP header information, and then selects the forward error correction coding scheme to perform the erasure decoding and decoding according to the related information of the forward error correction coding scheme. Get multimedia data.
  • the unequal protection is reflected in that the sending end selects the forward error correction coding scheme according to the current network transmission status and/or the quality of service level of the multimedia data to be transmitted.
  • the specific structure of ERRTP is introduced.
  • the following is an example of the structure of the header information of the specific ERRTP.
  • 4 is a block diagram showing the structure of an ERRTP header according to a first embodiment of the present invention.
  • the header information extension is finally accompanied by a related information field regarding the forward error correction codec scheme, and the example includes: a forward error correction coding type field, a forward error correction coding parameter field, a packet length field, and data.
  • the number of packages field is a packet length of the packet length field.
  • the forward error correction coding type field is used to indicate the erasure code type used by the forward error correction coding scheme, and may also be referred to as an FEC Type field, that is, an FEC coding type, which is 4 bits, and can represent 16 different FEC types. , from the actual application, is enough.
  • the types defined here are actually large types, and will be further subdivided into various schemes, called subtypes.
  • the large types in practical applications are, for example, 0010 for Tornado code and 0011 for RS code.
  • This field can identify 16 different types of FEC codes.
  • the query table (LUT, Look-Up Table), which needs to agree in advance on the correspondence between the FEC encoding type and the encoding type code, is called FECTypeLUT.
  • the forward error correction coding subtype field is used to indicate the related parameter setting of the forward error correction coding scheme. For each type of FEC coding, it is also necessary to determine the setting of various parameters to be specifically implemented, and this field is to clear specific parameters. The role. Since the resources in the ERRTP header information are limited, it is impossible to list specific parameters corresponding to various FEC encoding schemes, their rules, etc., and the first embodiment of the present invention indicates various alternative parameters by using the concept of subtypes. Set the plan.
  • This field is also known as the FEC coded subtype field, FEC Subtype, which occupies 9 bits. This field mainly represents the subtypes further subdivided under the major types defined in the FECTypeLUT.
  • MTU Maximum Transport Unit
  • the number of packets field used to indicate the number of data nodes carried by the ERRTP packet, also known as the Packet Number field, which occupies 8 bits, for example, before a number of NALUs pass through
  • the packet is encapsulated in multiple ERRTPs, and the number of data nodes carried in each ERRTP.
  • the decoding end or the network node can verify the received data packet according to the FEC code type and the check type of the data packet given by the field, and recover the lost data packet.
  • sub-type FEC Subtype field mentioned above has a total of 9 bits for encoding a parameter setting scheme indicating various alternatives, and how to perform the coding indication in the first embodiment of the present invention is given below. technical details.
  • the receiving and receiving party needs to negotiate to determine the field indicating the relationship correspondence table.
  • the sender and the receiver negotiate to determine: for various types of FEC codes, the correspondence between the value of the FEC Subtype and the related parameter setting scheme of the FEC code indicated, and various alternatives. Specific parameter settings.
  • the sender and the receiver both establish a correspondence table according to the negotiation result, and are configured to query the corresponding FEC coding type or FEC codec processing module according to the FEC Type and FEC Subtype fields;
  • the transmitting end calls the corresponding erasure coding processing module to perform erasure coding
  • the receiving end calls the corresponding erasure decoding processing module to perform erasure decoding.
  • the so-called generation rule is a rule or algorithm (Algorithm) of how the data node is processed at the transmitting end to generate each check node. Of course, the opposite is done at the receiving end. If a packet loss occurs during the transmission, that is, some nodes are lost, the lost node can be recovered or partially recovered according to the generation rule. It can be seen that the generation rule is very important information, according to which both parties of the communication can work based on the FEC mechanism.
  • Each of the FEC types listed in the FECTypeLUT has different generation rules; in each class, such as Tornado code, the following subclass generation rules are combined with specific generation parameters. . So for each subclass here, the claim rule will be combined with the build parameters.
  • the generation parameters include the following data: According to the total number of nodes, the total number of check nodes, the number of check node layers, the scaling ratio of the number of power saves between successive layers, and the association of node associations between successive two layers.
  • Matrix if there is an L-layer check node, then such an associative matrix has L or equivalent bipartite graphs representing the relationship between successive two-layer nodes.
  • the generation is performed. The parameters often determine the protection strength of the subtype.
  • Tornado code in the various generation parameters given above, the total number of data nodes and the total number of test nodes can basically determine the protection ability to a large extent (of course, strictly speaking, to fully determine the protection capability, all the generation parameters are required. ).
  • the representative generation parameters representative generation parameters
  • FECSubTypeLUT For example, Tornado code, in the various generation parameters given above, the total number of data nodes and the total number of test nodes can basically determine the protection ability to a large extent (of course, strictly speaking, to fully determine the protection capability, all the generation parameters are required. ).
  • select some of the main parameters determining the protection capability the decision is the most important
  • the representative generation parameters representative generation parameters
  • Subclasses are arranged in order of protection from weak to strong (ascending order).
  • creating a LUT is called FECSubTypeLUT.
  • Each large type specifically supports multiple subtypes below, and can have specific application and communication capabilities (CPU processing speed, memory, program complexity, etc.) and needs to be determined. If the communication environment changes a lot and the performance of the network fluctuates widely, then the subtypes that need to be supported are generally more, but less. This can be agreed upon by the communication parties through the capability negotiation process before the communication begins. Negotiation can be carried out through the current mainstream multimedia communication framework protocols such as H.323 or Session Initial Protocol (SIP).
  • H.323 Session Initial Protocol
  • a given set of generation rules combined with corresponding generation parameters corresponds to a unique coding scheme, that is, the only decision is how to generate a calibration node from the data node, and how to recover the lost node.
  • a database can be created to store the generation parameters for each of the large types and subtypes.
  • the generation rules themselves are implemented in hardware or software modules. Therefore, each type of macro corresponds to a FEC processing module at the transmitting end, which is responsible for generating a check node; at the receiving end, it also corresponds to an FEC processing module, which is responsible for restoring the node.
  • each large type of module it is necessary to read the specific generation parameters of each seed type from the above generated parameter database, thereby performing processing. Therefore, both parties are based on
  • the information of the two information fields FEC Type and FEC Subtype determines which FEC processing module is called and reads those generation parameters.
  • the second embodiment of the present invention gives the NALU of H.264 with ERRTP.
  • Step 501 The sender combines multiple (assumed S) H.264 NALUs into a unified group of coded transmissions, and first re-divides the S NALUs into blocks of equal length, which are assumed to be M, and the M are data. node.
  • the S NALUs of H.264 are grouped into one group; then the S NALUs are concatenated end-to-end, connected to form a large block, and then the large block is equally divided into M data blocks, wherein Each data block has a length of K bytes.
  • the rounding operation should be performed so that the length of each data block is Ceiling (TBZM) bytes, and the Ceiling function indicates rounding, that is, Ceiling(x) is equal to no
  • the smallest integer less than x, x is any real number.
  • the operation of zero padding may be used, so that the number of bytes is equal to Ceiling (TB/M).
  • Step 502 Perform FEC encoding on the M data nodes to obtain N check nodes.
  • FEC code encoding for M data blocks to generate N check blocks the generation process uses the method described above to determine which FEC processing module to call for the generation of the check block according to the FEC Type and FEC Subtype information.
  • Step 503 The sender encapsulates all data nodes and check node packets in an ERRTP packet for transmission.
  • Figure 6 shows the structure of P + ER TP packages carrying M + N data nodes. Combined with the header information format of ERRTP given in Figure 4, in this example the fields should be set as follows:
  • Type field FEC Type 0010, indicating the use of Tornado code
  • the channel coding redundancy is 16.7%; the erasure code can completely recover the lost data packet when the packet loss rate is less than or equal to 3%;
  • Packet Number Packet Number (M+N)/P, which represents the number of data nodes carried in an ERRTP payload.
  • Step 504 After receiving the ERRTP packets, the receiving end encapsulates the data node and the check node. The receiving end starts with P packets and starts decoding and recovering every time a group of P packets is received. How many packets of a group are determined by mutual agreement.
  • Step 505 The receiving end performs forward error correction decoding on the data node according to the check node. Each time after receiving the data packet P+1, it starts to detect whether there is a packet loss in the P packets received before. If there is, the method described above is used to determine which FEC to call according to the FEC Type and FEC Subtype information. The processing module decodes and recovers or partially loses data.
  • Step 506 finally, after obtaining the complete data node, re-merging to obtain a large block, and dividing the S NALUs in the same manner as the transmitting end.
  • the above example uses the ERRTP-based anti-data packet loss algorithm, which can greatly improve the anti-data packet loss of the video code stream when the number of codewords is less than 17%. Force. Compared with the RTP payload header structure, only 4 bytes have been added, which shows that there is basically no effect on the transmission efficiency, and significant practical results have been achieved.
  • Another key technical point that has been mentioned above with respect to the present invention is the implementation of unequal protection. It is mainly embodied in two aspects. One is to select the appropriate codec scheme or parameters according to the multimedia data of different important levels, that is, to determine the aforementioned FEC coding type and subtype, and the other is to select according to the network conditions at different times. Corresponding to these two aspects, they are called mixed and alternate use of various FEC coding schemes. Hybrid refers to the simultaneous use of multiple FEC subtypes at the same time, mainly for protecting data of different importance. The so-called Alternation refers to the use at different times (different network conditions). Different FEC subtypes.
  • these two unequal protection mechanisms are given based on the first embodiment.
  • its first byte reflects the importance of the data, so the sender can evaluate the QoS level according to the NRI field or Type field in the NALU header information, and then select the forward error correction.
  • the coding scheme that is, the FEC Type field and the FEC Subtype field are determined.
  • the general network transmission has a corresponding network condition monitoring mechanism, and the transmitting end can learn the transmission report fed back by the receiving end according to these mechanisms, so as to evaluate the network transmission status, and then select the forward error correction coding scheme, that is, Determine the FEC Type field and the FEC Subtype field.
  • the H.264 code stream is transmitted or stored based on the NALU, which consists of NAL header information and NAL payload.
  • NALU which consists of NAL header information and NAL payload.
  • different NALU types have different effects on decoding and restoring images.
  • a NRI of 0 means that a Slice or Slice data strip of a non-reference image in the NALU does not affect subsequent decoding; and a non-zero indicates that a sequence/image parameter set or a slice of the reference image is stored in the NALU or Slice data strips can seriously affect subsequent decoding.
  • Nal_unit_type divides the data of H.264 into two categories: one is relatively important image data (for example, Nal_ref-idc is equal to 1); the other is secondary image data (for example, Nal). — ref— idc is equal to 0). Then, the important image data is protected by the FECI code with high redundancy and strong anti-dropping ability; while the secondary image data can be used with less redundancy and weaker anti-loss capability. The FEC2 code is protected.
  • FEC1, FEC2 are just general representations, representing any two seed types. These two seed types can belong to the same large type, or they can belong to different large types.
  • the above method can be extended to a more general case, and the data is divided into more classes according to the value of NAL_unit-type, such as five categories: the most important data, the second most important data, the general important data, the less important data, The least important data; can also be divided into 7 categories or more, then, can be protected with the same number of FEC subtypes, each type of data corresponds to a different subtype. As long as the protection ability is weak to strong, these subtypes do not necessarily belong to the same large type.
  • the image information that has not been recovered after the protection of the most protected FEC code is protected by error concealment and error-proof diffusion.
  • Another case of unequal protection according to the present invention is the ability to select FECs of different protection capabilities depending on the real-time conditions of the network.
  • the two sides of the communication are then notified by the header information of ERRTP so that they can correctly decode the data and recover the lost data.
  • the image information that has not been recovered after the protection of the FEC code with the strongest protection is protected by error concealment and error-preventing. Network conditions can be monitored through various existing QoS monitoring methods.
  • the subscript of the middle FEC is represented by a two-dimensional subscript.
  • the fault-tolerant elastic mechanism FEC(i,j) in the table, 0 ⁇ i ⁇ U, 0 ⁇ j ⁇ V, may be any of the above T FEC schemes. .
  • an improved Tornado erasure code is specifically employed.
  • the improved Tornado erasure code generates only one layer of the check node for a group of data nodes, which can greatly reduce coding. Delay, to meet the needs of real-time communication.
  • NALUs are grouped into one group, and one NALU contains the code stream data of a Slice. If a frame of image is divided into a slice, the encoding end will have the delay of the S frame, and the decoding end will also have the delay of the S frame.
  • the relationship between NALU and the number of data nodes is as follows:
  • the delay of the delay of one frame is basically determined by the value of S. Determine, and the DataNode greatly affects the value of s. Therefore, under the premise of ensuring the ability of video communication to resist packet loss, the delay introduced by FEC is minimized, and the QoS of real-time video communication is further ensured.
  • the present invention employs an improved Tornado code protection algorithm in the case where the DataNode is limited.
  • the improved Tornado method does not use a multi-level even graph coding method, but uses only one layer of check node coding.
  • the improved coding method greatly improves the flexibility of the algorithm.
  • the number of data nodes and check nodes can be set arbitrarily, and the complexity of the codec algorithm is also reduced. It can be used for real-time video communication. Anti-packet loss.
  • the improved anti-data packet loss performance of the Tornado code is basically not reduced in the case where the data node is limited.
  • the specific principle and detailed steps of the improved Tornado coding method are described in Chinese Patent Application No. 200510066146.7, entitled "A Data Transmission Protection Method Based on Erasure Code".

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

La présente invention concerne un procédé de prise en charge de transmission de données multimédias avec tolérance aux erreurs, où il est possible de réaliser le mécanisme de tolérance aux erreurs de la transmission en temps réel des données multimédias sur la couche de protocole de transmission. La présente invention commence par procurer une transmission en temps réel de données multimédias en exposant le protocole ERRTP qui transporte des informations relatives au procédé de codage de la correction d’erreur en avance (FEC) au protocole RTP existant, de manière à pouvoir marquer les informations concernant le procédé de codage FEC correspondant pour les données multimédias pendant qu’elles sont transmises sur ERRTP, ce qui permet d’introduire le mécanisme de tolérance aux erreurs dans la couche de transmission. Ensuite, il est possible de sélectionner chaque procédé de codage FEC en attente en fonction de l’état actuel du réseau et du niveau d’importance des données multimédias à l’extrémité émettrice, de telle manière que la présente invention peut atteindre l’objectif de protection basée sur le niveau et réaliser un équilibre entre la capacité de protection et l’efficacité de transmission.
PCT/CN2006/001846 2005-10-17 2006-07-25 Procede de prise en charge de transmission de donnees multimedias avec tolerance aux erreurs WO2007045141A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB2005101139402A CN100450187C (zh) 2005-10-17 2005-10-17 支持错误弹性的多媒体数据网络实时传送方法
CN200510113940.2 2005-10-17

Publications (1)

Publication Number Publication Date
WO2007045141A1 true WO2007045141A1 (fr) 2007-04-26

Family

ID=37298434

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/001846 WO2007045141A1 (fr) 2005-10-17 2006-07-25 Procede de prise en charge de transmission de donnees multimedias avec tolerance aux erreurs

Country Status (2)

Country Link
CN (1) CN100450187C (fr)
WO (1) WO2007045141A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109245850A (zh) * 2017-07-11 2019-01-18 上海交通大学 基于媒体内容的自适应系统码fec编译码方法
WO2021180065A1 (fr) * 2020-03-09 2021-09-16 华为技术有限公司 Procédé de transmission de données et appareil de communication
CN113541853A (zh) * 2020-04-13 2021-10-22 海能达通信股份有限公司 数据传输方法、终端及计算机可读存储介质
CN115189810A (zh) * 2022-07-07 2022-10-14 福州大学 一种面向低时延实时视频fec编码传输控制方法

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101193060B (zh) * 2006-12-01 2010-09-01 武汉烽火网络有限责任公司 在分组网上采用前向纠错机制实现可靠的e1传送的方法
US8990663B2 (en) * 2006-12-21 2015-03-24 Thomson Licensing Method to support forward error correction for real-time audio and video data over internet protocol networks
US8570869B2 (en) * 2007-09-21 2013-10-29 Nokia Corporation Scalable error detection and cross-session timing synchronization for packet-switched transmission
CN101616139A (zh) * 2008-06-24 2009-12-30 华为技术有限公司 下一代网络中传输多媒体业务的方法、系统、及装置
CN101594206A (zh) * 2009-06-23 2009-12-02 中兴通讯股份有限公司 前向纠错编解码模式的同步方法及装置
KR101660554B1 (ko) * 2009-11-13 2016-09-27 파나소닉 인텔렉츄얼 프로퍼티 코포레이션 오브 아메리카 부호화 방법, 복호 방법, 부호화기 및 복호기
CN101778295B (zh) * 2009-12-25 2012-11-14 中兴通讯股份有限公司 一种视频监控系统及其前向纠错的方法
CN102595252B (zh) * 2011-01-11 2016-09-28 中兴通讯股份有限公司 流媒体前向纠错实现方法及系统
PL3522541T3 (pl) 2011-01-19 2021-08-30 Samsung Electronics Co., Ltd. Urządzenie i sposób odbierania komunikatu sterowania w systemie rozgłoszeniowym
KR101933465B1 (ko) * 2011-10-13 2019-01-11 삼성전자주식회사 이동 통신 시스템에서 패킷 송수신 장치 및 방법
CN103532923B (zh) * 2012-11-14 2016-07-13 Tcl集团股份有限公司 一种实时媒体流传输方法及系统
CN103354615B (zh) * 2013-06-24 2015-04-15 西安交通大学 基于信号强度的直播视频数据传输差错控制方法
CN105337682B (zh) * 2014-05-26 2018-10-12 联想(北京)有限公司 一种传输数据的方法及装置
CN107294631A (zh) * 2016-03-30 2017-10-24 北京数码视讯科技股份有限公司 一种激励器的信号处理方法及激励器
CN110299963A (zh) * 2019-06-05 2019-10-01 西安万像电子科技有限公司 数据处理方法及装置
CN112699145B (zh) * 2019-10-23 2024-05-03 苏州华兴源创科技股份有限公司 一种数据处理系统
CN114866195A (zh) * 2022-07-07 2022-08-05 深圳市江元科技(集团)有限公司 一种使用安卓系统控制热敏打印机的方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000187441A (ja) * 1997-12-08 2000-07-04 Nippon Telegr & Teleph Corp <Ntt> 埋め込み情報符号化方法及び装置及び埋め込み情報符号化プログラムを格納した記憶媒体及び抽出情報復号化方法及び装置及び抽出情報復号化プログラムを格納した記憶媒体及び電子透かし情報符号化方法及び装置及び電子透かし情報符号化プログラムを格納した記憶媒体及び電子透かし情報復号方法及び装置及び電子透かし情報復号プログラムを格納した記憶媒体
CN1353895A (zh) * 1999-04-01 2002-06-12 诺基亚移动电话有限公司 用于数字数据传送的方法与设备
US6665420B1 (en) * 1999-12-02 2003-12-16 Verizon Laboratories Inc. Message authentication code with improved error tolerance
CN1479489A (zh) * 2002-08-29 2004-03-03 ����ͨѶ�ɷ����޹�˾ 一种在综合业务数字网上传输宽带多媒体数据的方法
CN1571512A (zh) * 2004-04-30 2005-01-26 清华大学 面向移动终端的多媒体广播系统及其实现方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6349138B1 (en) * 1996-06-14 2002-02-19 Lucent Technologies Inc. Method and apparatus for digital transmission incorporating scrambling and forward error correction while preventing bit error spreading associated with descrambling
JP2005524281A (ja) * 2002-04-25 2005-08-11 パッセイヴ リミテッド イーサネット（登録商標）ネットワークにおける前方誤り訂正コーディング

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000187441A (ja) * 1997-12-08 2000-07-04 Nippon Telegr & Teleph Corp <Ntt> 埋め込み情報符号化方法及び装置及び埋め込み情報符号化プログラムを格納した記憶媒体及び抽出情報復号化方法及び装置及び抽出情報復号化プログラムを格納した記憶媒体及び電子透かし情報符号化方法及び装置及び電子透かし情報符号化プログラムを格納した記憶媒体及び電子透かし情報復号方法及び装置及び電子透かし情報復号プログラムを格納した記憶媒体
CN1353895A (zh) * 1999-04-01 2002-06-12 诺基亚移动电话有限公司 用于数字数据传送的方法与设备
US6665420B1 (en) * 1999-12-02 2003-12-16 Verizon Laboratories Inc. Message authentication code with improved error tolerance
CN1479489A (zh) * 2002-08-29 2004-03-03 ����ͨѶ�ɷ����޹�˾ 一种在综合业务数字网上传输宽带多媒体数据的方法
CN1571512A (zh) * 2004-04-30 2005-01-26 清华大学 面向移动终端的多媒体广播系统及其实现方法

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109245850A (zh) * 2017-07-11 2019-01-18 上海交通大学 基于媒体内容的自适应系统码fec编译码方法
CN109245850B (zh) * 2017-07-11 2021-04-02 上海交通大学 基于媒体内容的自适应系统码fec编译码方法
WO2021180065A1 (fr) * 2020-03-09 2021-09-16 华为技术有限公司 Procédé de transmission de données et appareil de communication
US12003322B2 (en) 2020-03-09 2024-06-04 Huawei Technologies Co., Ltd. Data transmission method and communication apparatus
CN113541853A (zh) * 2020-04-13 2021-10-22 海能达通信股份有限公司 数据传输方法、终端及计算机可读存储介质
CN113541853B (zh) * 2020-04-13 2022-12-16 海能达通信股份有限公司 数据传输方法、终端及计算机可读存储介质
CN115189810A (zh) * 2022-07-07 2022-10-14 福州大学 一种面向低时延实时视频fec编码传输控制方法
CN115189810B (zh) * 2022-07-07 2024-04-16 福州大学 一种面向低时延实时视频fec编码传输控制方法

Also Published As

Publication number Publication date
CN100450187C (zh) 2009-01-07
CN1859580A (zh) 2006-11-08

Similar Documents

Publication Publication Date Title
WO2007045141A1 (fr) Procede de prise en charge de transmission de donnees multimedias avec tolerance aux erreurs
Wang et al. RTP payload format for H. 264 video
Wenger et al. RTP payload format for H. 264 video
WO2007051425A1 (fr) Procede de communication multimedia et terminal de celui-ci
Turletti et al. RTP payload format for H. 261 video streams
EP1936868B1 (fr) Méthode pour surveiller une qualité de service dans une communication multimédia
Li RTP payload format for generic forward error correction
US20090103635A1 (en) System and method of unequal error protection with hybrid arq/fec for video streaming over wireless local area networks
CN101867453B (zh) 一种rtp抗丢包的方法
WO2007045140A1 (fr) Methode en temps reel pour transferer des donnees multimedia
BRPI0608977A2 (pt) métodos e equipamento para empacotamento de conteúdo para transmissão através de uma rede
WO2006105713A1 (fr) Procede de protection d&#39;emission video fonde sur la technologie h.264
US20060190593A1 (en) Signaling buffer parameters indicative of receiver buffer architecture
JP2001045098A (ja) データ通信システム、データ通信装置、データ通信方法及び記憶媒体
WO2013098810A1 (fr) Système et procédé de correction d&#39;erreur sans voie de retour (fec) adaptatif
KR102163338B1 (ko) 방송 및 통신 시스템에서 패킷 송수신 장치 및 방법
JP2018505597A (ja) メディアコンテンツに基づくｆｅｃメカニズム
Wenger et al. RFC 3984: RTP payload format for H. 264 video
US20150006991A1 (en) Graceful degradation-forward error correction method and apparatus for performing same
KR101953580B1 (ko) 영상회의 시스템에서 데이터 송수신 장치 및 방법
Frescura et al. JPEG2000 and MJPEG2000 transmission in 802.11 wireless local area networks
Monteiro et al. Robust multipoint and multi-layered transmission of H. 264/SVC with Raptor codes
Wang et al. RFC 6184: RTP Payload Format for H. 264 Video
Fonnes Reducing packet loss in real-time wireless multicast video streams with forward error correction
Chung-How et al. Loss resilient H. 263+ video over the Internet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06761576

Country of ref document: EP

Kind code of ref document: A1