The MTU size was too small since it subtracted the Ethernet header size
which is not included in MTU. This fix results in 14 bytes larger
RTP frames, which increases throughput slightly.
Also added few sizes for IPv6, but they are not used yet.
SCC has an increased chance of losing frames at the receiving end if
used and I think this justifies it disabling. The benefit of SCC is
reduce CPU usage at the sender. Added a flag for enabling it.
This may break some implementation if they don't want start code prefix
for some reason or if they already implemented start code prefix in
their code.
Those who implemented themselves are using an inferior solution
(one extra stream copy for fragmented frames) and should update anyway.
Those who use the flag will just get a warning to update their flags.
Those whose decoder doesn't want start code prefix may not work without
adding a flag.
The API forced uvgRTP to both bind to local port even if user does not
need or want this and it also expects the user to know the remote
remote address which is not always possible.
This commit adds API to session for specifying only one port when
creating media_stream. This commit also adds RCE_SEND_ONLY and
RCE_RECEIVE_ONLY flags which can be used to prevent binding and specify
the meaning of single address and port parameters.
I noticed that H263 uses a very similar fragmentation as
RCE_FRAGMENT_GENERIC and this commit modifies the implementation to use
the exactly same scheme in case we want to support H263 at some point.
* common: Remove stray quote from include to silence warning
* Fix warning related to return type for sendmmsg stand-in
Co-authored-by: Matt Durgavich <mdurgavich@vivox.com>
It was making compiling software that wants to use crypto more
difficult and it was completely unnecessary. It is possible that
someone is using the enable function there, but it has also existed
in the context class for a long time.
I've already created one bug by not being able to distinguish between
different flags. uvgRTP has four types of flags: enable, context, rtp
and socket. I'm planning on adding one more flag type which makes this
a good point to rename all flags.
It is no longer possible to send APP packets alone as RFC 3550 does
not permit this. Instead they are sent together with SR and RR as they
are supposed to.
RFC 3550 A.8 says that jitter should be saved as float and sampled to
32-bit unsigned integer. This commit fixes this and seems to improve
the accuracy of jitter estimation (previously it often showed just
15 or 10).
The allowed payload sizes were calculated slightly incorrectly and
this caused frames with sizes near the allowed frame size to be not
sent or sent incorrectly. Now all these errors should be fixed.
uvgRTP was using incorrect terms in few places which made the code more
difficult to understand. This commit fixes this by changing NAL header
(incorrect) to payload header (correct).
Integrated runner into holepuncher since it was the only remaining class
still using it and they both are small classes where separation does more
harm than good.
The dispatching is what technique the class uses, but it does not
describe its responsibilities at all making it very hard to figure out
what role it plays in the architecture just by looking at the name.
Also removed all references to obsolete System call dispatcher
(different concept) in all the comments.
With this separation, the user has the option of not including all
the classes with lib.hh, where as previously it was mandatory because
context is always needed.
The previous implementation had the pull_frame take around 20x longer
than what the user specifies (no matter how long the user specified.
Now the excess should only be max 30 ms, which is an improvement.
These tests are mostly just placeholders until something more
substantial is added. They are good tests, but it would be better to
also test the functions in different kinds of scenarios.
Note: the Crypto++ is causing problems in tests on Windows, because the
CMake is rerun often and this causes the Crypto++ linking to disappear.
I just switched all __linux to not _WIN32 in the hopes that Unix/Linux
API would be more likely to be found on Mac OS. This has not been
tested on Mac so it may or may not work.
Primary changes are:
- Versioning integrated in cmake build system with library for version usage in end user programs
- New minimum CMAke required version is 3.14
- Created install capabilities. Allows uvgRTP to be used in different scenarios for win and lin (mac-os still missing)
- Added testing environment with automatically fetched google test and some example test code.
- Added packaging capabilities (and some placeholders that have to be changed)
- Create Shared library with -DBUILD_SHARED_LIBS=TRUE
Send receiver reports instead of sender reports if we haven't sent any
RTP packets. Also don't include report blocks if we haven't received
any RTP packets.
The architecture is more easily modified with less dependencies. The
dependency concerned only getting the keys from zrtp and now that is
handled by media_stream.
Also added checks that we are not double freeing resources, since
previous version seemed very risky.
This commit removes little bit of duplicate code, making future bug
fixes easier. The length of the packet is not set correctly, but that
will bi fixed in future.
Since compiler was complaining about them and its little bit more
secure, I set all integers to 0 and pointers to nullptr. There is a
small risk of reduced performance if the initialization is done
frequently, but I think the risk is worth it since uvgRTP is already
one of the fastest RTP libraries in the world and there are issues with
reliability.
The member variable initialization was introduced in C++11 which is the
lowest we support at the moment.
I tried to make the headers be included in local to global order. This
way any potential missing includes are detected making it easier to
make changes to header location and includes.
The 2.0.0 release of uvgRTP fails to build on CentOS7, because :
- the gcc-c++ compiler doesn't support the c++17 standard, which is
required to compile the crypto.hh file
- the getrandom() function isn't available in the libc
This pull request adds CentOS7 build support.
The modified files are :
- CMakeLists.txt : the availability of the getrandom() function is checked.
If it exists, the HAVE_GETRANDOM preprocessor definition is added
- src/random.cc : if HAVE_GETRANDOM isn't defined, a syscall equivalent to
the getrandom() functions is called
- include/crypto.hh : the c++17 code is replaced by a code that compiles with
the CentOS7 compiler (c++11)
Fragmented generic frames whose sequence numbers crossed the overflow
boundary were incorrectly reconstructed as the last fragments of the
frame were in the beginning of the buffer.
Save the frame info to the media object and fetch it from there
when a packet is received, update the code to better handle out-of-order
packets and add support for RCE_H26X_PREPEND_SC
I have no idea why the name had an underscore but now it's gone.
The old namespace is kept as an alias for backwards-compatibility
but it may be removed in the future
1443 is the maximum payload size for H26X Fragmentation Units but
for generic frames there is no NAL + FU header meaning the 3 bytes
can be used for payload data
This change removes set_dynamic_payload() as ctx_configure() function
should be used for all context configuration instead of separate functions
for some configurations
Use __has_include to check if all needed headers are present in the
system and if so, build uvgRTP with crypto enabled.
Introduce new define, __RTP_NO_CRYPTO__ which disables SRTP/ZRTP
support even if Crypto++ is present in the system
Joni Räsänen
Matt Durgavich
Matt Durgavich
vechtomo
Mansour Moufid
Guillaume GAUTIER
dennis
Le Clech Philippe
Aaro Altonen