Commit messages are exchanged and roles for both parties are selected
as defined in RFC 6189. Lots of details are omitted and they will be
implemented later on when crypto functionality is added to the project
kvzRTP's ZRTP implementation shall support only the mandatory algorithms
defined in the specification. There are several things missing from Hello
but those are somewhat minor details and will be fixed when the ZRTP is
starting to be ready
Making configuration global was moronic considering there are
different types of media streams per session (f.ex Opus and HEVC)
which have very different types of needs. For example, setting
receiver's UDP buffer size to 40 MB would make no sense for Opus.
Now each connection can be configured individually which is also
a needed feature for SRTP
This change reverted the changes made earlier to global API
The security layer is injected between reading a datagram from OS and
RTP/RTCP payload processing so the obvious place for that layer is socket.
Make all recv/send function calls go through socket API so the security
layer function calls doesn't have to be copied everywhere
To prevent excess relocations but to minimize the nubmer of system
calls done, OFR reads 15 datagrams from OS using one system call if
more than 2% or less than 98% of the frame has been read.
These values are a result of experimentation and they lowered the CPU
utilization most. Compared to simple receiver, OFR, with dynamic datagram
read size, uses 14% less CPU than.
These numbers could be improved even further if media-specific
optimizations would be done such as keeping track of intra or VPS
period to adjust max datagram read size or the legal interval for
max read.
This optimizations are, however, probably not going to yield a lot
of benefit compared to the current state of OFR and are thus not
implemented. As it is, OFR is already able to receive HEVC at
580 MB/s and uses 14% less CPU than simple so for high-quality video
conferencing situations with multiple participants this is a good
choice.
The version that does not use sendmmsg(2) didn't return proper status
codes for __push_hevc_frame() when it had sent the smaller NAL units.
This caused it to send far less data than it should have
The NTP millisecond diff calculation seems to be incorrect (it gives
very weird results) but miraculously it still produced playable video
stream.
I'll need to figure out what's wrong with the calculation at some point
but for now switch to use HRC.
Linux seem to have an undocumented "feature" where it accepts only
1024 messages per sendmmsg(2).
So basically, if you gave it a buffer containing f.ex 1100 messages,
it would only sent the first 1024 **without returning an error**.
This caused large intra frames not to be received fully creating
broken stream
When MSG_WAITFORONE is used, the system call returns 1..N packets
but the code initially assumes N packets are read so the offset pointer
might need adjustment after the fragments have been processed.
The sequence number counter is only 16 bits long meaning that it will
overflow quite fast and can cause S fragment to have larger sequence
number than what E fragment has.
Previous calculation didn't take this into account which caused all
fragment after the first overflow has happened to be discarded
Several classes have common active_ and runner_ variables and
stop/start/active routines (such as reader and dispatch).
Create one common class for these to make the interface cleaner
This is the third way of dealing with memory ownership/deallocation.
Application "lends" the memory for kvzRTP's use and when SCD has finished
processing the transaction associated with this memory, it will call the
deallocation hook provided by the application to release the memory.
This makes, for example, custom allocators possible where wrapping the
memory inside a unique_ptr is not suitable and creating copies is also
not acceptable.
Aaro Altonen