6.1.1. Release notes for v0.18
6.1.1.1. v0.18.0
API changes and deprecations
Builder pattern for feeds with multiple/optional components
As the SDK has evolved, certain feed types have increased the number of components that they may take. This has led to lengthy parameter lists and the need for multiple overloaded creation functions to cover different combinations and optionality of components.
To address this, we are introducing a builder pattern for feeds with lengthy creation parameter lists. The following feed types have been updated to support the builder pattern:
For these classes, the existing create factory functions:
Remain for basic feed creation, but generally limited to required parameters and possibly a single optional trailing component for convenience.
Other existing (over-)overloaded
createfunctions that allowed different optionality combinations are now deprecated: instead use the builder form to create feeds with additional optional components.
Example:
// Previously: components in long parameter list
auto created = MediaServerOutgoingVideoFeed::create(mediaSession, props, inputVideo, localOut, monitorOut);
// Now: Use builder pattern to specify additional optional components in a clear way
auto created = PxMedia::MediaServerOutgoingVideoFeed::Builder(mediaSession, props, inputVideo)
.localOutput(localOut)
.monitorOutput(monitorOut)
.create();
# Previously: components in long parameter list
created = media.MediaServerOutgoingVideoFeed.create(media_session, props, input_video, local_out, monitor_out)
# Now: Use builder pattern to specify additional optional components in a clear way
created = (
media.MediaServerOutgoingVideoFeed.Builder(media_session, props, input_video)
.local_output(local_out)
.monitor_output(monitor_out)
.create()
)
Release and packaging changes
New feature: Python SDK
The Proximie SDK is now available in Python, in addition to C++. The Python SDK provides bindings to the same underlying C++ SDK functionality, allowing developers to use the Proximie SDK from Python applications.
Many sections of the documentation have been updated, including:
Getting Started: added instructions related to obtaining and using the Python SDK
Sample applications: added instructions for obtaining and running Python sample applications
SDK reference: added a new reference section for the Python SDK
All included code snippets now display tabbed C++/Python versions
APT Package changes
A new
python3-pxsdkpackage has been added to our public APT repository, providing the Proximie SDK for Python.The
pxsdkutility command that was previously installed by thepxsdk-devpackage is now installed by the mainpxsdkpackage, and will prompt the user to install additional packages if required by a given command (e.g.,pxsdk python-sampleswill prompt to installpython3-pxsdkif not already installed).
Release archive changes
The release archive now includes Python bindings in a
python/subdirectory, in addition to the existing C++ SDK files.A helper script,
setup_env.sh, is provided undersamples/python/to configure the required environment variables for using the Python SDK.Python sample applications are now included in the release archive, under the
samples/python/directory. C++ samples have been moved tosamples/cpp/for consistency.
SBOM for Python deployments
A dedicated Software Bill of Materials (SBOM) is now published for Python deployments (the
python3-pxsdk package). It wraps the C++ SBOM and adds the Python-specific components: the
CPython interpreter, the pybind11 framework, and the compiled extension module. It is included
in the python3-pxsdk APT package and the release archive. See
Software Bill of Materials for more details.
Other changes
Sample applications updated with headless/UDP video output options
Several sample applications have been updated with new command-line options to support headless (no-display) operation and programmatic testing via UDP/RTP video output:
--video-output: selects the video output mode —window(default),udp(send encoded H.264/RTP to a UDP port), ornone(discard video, no display required).--udp-port: sets the UDP port used with--video-output=udp(default: 5004).--audiosink=none: discards audio output without requiring a display or audio device.--run-time: configures the demo duration in seconds (hello-sdkandreusable-inputs).
These options are available on hello-sdk, stages, reusable-inputs, peer-simplex,
and peer-duplex. See Running samples for details.
New Features
New experimental feature: Component-based adaptive streaming
The SDK now offers a more flexible adaptive streaming system built on top of feed components and
the FeedRequest mechanism. This will supersede the existing
adaptive streaming approach with a design that allows individual components to express their own
quality adaptation logic.
New APIs (all in the Proximie::PxMedia::experimental namespace):
VideoAdaptiveFrameRateComponent- a feed component that adjusts the outgoing video frame rate based on a quality level.VideoAdaptiveResolutionComponent- a feed component that adjusts the outgoing video resolution based on a quality level.RequestAdaptiveQuality- aFeedRequestthat sets a given quality level on a feed.
Additionally, WebRTC encoders (e.g. VideoWebRtcEncodeFeedVp8)
support the same quality level mechanism, which is set on the encoder component itself. The
hardware H264VaapiEncoderComponent supports adaptation across all
levers (bit rate, frame rate and resolution) and automatically clamps its bit rate to remain safe
at very low resolutions/frame rates.
Components are configured with a set of quality bands that map quality levels onto target values, and added to the feed when it is created.
Once a feed is running, quality is adjusted by sending a RequestAdaptiveQuality request.
The existing FeedQualityMonitor can drive quality requests
automatically based on WebRTC stats, as before.
A new adaptive-streaming sample application demonstrates the full workflow including
quality monitoring and manual quality overrides.
See Adaptive Streaming (Experimental) for a full guide and code examples.
Note
We expect this approach to replace the existing adaptive streaming system in a future release. The existing Adaptive Streaming APIs remain unchanged and supported.
Other changes
Sample applications updated with headless/UDP video output options
Several sample applications have been updated with new command-line options to support headless (no-display) operation and programmatic testing via UDP/RTP video output:
--video-output: selects the video output mode —window(default),udp(send encoded H.264/RTP to a UDP port), ornone(discard video, no display required).--udp-port: sets the UDP port used with--video-output=udp(default: 5004).--audiosink=none: discards audio output without requiring a display or audio device.--run-time: configures the demo duration in seconds (hello-sdkandreusable-inputs).
These options are available on hello-sdk, stages, reusable-inputs, peer-simplex,
and peer-duplex. See Running samples for details.
New sample: Wayland desktop capture
A new wayland-capture sample application demonstrates how to capture the desktop on Wayland
using the XDG Desktop Portal and the SDK’s
VideoInputFeedPipewire component. The sample
performs the full portal negotiation (session creation, source selection, stream start, and
PipeWire fd acquisition) using GDBus, then displays the captured screen in a local preview
window. When portal negotiation fails, the sample distinguishes a user-cancelled request from
an unavailable xdg-desktop-portal/PipeWire backend, and its docs cover the headless/Docker
screen-picker limitations.
See Running samples for prerequisites and usage.
New experimental feature: Annotation/Telestration event receipt
MediaServerSession now supports receiving real-time
annotation (telestration) events from other participants in a session.
Warning
Experimental — this API may change or be removed in a future release.
Annotation methods are accessed via mediaSession->experimental():
experimental().subscribeToAnnotations()/experimental().unsubscribeFromAnnotations()to manage per-stream subscriptionsexperimental().onAnnotationReceived()callback delivers live annotation events as they arriveexperimental().fetchAnnotationHistory()retrieves persisted annotation history via RESTSubscriptions are local state and persist across reconnections
Event payload shape matches the history REST response:
[seqNum, profileId, {command, params, streamId}, timestamp, userId]
See Media Server Services for usage details.