RTP and RTCP explanations. With synchronous timestamp

Transferred from: http://blog.csdn.net/wudebao5220150/article/details/13816225

RTP protocol is the abbreviation of real-time transport protocol, is designed to transmit streaming media data, has a wide range of applications, and other related to introduce themselves to see the RFC, I do not intend to discuss these boring conceptual things.

(1) Understanding RTP

It can be said that the RTP protocol does not depend on the underlying protocol, that is, it is an independent protocol. In general, because of the fast, high-speed UDP packet, it is usually combined with UDP, as the upper layer of UDP data transmission form.

typedef struct {
In Out UINT32 timestamp;
In-out BOOL marker;
In Out BYTE payload;

Out UINT32 SSRC;
Out UINT16 SequenceNumber;
out int sByte;
out int len;
} Rtpparam;

This is a RTP head, very simple, and not as complex as you think, right? Let's look at a few main parameters, and they are also the souls of RTP:

(1) payload. Payload indicates that the data for this RTP packet is that type of data, with different values representing different types. such as 0 is pcmu,8 is 723,24 is video 263 and so on.

(2) SSRC, this thing is not used, in fact it is a generated ID that represents an RTP connection. In the application, make sure that the ID is unique.

(3) Sequence number. That is, the serial number, which indicates the current package is the first few packages. Each sender sends a packet and adds one to the value. Acceptance can be used to re-assemble the packet order according to this value, to determine whether the packet is lost or not. Note: It simply indicates the order of the package and it cannot represent any other information on the time. Compare this with the time stamp in the back.

(4) timestamp. Time stamp, its concept is a little bit more complex, I use a little more popular understanding to explain it, although this is a bit incorrect. Time stamp as the name implies, it represents the time a data is generated, like our mailing postmark, it is a time stamp (as for what to do with this time, I will say in detail later), usually indicates the time of the first byte data in the RTP packet, which is how you write the program.

If you understand above, then we went further: in fact, the time stamp increase is not in our usual sense of a microsecond, but increases a sampling interval that long time. For instance. Different acquisition has different sampling frequency, such as General audio is 8K sampling frequency, that is, a millisecond acquisition of 8 data, that is, each sampling interval is 1/8ms, and timestamp increased by 1 also means that a sampling interval is added. That is, after the 1/8ms. In other words, if the sampling frequency of an encoding is 16K, then a timestamp increase of 1 means that the system is 1/16ms. That is, in the same system, the different encoding, although using the same clock, but the growth rate of timestamp is different, in this case, the sampling frequency is 16K encoding is twice times faster than 8K, please remember this difference.

(2) Understanding RTCP

RTCP protocol is real-time Transport Control protocol abbreviation, is designed to do RTP controls, this relatively people do not care, I only introduce its basic things.

RTCP is actually a feedback of the RTP transmission situation, which, in layman's terms, tells the other party, at one end of the time (5 seconds), how many packets it sends to each other and how many packets it receives.

In addition, there are two more important things in RTCP, a 64-bit absolute timestamp and a 32-bit relative timestamp. The 64-bit timestamp is also called the NTP timestamp, and its first 32 bits are the integer portion in seconds from January 1, 1900 0 o'clock to now, and the last 32 bits are the fractional parts of this time, so it can be sure that the data is sent out in absolute time. A 32-bit timestamp is the same as the timestamp in RTP, without any difference.

(3) We are interested in the use of timestamps and some topics of synchronization.

1, the role of SSRC.

SSRC corresponds to the ID of a RTP transfer session, as everyone has a name, and each RTP transmission has a name. This number is randomly generated and is guaranteed to be unique. This ID also changes when the RTP session changes (such as IP, etc.).

2. Can the serial Number field be used as the synchronization label in the stream?

As I have said above, serial numbers only indicate the order in which the packages are issued, and they do not represent any other concept at any time, and all strictly speaking, serial numbers cannot be used as synchronization flags within the stream. However, as a general rule, packet delivery time will have strict restrictions, such as the audio packet is sent 30 packets per second, that is, each packet interval 1000/30ms, and this time can be played as a synchronization time. In other words, a packet is played every 1000/30ms interval according to the serial number, which also guarantees synchronization, but consider the problem of packet loss.

3. What is the difference between an absolute timestamp and a relative timestamp when synchronizing

When we get the absolute time, we can play these packets according to this absolute time. This absolute time, coupled with the delay we need (for data transmission, decoding and so on) is our playback time, so we can guarantee the strict synchronization of time (equivalent to the other side of the action delay after a period of time to reproduce the exact). Currently, in RTP, the only way to get this absolute time is rtcp.

For relative timestamps, we are more concerned with the time interval between two timestamps, depending on the time interval, to determine the playback interval of two packets.

4. What is the difference between synchronization in a single media and synchronization between different media streams in the processing mode?

It should be said that the synchronization between different media than the single-media synchronization is much more complex, in addition to ensure that its own playback and time synchronization, but also to ensure that two or more media synchronization (such as audio and video synchronization). This difference is more concerned with the conversion of two timestamp time unification, as I have said before, different codes have different sampling frequency, then the time stamp growth is different. In addition, two timestamps also need to have a standard time to represent the synchronization of timestamps. The simplest method is that the first timestamp of the two media is the same, indicating that the acquisition start time of the two streams is uniform. You can also use RTCP to synchronize between different streams, which is mentioned in the next question.

5. How timestamp fields are used as synchronization identities between streams

In the RTP protocol, we have two ways to get timestamps: one is the timestamp in the RTP packet, the other is the absolute timestamp and the relative timestamp in the RTCP packet. The concept of absolute timestamp above I have said that it can represent the absolute time of the system. The relative time in the RTCP packet is the time in the RTP packet. Depending on these two times, different streams can correct their playback time and the true time deviation to achieve the goal of absolute time synchronization. Conversely, if we have no way to get this absolute time, only the relative time in the RTP packet, then how do we need to determine the two stream at a point in time timestamp value. Colloquially, that is, at some point in time, the timestamp of the flow A is how much, B is how much, and then according to this time two stream playback delay time, in order to achieve the purpose of synchronization. The simplest way to achieve this is to use the same stamp at the beginning of the two streams, take the audio and video, at an absolute moment, collect the corresponding data, and play the same time stamp, after the playback, all of this time to make the base time to ensure synchronization.

RTP and RTCP explanations. With synchronous timestamp