a=fingerprint:sha-256 (null)
neilyoung opened this issue · 13 comments
This is the content of an SDP offer generated by the Python sample code on a Raspberry PI 3A+. I had this issue already last year with Java, that time it was the missing srtp plugin for gstreamer-plugins-bad.
The GStreamer 1.0 installation on the PI is of version 1.14.4, srtp is supposed to be installed.
What might be the reason for this missing fingerprint?
I had a similar problem on the PI, where the end result was the same as for you (sha-256 null). Do you get any error/warnings with GST_DEBUG?
How i solved it:
According to ISSUE-811 you can test if it is a basic--gstreamer problem with: "gst-inspect-1.0 dtlsdec".It returned with errors for me. As mentioned in the issue to fix it, set "OPENSSL_CONF env variable to an empty string" and it worked. Both, the "gst-inspect-1.0 dtlsdec" command and the webrtc-connection.
Note: I also installed manually another openssl-version (same as on my desktop-pc, where it was runnnig fine). Unfortunately, i currently have no access to the PI to be sure what solved it in the end...But going for the env-variable will be the better start anyhow
Interesting. Thanks for the pointer. Did you set the OPENSSL_CONF in the environment?
How did you install GStreamer?
I don't have that plugin
pi@raspi:~ $ gst-inspect-1.0 dtlsdec
No such element or plugin 'dtlsdec'
I installed Gstreamer via the "apt install gst....". An example command can be found in the readme of this repo, which should cover all the packages (I installed gst myself already before so I did not try it). Note, the dtlsdec is part of "gst-plugins-bad".
I can confirm that setting OPENSSL_CONF="" solved the issue for me with GStreamer 1.14.4.
Cool. Will give it a try now.
Very cool. Yes, on a fresh Raspbian Buster the trick really worked. First an error on enumeration:
gst-inspect-1.0 dtlsdec
** (gst-inspect-1.0:13181): CRITICAL **: 14:30:38.190: file gstdtlsagent.c: line 192 (gst_dtls_agent_init): should not be reached
then, after export OPENSSL_CONF="" error gone and kind of certificate in output :)
Looking forward to test the entire solution now.
Thanks a lot. Will return and report
So the ping-pong ball is rolling in the browser window. Now I would like to access the CSI cam of the RPI. Any hint, how this can be achieved?
Install rpicamsrc from https://github.com/thaytan/gst-rpicamsrc/ and use the rpicamsrc element to replace the videotestsrc and x264enc in the pipeline
Almost :) Thanks for the suggestion and nice to meet you again. I'm able to connect and a still image appears (still using vp8enc, but that shouldn't mater I think), but then the python webrct_sendrcv.py terminates with
Traceback (most recent call last):
File "webrtc_sendrcv.py", line 103, in on_incoming_decodebin_stream
self.pipe.add(q, conv, resample, sink)
TypeError: Gst.Bin.add() takes exactly 2 arguments (5 given)
Traceback (most recent call last):
File "webrtc_sendrcv.py", line 93, in on_incoming_decodebin_stream
self.pipe.add(q, conv, sink)
TypeError: Gst.Bin.add() takes exactly 2 arguments (4 given)
Happens on the incoming audio stream.
I think we're getting a bit off topic for this issue. Take a look at https://github.com/thaytan/gst-rpicamsrc/blob/master/examples/webrtc-unidirectional-h264.c for example of streaming H.264 directly from the RPi hardware encoder.
I was only just keen, if gst has become a bit more handy meanwhile. I'm fine with the UV4L webrtc service, so why bother...
Thanks anyway
Sorry! I didn't mean to say stop - just that we might rename the issue or move to a new one.
No issue. It stopped me at the right moment :) I would just have wasted time. I'm having a very well running UV4L based solution, it was just a matter of interest...