Load type and timestamp in RTP Transmission

I was recently depressed by the load type and timestamp of RTP. After debugging for nearly a week, I finally solved the problem. Let's look back, I found that the main reason is that I did not really understand the meaning of the load type and timestamp in the RTP protocol. Although RTP transmission is supported by Jrtplib and Ortp databases, one is the c ++ interface and the other is the c language interface. Each has its own characteristics and its own application environment, but can I solve all the problems only by having a database? You may be able to complete the main functions following some examples. However, once a problem occurs, it is difficult to locate and solve the problem if you do not know the principle, I would like to advise you with my experience that you should first clarify the principles before using it to sharpen your skills to cut firewood ......
Before reading this article, you should first know what the RTP protocol is. You can refer to the original RFC3550 protocol of the RTP protocol.) You can also read a lot of articles about the RTP protocol explained by some netizens, here I provide a http://blog.csdn.net/bripengandre/archive/2008/04/01/2238818.aspx that I personally think is well written.

Well, let's get down to the point. First, let's talk about the load type in RTP transmission.

First, let's look at the RTP Header Format:
650) this. width = 650; "border =" 0 "alt =" "width =" 503 "height =" 141 "src =" http://www.bkjia.com/uploads/allimg/131228/1K2434646-0.jpg "/>

10 ~ 16 Bit is a PT domain, which refers to the PayLoad type. The load type defines the RTP load format. In the original article, this domain is determined by the specific application.
Currently, the load type is mainly used to tell the receiver or player) which type of media is transmitted, such as G.729, H. 264, MPEG-4, etc.), so that the receiver or player) to know the data stream format, will call the appropriate decoder to decode or play, this is the main role of the load type.
For the ORTP library this article uses ortp-0.9.1), the load type definition is as follows:
650) this. width = 650; "border =" 0 "alt =" "src =" http://www.bkjia.com/uploads/allimg/131228/1K2432347-1.jpg "/>

Each type of load has its own unique parameters. It basically covers some mainstream media types, such as pcmu, g.729, and h.263. It is strange that h is not defined. 264. Note: The new version has been added to the h. 264), MPEG-4, and so on. The Jrtplib library should have similar definitions. You can find the source code and I will not go into details here.

Both the ORTP Library and the JRTplib library provide functions for setting the RTP load type. Remember to set them according to the actual application. I didn't pay attention to them at the time, use ORTP's default pcmu audio load type to transmit H. 264 encoding of video data, results transmission has been a problem, it has plagued me for a long time.

Okay. Let's talk about the RTP timestamp.

First, understand several basic concepts:

Timestamp unit: the unit of Timestamp calculation is not a unit such as a second, but a unit replaced by the sampling frequency. This aims to make the timestamp Unit more accurate. For example, if the sampling frequency of an audio is 8000Hz, we can set the timestamp unit to 1/8000.
Timestamp increment: the time difference between two adjacent RTP packets is based on the timestamp unit ).
Sampling frequency: the number of samples taken per second. For example, the audio sampling rate is generally 8000Hz.
Frame Rate: the number of frames transmitted per second or displayed, for example, 25f/s.

Let's take a look at the definitions in the RTP timestamp textbook:

The 2nd 32Bit RTP packet header is the Time Stamp of the RTP packet, which occupies 32 bits.
The timestamp reflects the sampling time of the first byte of the data in the RTP group. The initial timestamp values at the beginning of a session are also randomly selected. Even if no signal is sent, the timestamp value increases with time. The receiving end uses a timestamp to accurately know at which time the data block should be restored to eliminate the jitter during transmission. Timestamp can also be used to synchronize audio and image in a video application.
The RTP protocol does not specify the timestamp granularity, depending on the type of the payload. Therefore, the RTP timestamp is also called a media timestamp to emphasize that the granularity of the timestamp depends on the signal type. For example, for 8 kHz-sampled voice signals, if a data block is formed every 20 ms, a data block contains 160 samples (0.02 × 8000 = 160 ). Therefore, the timestamp value of each RTP group is increased by 160.

Do you understand the official explanation? Did not understand? It doesn't matter. I didn't understand it at the beginning. Let me explain it.

First, the timestamp is a value that is used to reflect the collection time of a data block. The timestamp of the data block collected later must be greater than the data block collected first. With such a timestamp, you can mark the sequence of data blocks.
Second, in real-time stream transmission, data is immediately transmitted to the RTP module for sending after collection. In fact, the collection timestamp of the data block is directly used as the time stamp of the RTP package.
Third, if RTP is used to transmit fixed files, the timestamp is the time point for reading files, increasing sequentially. This is not in our current scope of discussion.
Fourth, the unit of the timestamp is the reciprocal of the sampling frequency. For example, if the sampling frequency is 1/8000Hz, the unit of the timestamp is. In the Jrtplib database, there is a function interface for setting timestamp units, while the ORTP library directly sets the timestamp unit for audio load 1/8000 and video load 1/90000 according to the load type)
Fifth, timestamp increment refers to the time interval between two RTP packets, the unit of time between sending the second RTP packet and sending the first RTP packet is timestamp ).
If the sampling frequency is 90000Hz, we can see from the above discussion that the unit of the timestamp is 1/90000. We assume that 90000 time blocks are allocated for one second, if 25 frames are sent per second, so how many time blocks do each frame send? Of course it is 90000/25 = 3600. Therefore, according to the definition, "the timestamp increment is the time interval when the second RTP packet is sent separately." Therefore, the timestamp increment should be 3600. Supplement: I have been thinking about it recently and have some new experiences and explanations. It may be helpful for you to understand the timestamp increment more easily. Add the following to the question: actually, network Transmission focuses on the balance of traffic, that is, the balanced use of network bandwidth. To achieve this, we need to meet the following requirements: the data collection rate should be consistent with the data network transmission rate. The setting of Timestamp increment affects the network transmission rate of RTP packets. The smaller the timestamp increment, the faster the transmission speed. The following further explains how timestamp increments are calculated: for a PAL video, the camera collects 25 frames of data per second. Therefore, it takes 1/25 s to capture one frame, if we design a RTP package to contain only one frame of data and send one frame at a time, we should design the timestamp increment to 1/25 s to ensure even network traffic. in the implementation of the RTP protocol, the unit of the timestamp is not second s, but the Convention is the reciprocal of the sampling frequency, because the sampling frequency of the general video is 90000, therefore, the timestamp unit is 1/90000 s. Therefore, the actual timestamp increment = timestamp increment (1/25 s)/timestamp unit (1/90000 s) = 3600
In Jrtplib, it seems that you do not need to manually manage the increase of Timestamp, which is managed by the database. However, in ORTP, each time data is sent, you need to input the timestamp value, that is, you need to accumulate the timestamp increment after each RTP packet is sent, which is not very convenient, this requires a deep understanding of the RTP timestamp. At the beginning, I was confused and set the timestamp increment at any time, which caused transmission problems for a long time.

Now, the introduction of RTP load types and timestamps is here. I have learned a lot by solving problems in RTP transmission. I hope this article will be useful to you. Have said not correct place welcome expert advice, can also send a letter to exchange: lujun.hust@gmail.com
 

This article from the "three shadows" blog, please be sure to keep this source http://ticktick.blog.51cto.com/823160/350142