RTP and Rtcp explain. Include sync timestamp

RTP and Rtcp explain. Include sync timestamp

RTP is real-time transport protocol abbreviation, is designed to transmit streaming media data, has a wide range of applications, other related to the introduction of their own 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 rely on the underlying protocol, that is, it is an independent protocol. In general, because of the fast, high-real characteristics of UDP packets, it is usually combined with UDP, as the upper carrier data of UDP transmission.

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 might think, right or wrong. Let's take a look at some of the main parameters, they are also RTP souls:

(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 commonly used, in fact it is a immediately generated ID, indicating a RTP connection. When applied, make sure that the ID is the only thing you can do.

(3) Sequence number. The serial number, which indicates the current package is the first few packages. Each send a packet, the sender of this value plus one. Accept put can be based on this value to regroup the package order, to determine whether the packet loss and other operations. Note: It only represents the order of the packages, and it cannot represent any other information on the time. This is compared to the time stamp that follows.

(4) timestamp. The time stamp, whose concept is slightly more complicated, I explain it in a slightly more popular sense, although this is a bit incorrect. The time stamp, as the name suggests, represents the time that a data is generated, like the postmark we mail, it's a time stamp (as far as this time is concerned, I'll say in detail later), which usually means the time that the first byte of data is generated in the RTP packet (as far as whether you use it is the problem with the program you're writing).

If you understand above, then we are further: in fact, the timestamp increase is not a microsecond in our usual sense, but it increases the length of time for a sample interval. For instance. Different acquisition has different sampling frequency, for example, the general audio is 8K sampling frequency, that is, 8 times a millisecond collection of data, that is, each sampling interval is 1/8ms, and timestamp an increase of 1 means that a sample interval is added. Which is the 1/8ms. In other words, if a coded sampling frequency is 16K, then a timestamp increase of 1 means that the system is 1/16ms. In other words, in the same system, for different encodings, although using the same clock, but the growth rate of timestamp is different, in this example, the sampling frequency is 16K code faster than 8K twice times, please remember this difference.

 

(2) Understand RTCP

RTCP protocol is real-time Transport Control protocol abbreviation, was designed to do RTP controls, this relatively little concern, I only introduced its basic things.

RTCP is actually the RTP transmission situation feedback, in layman's terms, it tells the other party, at one end of the time (5 seconds), it sent how much data packets to each other, received how many of each other's packets.

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 digits are the integer portion of seconds starting from 0 o'clock January 1, 1900 to the present, and the last 32 bits are the decimal parts of the time, so it can definitely represent the absolute time that the data is sent out. The 32-bit timestamp is the same as the timestamp in RTP, without any distinction.

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

1, the role of SSRC.

SSRC is equivalent to a RTP transmission session ID, just as everyone has a name, each RTP transmission also 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, the serial Number field can be used as a synchronization within the flow of the label.

As I said above, the serial number only indicates the order in which the packet is issued, it does not represent any other concept at any time, and all strictly speaking, the serial number cannot be used as the synchronization flag in the stream. However, as a general rule, packet delivery time will be strictly limited, 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. That is, the serial number of each 1000/30ms to play a packet, which can also guarantee synchronization, but this time please 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 the absolute time. This absolute time, plus the delay we need (for data transmission, decoding and so on time) is our playback time, so we can ensure the strict synchronization of time (equivalent to the other side of the action delay for a period of time after the exact reappearance). At present, 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 in how the synchronization between a single medium and the different media streams is handled

It should be said that the synchronization between the 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 about the two time stamp time of conversion unification, as I have said before, different coding has different sampling frequency, then the timestamp growth rate is different. In addition, two timestamps also require a standard time to indicate a timestamp synchronization. The simplest method is the same as the first timestamp of the two media, which indicates that the collection start time of the two streams is unified. You can also do synchronization between different streams by RTCP, which is mentioned in the next question.

5. How timestamp fields are used to synchronize identities between streams

In the RTP protocol, we have two methods to obtain the timestamp: One is the time stamp in the RTP packet, the other is the absolute timestamp and the relative timestamp in the RTCP packet. The concept of absolute timestamp I have already said that it can represent the absolute time of the system. The relative time in the RTCP packet is the time in the RTP package. According to these two times, different streams can correct their playback time and real time deviations to achieve and absolute time synchronization purposes. Conversely, if we have no way to get this absolute time, only the relative time in the RTP package, then how do we need to determine the value of the timestamp of two streams at a point in time. Colloquially speaking, is at a certain point in time, flow a timestamp is how much, B is how much, and then according to this time two stream playback delay time, in order to achieve synchronization purposes. The easiest way to achieve this is to start with two streams, use the same stamp, take audio and video, in a certain absolute moment, collect the corresponding data, and play the same time stamp, later play, all with this time to do the benchmark time to ensure synchronization.