Releases: ultravideo/uvgRTP
uvgRTP 3.1.3
This patch release introduces bug fixes, small improvements to code quality, and reduces test execution time.
New Feature
Fixes
- Fixing Null pointer in rtp.cc #220 by @Atlas42 in #222
- Fix RTCP SR RTP timestamp value calculation by @befinitiv in #223
New Contributors
- @befinitiv made their first contribution in #223
Full Changelog: v3.1.2...v3.1.3
uvgRTP 3.1.2
This patch release introduces bugfixes and improves code quality.
New Feature
- Add basic Android support by @jstefanelli in #217
Fixes
- Update h26x.cc - fixed initialization order of 'dropped_ts_' and 'dropped_in_order_' by @inobelar in #218
- Fixed the issue when reconstructing h264 frames that are not continuous by @Banner2404 in #221
New Contributors
- @jstefanelli made their first contribution in #217
- @inobelar made their first contribution in #218
- @Banner2404 made their first contribution in #221
Full Changelog: v3.1.1...v3.1.2
uvgRTP v3.1.1
This patch release fixes an issue with the Aggregate Packets (AP) found in H264/H265/H266 payload formats.
Fixes
-Fix reordering issue when there are multiple, non-consecutive aggregatable NAL units inside an access unit given to uvgRTP via push_frame().
uvgRTP v3.1.0
This release focuses on finalizing the Aggregate Packet (AP) functionality for H264, H265 and H266 payload formats.
New Feature
- Support for Aggregate Packets for H264, H265 and H266
- New RTP flag RTP_H26X_DO_NOT_AGGR that can be used to disable the use of APs when necessary
Fixes
- Fixed bugs related to transmission and reception of multiple fragmented NAL units inside an access unit in H26x payload formats.
- Fixed a bug in H264 SCL
uvgRTP v3.0.0
This release focuses on features related to the RTP transmission of Visual Volumetric Video-based Compression (V3C) content.
New Feature
- RTP payload format for V3C Atlas
- Support for socket/port multiplexing (RFC 8872) by assigning the same port number to multiple media streams and setting their SSRC values accordingly
- Ability to set SSRC of a media stream via the RCC_SSRC context flag
- Ability to set remote SSRC for a media stream via the RCC_REMOTE_SSRC context flag
- Support for RTCP to RTP port multiplexing (RFC 5761) via the RCE_RTCP_MUX context flag
- Multithreaded packet reception
- New example program for V3C transmission
- Ability to change socket polling timeout value with the RCC_POLL_TIMEOUT context flag
- Ability to get configuration values from media streams via get_configuration_value()
- New create_session() API function
- random: Replace system random calls with STL by @roharvey in #192
- common: Added multicast bind support for ipv4 and ipv6 by @Atlas42 in #196
Fixes
- Fixed bugs related to reliability of ZRTP negotiation
- Compiler warnings fix by @eMKa94 in #206
- Fix build with gcc13 by @mathisloge in #210
API Changes
- Removed obsolete flags RCE_SYSTEM_CALL_DISPATCHER, RCE_NO_H26X_INTRA_DELAY, RCE_NO_H26X_SCL, RCE_H26X_NO_DEPENDENCY_ENFORCEMENT, RCE_H26X_PREPEND_SC, RCE_NO_SYSTEM_CALL_CLUSTERING, RCE_SRTP_INPLACE_ENCRYPTION to remove clutter from the API. Removing these flags from your code is safe since they did not do anything
- Removed renamed flags. Use the replacement to get the same effect
- RCE_H26X_DO_NOT_PREPEND_SC -> RCE_NO_H26X_PREPEND_SC
- RCE_FRAMERATE -> RCE_FRAME_RATE
- RCE_FRAGMENT_PACING -> RCE_PACE_FRAGMENT_SENDING
- RCE_ZRTP_MULTISTREAM_NO_DH -> RCE_ZRTP_MULTISTREAM_MODE
Known Issues
- Aggregate packets are not supported for H264, H266 or V3C Atlas. These are planned for 3.1 release
- When streaming H.264/H.265/H.266, sending access units that contain multiple large NAL units which require fragmentation may lead to issues
- When streaming H.264, if a NAL unit contains 0x00 0x01 0x00 byte sequence, there may be undefined behavior
New Contributors
- @roharvey made their first contribution in #192
- @Atlas42 made their first contribution in #196
- @eMKa94 made their first contribution in #206
- @mathisloge made their first contribution in #210
Full Changelog: v2.3.0...v3.0.0
uvgRTP v2.3.0
This release adds IPv6 support to uvgRTP. Using IPv6 addresses does not require anything from the user. It is not possible to mix IPv4 and IPv6 addresses together. If you use IP tunneling or VPNs, make sure to adjust the MTU size to your situation.
New Feature
- IPv6 support
Full Changelog: v2.2.0...v2.3.0
uvgRTP v2.2.0
This release focuses on finalizing RFC 3550 RTCP.
New Feature
- RTCP BYE packets are sent when exiting
- Handling received RTCP BYE packets and timing out inactive RTCP sources
- New example program for synchronizing audio and video streams
- RTCP reporting interval is calculated according to RFC 3550
- RTCP reporting interval can be manually set via RCC_SESSION_BANDWIDTH context flag
- rtcp: add hooking for sending APP packets by @wowaser in #187
- config: allow for custom SSRC. Added thread safety by @wowaser in #185
Fixes
- RTP timestamps in RTCP Sender Reports are calculated according to RFC 3550 (stream synchronization)
- Fraction lost field in RTCP Sender Reports is calculated correctly
- rtcp: add thread safety for participants_ data structure by @wowaser in #188
Known issues
- Multithreaded use of ZRTP only supports at most two streams reliably
- No IPv6 support yet
Full Changelog: v2.1.2...v2.2.0
uvgRTP v2.1.2
This patch release significantly reduces RTCP CPU usage, extends SCL to support NAL units as small as 4 bytes for H264 and 6 bytes for H265/H266 (including start code prefix). These are the smallest sizes reasonable. This release also fixes a bug where separate NAL units with same timestamps are discarded after first.
Fixes
- formats: Support smallest NAL unit sizes in SCL in 5ca3c13
- formats: Don't discard NAL units with same timestamps in c07a8c2
- rtcp: fix socket selection busylooping in rtcp polling by @wowaser in #178
Full Changelog: v2.1.1...v2.1.2
uvgRTP v2.1.1
This is a small patch release which fixes a bug in SCL, improves the handling of FPS flag, and renames the ZRTP mode flags (while keeping the old names valid, at least for now).
Fixes
Full Changelog: v2.1.0...v2.1.1
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