uvgRTP v2.1.0

This release brings an improved build system, automated testing and working examples. In addition, the reliability of streaming has increased, with most prominent bugs being fixed in both RTP and SRTP streaming. ZRTP also now supports two streams instead of only one. Thanks to everyone who helped with pull requests!

Dependencies

• The minimum supported CMake version has increased to 3.14

New Feature

• Greatly improved CMake build system including tests and version API (thanks to @db-tech)
• macOS compilation (thanks to @eliteraspberries)
• Automated tests to help with development
• Examples are now working code that can be run and built upon
• More documentation
• Increased the number of supported payload formats from 5 to 27
• Options to send at certain frame rate
• Option to pace the sending of fragments to help the receiver
• Garbage collection for partially lost frames

Fixes

• H26x sending no longer loses frames with sizes 1444 - 1446.
• RTP reception now has increased performance, leading to much higher reliability
• RTCP now uses compound packets as specified in RFC 3550 instead of single packets
• Fixes to various aspects of RTCP (thanks especially to @wowaser for helping out)
• Improve code readability
• Remove memory leaks
• Remove compiler warnings
• Further cleanup of include folder
• Numerous other smaller fixes

API changes

While we try to keep the API changes to an absolute minimum, the following changes were implemented:

• The port parameter type of create_mediastream()-function was changed from int to uint16_t
• The SDES messages structure was changed, so all messages described by RFC 3550 are possible
• While no flags were completely removed (they still compile), some of them have been obsoleted (see docs folder for an up-to-date list of flags)
• Because of the compound packet nature of RTCP, the usage of RTCP has changed significantly
• Removed the possibility of building uvgRTP with Qt project file

Known issues

• The implementation of RTCP still has some missing fields and features
• Multithreaded use of ZRTP only supports at most two streams reliably
• No IPv6 support yet

New Contributors

• @jheo4 made their first contribution in #10
• @derkolja made their first contribution in #84
• @fador made their first contribution in #86
• @marco-tranzatto made their first contribution in #100
• @juteman made their first contribution in #123
• @LeeTaekLim made their first contribution in #134
• @gugautie made their first contribution in #135
• @eliteraspberries made their first contribution in #149
• @devenvexe made their first contribution in #157
• @ashley-b made their first contribution in #167

Full Changelog: v2.0.1...v2.1.0

uvgRTP v2.0.1

This is a minor patch that improves variety of existing features within uvgRTP as well as increases the code quality.

Highlights

• Correct sending of RTCP sender reports and correct inclusion of receiver reports
• Updated documentation
• Bug fixes to buffer sizes
• Support for using 196/256 length keys in SRTP when user provides the keys (no ZRTP support)
• Refactoring to reduce dependencies within code files
• Refactoring to reduce duplicate code
• Move some of the private headers out from public include folder
• Enable debug logging

uvgRTP v2.0.0

uvgRTP v2.0 has been released!

Highlights

• Secure RTP (SRTP)
• Zimmermann RTP (ZRTP)
• RTP payload format for AVC/H.264
• RTP payload format for VVC/H.266 (draft)

In addition to these new features, Doxygen documentation was added, and the build process of the library has been unified for all supported platforms.

Performance

• In ideal conditions, uvgRTP can stream unencrypted 8K HEVC video at 210 fps and it attains a round-trip latency of 7.3 ms.
• In ideal conditions, uvgRTP can stream encrypted 8K HEVC video at 125 fps and it attains a round-trip latency of 11.2 ms.

Additional notes

Windows users: Please remember to update your headers. The name of the top-level namespace of uvgRTP was renamed from uvg_rtp to uvgrtp. The old namespace is kept as an alias for backwards-compatibility but there may be errors if you try to use the old headers.