kvzrtp has internal mechanisms for keeping track of time and this
timestamp was actually not used because its accuracy is questionable
AND it had no reference clock.
This change makes the library also easier to use because now user
only has to push data to the library and doesn't have to keep track of
time.
RTCP is used for SSRC collision checking.
The actual RTCP functionality must be enabled explictly by
calling create_rtcp().
The line between packet validation and RTCP is becoming a little
blurry and a more coherent model for validation is a future task:
According to spec, simply calling random() is not enough without
initializing the state properly. We can tap into OS's entropy pool
and get good and secure random number using the platform-dependent
random() functions.
As a fallback, PSRNG of standard library is also initialize
though it should not be needed
If an SSRC conflic is detected, new SSRC must be generated and
all RTCP statistics zeroed out. The collision is detected for every
incoming RTP packet.
HEVC requires a lot of processing per frame whereas generic and Opus
don't require almost any. Creating a separate frame receiver where
all media-specifc processing can be done is the cleanest solution.
This is especially needed because receiving HEVC requires finer control
on the receiving side (recvfrom/WSARecvFrom) but opus/generic don't
so they actually can't be processed by the same receiver.
The new frame receiver requires (as does the spec) that RTP packets
have unique RTP sequence numbers.
We must store separate RTP header for each fragment and update only
the RTP sequence of each packet. This creates some spatial overhead by it's
negligible considering we need only one system call per full HEVC frame
We don't know how large frames remote is sending us so increasing
the buffer size (default size is 8KB on Windows) should give us some
leeway.
Too small buffer causes the OS to drop packets.
Because UDP packets may not arrive in order, we need to reorder as
they're received. The problem of previous implementation was that
it assumed that packets were ordered correctly and if it detected
a "stray packet", it dropped the whole frame which was suboptimal
We also need to keep track of much time it has taken to receive
the fragments and if a certain threshold is crossed, discard the frame.
There's still room for improvement because now the incoming frame is
copied to a temporary RTP frame and when all fragments have been received,
these fragment are merged together to a larger RTP frame. This extra copy
should be eliminated.
Make sure that header is correct, copy the CSRCs if present, and
make sure padding is discarded if the frame has been padded
Extension checking missing
Aaro Altonen