About timestamp issues in RTP

You need to set the timestamp unit (timestamp) and timestamp increment (timestamp increment) when sending data using Jrtplib.             Read some articles on the Internet, carefully wanted to think now just figured out the problem. The RFC3550 description of the timestamp is:

A timestamp (timestamp) 32-bit timestamp reflects the sampling time of the first byte in the RTP packet. (The sampling clock must originate from a timely, monotonically, linearly incrementing clock to allow synchronization and removal of packet jitter caused by the network (see section 6.4.1). The resolution of the clock must satisfy the desired synchronization accuracy and the need for jitter when measuring packet arrival (a typical clock resolution is not satisfied with the case that only one clock cycle per video frame) The clock frequency depends on the format of the payload data, It is also statically described in the description file (profile) or in the Payload format description (payload format speci_cation). The payload format can also be described dynamically through non-RTP methods (NON-RTP means).

If the RTP packets are generated periodically, the nominal sampling time determined by the sampling clock is used instead of the system time. For example, for a fixed rate of audio, the sample clock (timestamp clock) will increase by 1 per cycle. If an audio reads a block with 160 sample cycles from the input device, the value of the timestamp is incremented by 160 for each block, regardless of whether the block is passed with a packet or discarded.

The initial value of the timestamp should be random, just like the ordinal. Several sequential RTP packets, if (logically), are generated simultaneously, such as: RTP packets belonging to the same video frame, will have the same serial number. If the data is not transmitted in the order in which it is sampled, successive RTP packets can contain a timestamp that is not monotonically incrementing (or decreasing) (the sequence number of the RTP packet is still monotonically changing).
According to some articles, I have elaborated some of the following concepts:
Timestamp unit: The unit in which the timestamp is calculated is not a unit of seconds, but a unit that is replaced by the sampling frequency, so that the purpose is to be more precise in the timestamp unit. For example, if an audio sample frequency is 8000HZ, we can set the timestamp unit to 1/8000.
Timestamp increment: The time difference (in timestamp units) between adjacent two RTP packets.

How to set the increment between timestamps.
According to the time stamp unit, 1 seconds according to the timestamp unit is 8000, then a second if you can play 20 frames, that is, send 30 frames (frame rate), then you can find the time difference between two adjacent frames, that is, timestamp increment, then it is obvious that 8000/ 20, then this timestamp increment is 400.
An example of most of the online examples are: MPEG, 20ms per frame, sample frequency 8000Hz, set timestamp unit 1/8000, and 160 increments between each package
How to understand it here. It is easy to see that the increment is directly 8000 multiplied with 20ms results, we can know that the time between two frames is 20ms, that is, 0.02s, this unit is measured in seconds, then we have to use time-stamp units to indicate that is 8000*0.02=160. So the timestamp increment is 160.

There is also a point why the general use of 90000 as the video sampling frequency.
90k is the time scale for video synchronization (timescale), which is 90k clock ticks per second. Why use 90k? At present, the frame rate of video is mainly 25fps, 29.97fps, 30fps and so on, and 90k is just a multiple of them, so it adopts 90k.