gst-plugins-rs/net/webrtc/examples
François Laignel cc43935036 webrtc: add precise synchronization example
This example demonstrates a sender / receiver setup which ensures precise
synchronization of multiple streams in a single session.

[RFC 6051]-style rapid synchronization of RTP streams is available as an option.
See the [Instantaneous RTP synchronization...] blog post for details about this
mode and an example based on RTSP instead of WebRTC.

[RFC 6051]: https://datatracker.ietf.org/doc/html/rfc6051
[Instantaneous RTP synchronization...]: https://coaxion.net/blog/2022/05/instantaneous-rtp-synchronization-retrieval-of-absolute-sender-clock-times-with-gstreamer/

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1463>
2024-04-03 19:10:40 +02:00
..
webrtcsink-custom-signaller webrtc: Remove unnecessary manual Send+Sync implementations for signallers 2024-01-18 10:01:25 +02:00
webrtcsink-stats webrtc: examples: Update package-lock.json 2022-12-26 23:10:40 +00:00
README.md webrtc: add precise synchronization example 2024-04-03 19:10:40 +02:00
webrtc-precise-sync-recv.rs webrtc: add precise synchronization example 2024-04-03 19:10:40 +02:00
webrtc-precise-sync-send.rs webrtc: add precise synchronization example 2024-04-03 19:10:40 +02:00
webrtcsink-high-quality-tune.rs webrtcsink: expose consumer-pipeline-created signal 2023-05-25 13:15:52 +02:00
webrtcsink-stats-server.rs use new debug and parse API 2023-12-04 15:58:21 +01:00

webrtcsink examples

Collection of webrtcsink examples

webrtcsink-stats-server

A simple application that instantiates a webrtcsink and serves stats over websockets.

The application expects a signalling server to be running at ws://localhost:8443, similar to the usage example in the main README.

cargo run --example webrtcsink-stats-server

Once it is running, follow the instruction in the webrtcsink-stats folder to run an example client.

webrtcsink-custom-signaller

An example of custom signaller implementation, see the corresponding README for more details on code and usage.

WebRTC precise synchronization example

This example demonstrates a sender / receiver setup which ensures precise synchronization of multiple streams in a single session.

RFC 6051-style rapid synchronization of RTP streams is available as an option. Se the Instantaneous RTP synchronization... blog post for details about this mode and an example based on RTSP instead of WebRTC.

Signaller

The example uses the default WebRTC signaller. Launch it using the following command:

cargo run --bin gst-webrtc-signalling-server

Receiver

The receiver awaits for new audio & video stream publishers and render the streams using auto sink elements. Launch it using the following command:

cargo r --example webrtc-precise-sync-recv

The default configuration should work for a local test. For a multi-host setup, see the available options:

cargo r --example webrtc-precise-sync-recv -- --help

E.g.: the following will force avdec_h264 over hardware decoders, activate debug logs for the receiver and connect to the signalling server at the specified address:

GST_PLUGIN_FEATURE_RANK=avdec_h264:512 \
WEBRTC_PRECISE_SYNC_RECV_LOG=debug \
cargo r --example webrtc-precise-sync-recv -- --server 192.168.1.22

Sender

The sender publishes audio & video test streams. Launch it using the following command:

cargo r --example webrtc-precise-sync-send

The default configuration should work for a local test. For a multi-host setup, to set the number of audio / video streams, to enable rapid synchronization or to force the video encoder, see the available options:

cargo r --example webrtc-precise-sync-send -- --help

E.g.: the following will force H264 and x264enc over hardware encoders, activate debug logs for the sender and connect to the signalling server at the specified address:

GST_PLUGIN_FEATURE_RANK=264enc:512 \
WEBRTC_PRECISE_SYNC_SEND_LOG=debug \
cargo r --example webrtc-precise-sync-send -- \
  --server 192.168.1.22 --video-caps video/x-h264

The pipeline latency

The --pipeline-latency argument configures a static latency of 1s by default. This needs to be higher than the sum of the sender latency and the receiver latency of the receiver with the highest latency. As this can't be known automatically and depends on many factors, this has to be known for the overall system and configured accordingly.

The default configuration is on the safe side and favors synchronization over low latency. Depending on the use case, shorter or larger values should be used.