Hi All,
We are Experiencing difficulty in Playing WebRTC Desktop Capture streams in some networks.
publishing desktop capture using getDisplayMedia API to Wowza has no issues. I can record the stream in server and playback smoothly.
Some of our clients can also view the streams perfectly.But most of the clients faces difficulties.
Some are viewing black screen and some other are viewing scrambled images.
so we thought it was network issue and analyzed using packet capture .
Observed that ICE candidate exchange happens but few UDP packets are coming from server.
reduced the screen capture resolution from 1280x720 to 640x480 using constraints , then packets are arriving properly and playback occurs smoothly
UDP packet size is less than 1000 in 640x480 resolution.
packet size is 1372 in 1280x720 resolution.
IS it a UDP streaming issue? or network issues? is wowza has any configuration to control this behavior?
ONLY UDP is enabled in ICE Candidate Setup .
Publish Video Codecs is h264
Browser used for testing Google Chrome & Firefox
We are totally clueless. Any help will be greatful.
Welcome @Prasanth_Raom due to the complexity of webrtc configuration, accurate troubleshooting will require a support ticket.
What we can do in the forums is offer some guidance as far as documentation:
- You should have nack enabled as well as instructed in the webrtc doc here:
- If you use UDP ICE candidates, enabling NACK messages is recommended to allow for retransmission of lost packets. See the optional RTP properties in Configure a live application for information about how to enable NACK with Wowza Streaming Engine XML.
- You can enable both TCP and UDP as ice candidates and have TCP as first priority and UDP second. UDP is required for FIrefox so you can have both and your Firefox users will still be able to connect.
If needed, add additional ICE Candidates, and adjust their preferred order using the Priority up and down arrows.
- I would strongly advise you to add and enable nack with the jitter buffer since you are using UDP. See the steps here.
This is just one setting you need to change to TRUE. Please click the link above and configure them all for jitter buffer.
As far as issues your viewers are having with screen capture, following the suggestions above will help, but did did you see this in the docs?
- Screen share functionality for the hosted WebRTC publish and composite test pages is not available on mobile devices, Safari, or Firefox.
Again, please submit a support ticket if you continue to have issues, so we can review your webrtc configuration.
Thank you for the quick reply.
Removed TCP candidate,Enabled NACK,enabled jitter buffer;
Sorry, but no difference observed. I think some ISPs limit udp packets which are larger than MTU 1200. I am not an expert on this matter anyway.
If possible please inform Wowza Dev team about this issue.
Requested my client to raise support ticket on this issue.
There can be a problem with jumbo MTUs. In Germany some providers got problems when converting IPv4 <-> IPv6 packages (ds lite problem). So you souldn’t send packages larger than 1450.
You can munge your sdp file in a way, that the quality is handled automatically, (see here), but you said this doesn’t seem to be the issue.
Did you try installing a Turn server? You can simply install coturn with default settings and edit your PeerConnection in your application. Thereby you can force TCP.
Wowza Instance is running in a Cent OS server located in UK.
Thanks for pointing out the IP4/IP6 issue.
I tested using IP4 ADSL network and IP6 4G network.It worked in second one.But i dont have sufficient data to reach a conclusion.
In lower resolutions there is no issue where packet size is always less than 1000.
Difficulty comes in desktop resolutions like 1280x720 . that too not in the publishing side but in playback. when browser send data to Wowza, UDP Packet size are kept below 1200.
packet size is larger than 1200 when browser pull the stream from Wowza .
but can’t control the UDP packet size originating from Wowza.
I think there are setting to control this behaviour in udp-mpegts streaming but not in WebRTC.
.For WebRTC is there any SDP hacks?
Yes. I had tried TCP Ice Candidate and that worked. That’s how I came in to the consultation that its a UDP related issue. Currently using this as a workaround but lacks Firefox Support and performance issues like network disconnects.
