Definition at line 525 of file oqueue.h.

Get the timestamp that should be given for a packet whose payload sampling instant corresponds to the current system time.

The timestamp applications should provide for each packet represents the sampling instant of its payload and should not be a reading of the system clock. Nevertheless, the internal operation of the RTP stack relies on the accuracy of the provided timestamp, since several computations assume that there is a certain degree of correspondence between the timestamp and the system clock.

It is recommended that applications use this method in order to periodically adjust the RTP timestamp.

In particular, it is advisable getting the timestamp corresponding to the first sampling instant or any instant after a period of inactivity through a call to this method.

Applications should use the nominal sampling or any other value provided by the coder in order to compute the next timestamps with minimum computational requirement.

For instance, an application using an RTP profile that specifies a fixed sampling rate of 8 Khz with eight bits per sample, continuously transmitting audio blocks 80 octets long, would transmit 100 packets every second. Every packet would carry a timestamp 80 units greater than the previous one. So, the first timestamp would be obtained from this method, whereas the following ones would be computed adding 80 every time. Also the timestamp should be increased for every block whether it is put in the queue or dropped.

The aforementioned increment can be obtained from the RTPDataQueue::getTimestampIncrement() method rather than computing it by hand in the application.

Note

Frame based applications must follow a specific timestamping method, probably specified in a profile.

You should take into account that by default ccRTP assumes that the application begins sampling at the queue creation time. Moreover, the first sampling instant is assigned a "user visible" timestamp of 0, although the RTP stack will then add internally a ramdom offset unknown to the application. That is to say, the application may count samples from 0 in order to get the timestamp for the next packet, provided that the first sampling instant is the same as the queue creation time. Nevertheless, this simpler way of starting will not be as accurate as it would be if the application got at least the first timestamp through getCurrentTimestamp. We provide this option since ccRTP interface is evolving, but we admit that it is ugly, we could remove this option or even replace uint32 timestamps with a restrictively regulated object; suggestions are gladly welcomed