I am testing the demo publisher code cross browser. And the server is not initiating candidates with Edge browser and unpublishing itself automatically without a detailed log. Edge supports the webRTC api now.
The SDP mangling in the publisher demo breaks it but, so needs to be commented out, trying many things fails to get it working.
Does it need a turn server configured still ?
My configuration needs to be this to get Firefox even working
Edge browser support for WebRTC not Edge server. Well that is another support constraint altogether. So different origin servers are required for connectivity and publishing because Edge servers are not supported ? The systems I work on have origin and edge servers setup for HLS playback.
Live streaming has a requirement for 608 captions also, so the lack of data channels or sending embedded text tracks is a concern, and limit the use of WebRTC and may have to use in the future SRT mpegts publishing / HLS playback.
I fixed up the out of date demo code to work for Safari. So Chrome,Firefox and Safari is working. I can get Edge browser working up to recieving the remote stream which is blank, nothing is received, and it fails to continue further to adding the peer candidate. It should continue going through the candidate connection state of checking then connected but it doesn’t. Does it need a turn server ?
Hi @Daniel Rossi, thanks for clarifying you were inquiring about webrtc with edge browser. For WebRTC, we support Chrome/Firefox/Safari (limited). No support at this time for Microsoft Edge with WebRTC or any mobile platform. (please see the doc Alex linked to above).
We do provide Edge support for Wowza Player HLS playback, just not for webrtc workflows.
However, there are developers in our slack community experimenting with this and while we don’t officially support it right now, we encourage you to test and share your results in our webrtc slack here. You may find some of the old threads in there interesting and helpful.
Also, in your testing, remember that not all browsers support all codecs with WebRTC. H.264 is the most widely supported webrtc codec, but for best performance we recommend using VP8 video with Opus or Vorbis audio.
Or you can enable the transcoder and transmux it for testing.
Please review webrtc limitations and options here.
I tried to join slack, I think I already did but can’t back in ?. Its failing to gather candidates so won’t continue it requires udp debugging somehow. It doesnt use ORTC anymore.
Safari code is fixed up with my code above. It requires promises and not callbacks. Safari tests were not working.
I found a problem with publishing, wowza requires bitrate control or else the picture is pixelated, at least a max bitrate of 2000. I am still trying to find more limitations.
Chrome has a new api for dynamic max bitrate control and doesnt need sdp mangling, the other browsers still do, Im not sure yet if this will work with wowza. I’ll try and report my findings to slack then.
Chrome has a new api for selecting codecs which is returned in the offer sdp. The other browsers still need sdp mangling also.
I am implementing these changes in my forked simple-peer project and hopefully still works with wowza.
I want to move onto mobile testing next, and perhaps even see if ffmpeg / gstreamer webrtc publishing can work. If ffmpeg webrtc can work then OBS can be used for publishing via a plugin.