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 withRUST_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 ...