Skip to content

webrtcsink: don't panic if input CAPS are not supported

If a user constrained the supported CAPS, for instance using video-caps:

gst-launch-1.0 videotestsrc ! video/x-raw,format=I420 ! x264enc \
    ! webrtcsink video-caps=video/x-vp8

... a panic would occur which was internally caught without the user being informed except for the following message which was written to stderr:

thread 'tokio-runtime-worker' panicked at net/webrtc/src/webrtcsink/imp.rs:3533:22: expected audio or video raw caps: video/x-h264, [...]
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

The pipeline kept running.

This commit converts the panic into an Error which bubbles up as an element StreamError::CodecNotFound which can be handled by the application. With the above gst-launch, this terminates the pipeline with:

[...] ERROR webrtcsink net/webrtc/src/webrtcsink/imp.rs:3771:gstrswebrtc:: webrtcsink::imp::BaseWebRTCSink::start_stream_discovery_if_needed::{{closure}}: Error running discovery: Unsupported caps: video/x-h264, [...]
ERROR: from element /GstPipeline:pipeline0/GstWebRTCSink:webrtcsink0: There is no codec present that can handle the stream's type.
Additional debug info:
net/webrtc/src/webrtcsink/imp.rs(3772): gstrswebrtc::webrtcsink::imp::BaseWebRTCSink:: start_stream_discovery_if_needed::{{closure}} (): /GstPipeline:pipeline0/GstWebRTCSink:webrtcsink0: Failed to look up output caps: Unsupported caps: video/x-h264, [...]
Execution ended after 0:00:00.055716661
Setting pipeline to NULL ...

Merge request reports