timestamp and av sync
1. rtp/rtcp av sync
1.1 NTP time
RFC 1305 says such that,
Since NTP timestamps are cherished data and, in fact, represent the main
product of the protocol, a special timestamp format has been
established. NTP timestamps are represented as a 64-bit unsigned fixed-
point number, in seconds relative to 0h on 1 January 1900. The integer
part is in the first 32 bits and the fraction part in the last 32 bits.
This format allows convenient multiple-precision arithmetic and
conversion to Time Protocol representation (seconds), but does
complicate the conversion to ICMP Timestamp message representation
(milliseconds). The precision of this representation is about 200
picoseconds, which should be adequate for even the most exotic
requirements.
Sender Report RTCP Packets (SR)
A Sender Report message consists of the header, the sender information block,
a variable number of receiver report blocks, and potentially a profile-specific extensions.
The header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| RC | PT=SR=200 | length L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V, P:
As described for RTP data packets, see above. RC: 5 bits
The number of reception report blocks contained in this packet. PT: 8 bits
The packet type constant 200 designates an RTCP SR packet. L: 16 bits
The length of this RTCP packet in 32-bit words minus one, including the header and any padding.
SSRC: 32 bits
The synchronisation source identifier for the sender of this SR packet.
The sender information block:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word NTS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp RTS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count SPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count SOC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTS: 64 bits
The NTP timestamp indicates the point of time measured in wall clock time
when this report was sent. In combination with timestamps returned in reception
reports from the respective receivers, it can be used to estimate the round-trip
propagation time to and from the receivers.
RTS: 32 bits
The RTP timestamp resembles the same time as the NTP timestamp (above), but is
measured in the same units and with the same random offset as the RTP timestamps
in data packets. This correspondence may be used for intra- and inter-media
synchronisation for sources whose NTP timestamps are synchronised, and may be used
by media-independent receivers to estimate the nominal RTP clock frequency.
SPC: 32 bits
The sender's packet count totals up the number of RTP data packets transmitted by the
sender since joining the RTP session. This field can be used to estimate the average
data packet rate.
SOC: 32 bits
The total number of payload octets (i.e., not including the header or any padding)
transmitted in RTP data packets by the sender since starting up transmission. This field
can be used to estimate the average payload data rate.
The receiver report blocks:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC_1 (SSRC of first source) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|fraction lost F| cumulative number of packets lost C |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received EHSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| inter-arrival jitter J |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR LSR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR DLSR |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second source) |
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SSRC_n: 32 bits
The SSRC identifier of the sender whose reception is reported in this block.
F: 8 bits
The sender of the receiver report estimates the fraction of the RTP data packets
from source SSRC_n that it assumes to be lost since it sent the previous SR or RR packet.
C: 24 bits
The sender of a receiver report blocks also tries to estimate the total number of RTP
data packets from source SSRC_n that have been lost since the beginning of reception.
Packets that arrive late are not counted as lost, and the loss may be negative if there
are duplicates.
EHSN: 32 bits
The low 16 bits of the extended highest sequence number contain the highest sequence number
received in an RTP data packet from source SSRC_n, and the most significant 16 bits extend
that sequence number with the corresponding count of sequence number cycles.
J: 32 bits
An estimate of the statistical variance of the RTP data packet inter-arrival time, measured
in timestamp units and expressed as an unsigned integer.
The extensions:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
From above, NTP is 64bits, includes two parts, one is named as MSW,
another is named as LSW. As far as LSW, is in about 200 picoseconds unit.
1 second equals to 1000,000,000,000 picoseconds, which is represented
by 32bit. Therefore, each bit will represent about 232 picoseconds.
i.e. 1000, 000, 000, 000 / 2^32 = 232 picoseconds / bit.
See ntp implement in vlc source code below.
/* Convert nanoseconds to 32-bits fraction (232 picosecond units) */
uint64_t t = (uint64_t)(ts.tv_nsec) << 32;
t /= 1000000000;
it is inferred as this
10^12 / 2^32 = ts.tv_nsec * 10^3 / t
i.e. 10^12 picoseconds correspond to 2^32, then how much is corresponded to
ts.tv_nsec * 10^3 picoseconds.
Therefore
t = ts.tv_nsec * 2^32 / 10^9
further statement, 32bits denote 2^32 lattices, each lattice denote 10^12 / 2^32
picoseconds, i.e., about 232 picoseconds. That says, 10^12 picoseconds need 2^32 lattices
to represent, then how many lattices (t) is requried to
denote ts.tv_nsec nanoseconds, then above formula is obviously.
In other words, 2^32 / 10 ^12, the number of lattices denote for each 1 picosecond,
then ts.tv_nsec nanoseconds, i.e., ts.tv_nsec * 10^3 picoseconds, hold (or need),
how many lattices? then it is
ts.tv_nsec * 10^3 * 2^32 / 10^12
further,
ts.tv_nsec * 2^32 / 10^9
/**
* @return NTP 64-bits timestamp in host byte order.
*/
uint64_t NTPtime64 (void)
{
#if (_POSIX_TIMERS > 0)
struct timespec ts;
clock_gettime (CLOCK_REALTIME, &ts);
#else
struct timeval tv;
struct
{
uint32_t tv_sec;
uint32_t tv_nsec;
} ts;
gettimeofday (&tv, NULL);
ts.tv_sec = tv.tv_sec;
ts.tv_nsec = tv.tv_usec * 1000;
#endif
/* Convert nanoseconds to 32-bits fraction (232 picosecond units) */
uint64_t t = (uint64_t)(ts.tv_nsec) << 32;
t /= 1000000000;
/* There is 70 years (incl. 17 leap ones) offset to the Unix Epoch.
* No leap seconds during that period since they were not invented yet.
*/
assert (t < 0x100000000);
t |= ((70LL * 365 + 17) * 24 * 60 * 60 + ts.tv_sec) << 32;
return t;
}
2. rtp
2.1 rtp on audio
for example:
sample bitrate: 32000HZ
samples of one frame: 1024
then interval of packetizing one frame:
32000/1 = 1024/x => x = 0.032 secs
reversely:
for example the sample bitrate and packetize intervals is known.
e.g. 32000HZ, 32ms
then, its timestamp increased of each frame packetized is
32000/1 = x/0.032 => x = 1024
2.2 rtp on video
90000HZ, fps=30, then its timestamp increased of each frame
is
90000/1 = x/1/25 => x = 3000