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
This isn't quite optimal solution just yet. All copying should be
deleted but that requires some extensive studying of the winsock
documentation and it has to do for now
This API is used to send small messages. The message may consist of
several smaller buffers or it may just be one buffer containing all the
data.
The total size of buffers must not exceed the MAX_PAYLOAD limit
This is very similar to using frame queue but if there's no need for
caching the frames ie. all the needed buffers are ready, it easier to use these
functions than to enqeueu and then flush the queue
Aaro Altonen