5.1.1. Release notes for v0.14

Bug fix: Bus message queue overruns

A bug has been fixed that could cause Gstreamer bus message queue overruns during peer sessions. This was previously resulting in the following warning message being logged:

[WARNING] [GStreamer:GST_BUS (no description): queue overflows with 2048 messages. Application is too slow or is not handling messages. Please add a message handler, otherwise the queue will grow infinitely.

Bug fix: Intermittent media session keep-alive issue

A bug has been fixed that could cause media sessions to drop media feeds and disconnect, due to a too-long keep-alive interval.

Bug fix: latency improvements

Several issues affecting both peer and session stream latency have been addressed, including timing misconfiguration and the maximum sizes of some queues. This should also reduce the frequency of both video and audio buffers being dropped, as well as improve latency recovery times after connection issues during peer streaming.

Audio feed stages: volume, automatic gain control, and filters

This release adds the ability to specify audio feed stages for audio feeds. It works in the same way as video feed stages, allowing applications to apply audio processing stages to audio feeds.

The following audio feed stages are now available:

• AudioStageVolume: Adjusts the volume of the audio feed.

• AudioStageWebRtcDsp: Applies configurable WebRTC audio processing filters, such as automatic gain control (AGC), noise suppression, and high-pass filtering.

See Audio stages for more details on how to use these stages.

Pipeline SRT/WebRTC element stats (experimental feature)

To help diagnose performance issues with SRT and WebRTC elements, we have added experimental stats logging. This allows applications to request detailed statistics for SRT and WebRTC feeds, including information about packet loss, latency, etc.

This is triggered on a per-feed basis by calling the feed’s feedRequest() function with a PxMedia::experimental::FeedLogStatsRequest request object. If any of the feed’s components recognises the request, it will log its stats out (note that if the feed has no such components, this is fine and the request is ignored without error).

Queue diagnostics (experimental feature)

To help diagnose latency issues, we have an added an experimental feature to trace queue overruns. Queues help manage media flow where the input rate cannot be consistently consumed by further processing (e.g. an input video is encoded before sending to a remote session). When the input cannot be processed in time, we can either hold on to frames to keep quality/continuity of the media, or drop frames to avoid a (potentially increasing) backlog. SDK uses queues with a finite buffer for incoming media, which will drop older buffers when full. When queuing frames, we are of course introducing latency (an incoming media frame is held onto and processed later). Queues should be tuned to balance excessive latency (buffer too large) whilst maintaining quality by avoiding dropping buffers if possible (enough buffer to smooth occasional slow-processing).

The experimental queue diagnostics feature allows the application to enable tracing of queue overruns. The log output can be “spammy”, so we advise switching on for one feed at a time to get a clear picture rather than interleaving output in the log.

Enabling diagnostics only requires you to make a request on the feed, but importantly the feed must have started before diagnostics can be enabled, to set up the appropriate pipeline hooks.

// Include the FeedDiagnosticsRequest header
#include <PxMedia/FeedDiagnosticsRequest.h>

// When the feed starts, enable the diagnostics using a given log level for output
someFeed->onFeedStarted(
    [](auto& feed)
    {
        std::cout << "Feed " << feed->streamId() << " started playing" << std::endl;
        auto diagnostics = feed->feedRequest(experimental::FeedDiagnosticsRequest(LOG_LEVEL));
        if (!diagnostics) {
            // Failed to enable diagnostics, check diagnostics.error() for cause
        }
    });

When enabled, the log will output when the pipeline’s queue is overrunning, including the buffer size which indicates the potential latency introduced by the queue’s buffering.

` [INFO] MediaPipeline [webcam] queue [queue6]: OVERRUN (100ms) `

Peer streaming encryption key length increased

The length of the encryption key used for peer streaming has been increased to 256 bits. This improves the security of peer-to-peer connections.