libpeer
libpeer copied to clipboard
recording example receives/records nothing
Browser asks to select screencast capture source, I choose one to share. In console it prints just:
Listening 0.0.0.0:8000
No file gets created in the directory of executable (CWD). Tested both with google-chrome and chromium with the same result.
Do you connect with internet? Because the default STUN server is 18.191.223.12
Yes.
I tracked down the problem and here is the workaround diff which makes example work (record.h264 gets saved):
--- a/examples/recording/index_html.h
+++ b/examples/recording/index_html.h
@@ -13,6 +13,7 @@ const char index_html[] = " \
<body> \n \
<video style='display:block; margin: 0 auto;' id='localVideo' autoplay muted></video> \n \
<script> \n \
+ var counter=0; \n \
function jsonRpc(payload, cb) { \n \
var xhttp = new XMLHttpRequest(); \n \
xhttp.onreadystatechange = function() { \n \
@@ -45,7 +46,14 @@ console.log(JSON.parse(atob(sdp))); \n\
} \n \
} \n \
pc.onicecandidate = event => { \n \
- if (event.candidate === null) { \n \
+ counter++; \n \
+ console.log(\"counter = \" + String(counter)); \n \
+ console.log(event); \n \
+ if (event.candidate === null || event.candidate.address.length > 15) { \n \
+ console.log(\"ignoring this event\") \n \
+ } \n \
+ else \n \
+ { \n \
let sdp = pc.localDescription.sdp; \n \
var payload = {\"jsonrpc\": \"2.0\", \"method\": \"call\", \"params\": btoa(sdp)}; \n \
jsonRpc(payload, jsonRpcHandle); \n \
(counter is used only for debugging.)
OK, Thanks!
I have no experience with javascript and the workaround was found just empirically. It definitely needs a more correct approach.
I see you ignoring the ice candidate which the length of address is larger than 15. I guess it is a mDNS address. I tried to remove it and transfer to a ipv4 address, but it still seems to have some problems. I will check that.
I'm not only ignoring candidates which are not IPs basically, but since there is only one IP candidate, jsonRpc is called only once. Otherwise, setRemoteDescription was called 2 times what caused an error.
Without my changes jsonRpc was not called at all, because the condition for calling was event.candidate === null (now it's the opposite).
I used chrome://webrtc-internals for debugging.
According to the onicecanidate API, if the event's candidate property is null, ICE gathering has finished. It should be waited until all candidates are obtained, then send the offer. So you don't get event with null candidate property?
So you don't get event with null candidate property?
It seems the browser does not get event with null candidate property. Log without workaround:
11/29/2021, 2:07:23 PM transceiverAdded
11/29/2021, 2:07:23 PM createOffer
11/29/2021, 2:07:23 PM negotiationneeded
11/29/2021, 2:07:23 PM createOfferOnSuccess (type: "offer", 2 sections)
11/29/2021, 2:07:23 PM setLocalDescription (type: "offer", 2 sections)
11/29/2021, 2:07:23 PM setLocalDescriptionOnSuccess
11/29/2021, 2:07:23 PM signalingstatechange
11/29/2021, 2:07:23 PM transceiverModified
11/29/2021, 2:07:23 PM icegatheringstatechange
11/29/2021, 2:07:23 PM icecandidate (host)
11/29/2021, 2:07:23 PM icecandidate (srflx)
When workaround is in use the log continues further with setRemoteDescription (type: "answer", 2 sections).
After getting null candidate, the browser should call jsonRpc function to send the offer to recording program. When recording program accepts the offer and response an answer, browser should be callback to jsonRpcHandle and setRemoteDescription.
I think the recording program doesn't response the answer, because mDNS parse failed or it need more time to resolve.
I created a branch to disable mDNS resolver. If possible, please try again. Thanks.
This example is no longer supported