Because the architecture has changed a bit, the context is initialized
only after add_srtp_ctx() has been called to prevent the user from
sending unencrypted messages.
Remove old context configuration flags that are no longer used,
convert configure_ctx() to work as a handler for all RCC_* flags
and use default values in sender/receiver/queue during initialization
If the clock rate is not set (ie. it's zero) it will screw up
the timestamp calculations and may cause problems for the receiver,
especially when fragmentation is enabled
This flag indicates to kvzRTP that the input data given to push_frame()
is writable and the encryption can be done in-place.
By default kvzRTP assumes that the input cannot be modified and creates
a copy of the input data.
Failing to check this caused an infrequent error where kvzRTP
started a fragmentation unit but because there was not enough bytes
it couldn't finish it and thus the receiver never returned the frame
to user because it only received the first fragment (which was the full
frame)
Having separate enums for general configuration and media configuration
might be too confusing given that they are passed to kvzRTP using same
variable and the configuration values must not clash with each other
so the second enum's values would have to start from RCE_LAST which
might look weird
Dropping new inter frames when an intra is in progress is a little
too aggressive considering the intra might be finished by the time
all inter frame packets have been received so basically we would lost
a perfectly valid frame for no reason
This is the range where it's possible to reach sensical send/recv goodputs.
Going lower than 0.9375 doesn't even make sense and going higher than 960
will probably result in 90% of frames being dropped because
nobody can packetize and send 4K stream that fast.
Aaro Altonen