Load type and timestamp in RTP Transmission

Source: Internet
Author: User

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 go to the original RTP protocol (RFC3550 protocol), or 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:

10 ~ 16 Bit is a PT domain, which refers to the PayLoad. The load type defines the RTP load format. In the original article, the 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 (for example, 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, the load type is defined as follows:

Each type of load has its own unique parameters, which basically cover some mainstream media types, such as pcmu, g.729, and h.263 (it is strange that h is not defined. 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 (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, if a voice signal sampled at 8 kHz forms a data block 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 generation (Collection) time point of a data block. The timestamp of the acquired data block must be greater than that of the first data block. 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 the timestamp unit, while the ORTP library directly sets the timestamp unit (audio load 1/8000, video load 1/90000) based on the load type)
Fifth, timestamp increment refers to the time interval between two RTP packets, the time interval (unit: Timestamp unit) when the first RTP packet is sent when the second RTP packet is sent ).
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.
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.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.