60f7f4a664
This commit adds support for raw payloads such as L24 audio to `webrtcsink` & `webrtcsrc`. Most changes take place within the `Codec` helper structure: * A `Codec` can now advertise a depayloader. This also ensures that a format not only can be decoded when necessary, but it can also be depayloaded in the first place. * It is possible to declare raw `Codec`s, meaning that their caps are compatible with a payloader and a depayloader without the need for an encoder and decoder. * Previous accessor `has_decoder` was renamed as `can_be_received` to account for codecs which can be handled by an available depayloader with or without the need for a decoder. * New codecs were added for the following formats: * L24, L16, L8 audio. * RAW video. The `webrtc-precise-sync` examples were updated to demonstrate streaming of raw audio or video.
4.7 KiB
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.
The examples can also be used for RFC 7273 NTP or PTP clock signalling and synchronization.
Finally, raw payloads (e.g. L24 audio) can be negotiated.
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:MAX \
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:MAX \
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.
RFC 7273 NTP or PTP clock signalling and synchronization
For RFC 7273 NTP or PTP clock signalling and synchronization, you can use commands such as:
Receiver
cargo r --example webrtc-precise-sync-recv -- --expect-clock-signalling
Sender
cargo r --example webrtc-precise-sync-send -- --clock ntp --do-clock-signalling \
--video-streams 0 --audio-streams 2
Raw payload
The sender can be instructed to send raw payloads.
This command will stream two stereo L24 streams:
cargo r --example webrtc-precise-sync-send -- \
--video-streams 0 --audio-streams 2 \
--audio-caps 'audio/x-raw,format=S24BE,rate=48000,channels=2'
Launch the receiver with:
cargo r --example webrtc-precise-sync-recv
This can be used to stream multiple RAW video streams forcing width and allowing fallback to VP8 & OPUS if remote doesn't support raw payloads:
cargo r --example webrtc-precise-sync-send -- \
--video-streams 2 --audio-streams 1 \
--video-caps 'video/x-raw,format=I420,width=400;video/x-vp8' \
--audio-caps 'audio/x-raw,format=S24BE,rate=48000,channels=2;video/x-opus'