视频不流式传输

Question

I wrote a simple webapp for a huge amount of streamers. The streams are stable but audio/video not showing up.

Maybe you have a clue why.

See https://github.com/enexusde/Maven-Many-Videomeeting-RTC-OnlineServlet3.0

To start the app simply write mvn in the console, all goals are used from the maven defaultGoal.

Then start two browser tabs having the url http://localhost:8080/vc/.

Regards

Answer 1

I've forked and modified your project on GitHub. Working code and setup instructions can be found here .

Here is how it looks with 4 tabs open. You can see local session id on top right and corresponding sessions ids on each remote videos. I used VCam for debugging. That's why the trial text:

---

There are some issues to fix:

1. Major issue is the comparison if (y != "complete") . You are comparing event object with "complete" string. You end up sending offer SDP without any ICE candidate. Using if (self.peerConn.iceGatheringState === "complete") ref fixes part of the problem. With this change Receiver sees the Sender's video.
2. From Receiver side you create answer and send back SDP immediately . ICE candidate collections starts after you call createAnswer() or createOffer() . So you are sending SDP without any ICE candidates.
   After you fix this other issue is that on Sender side there are no onAddStream and streamEventsChangedHandler handlers. Thus Sender never gets to set received stream to corresponding <video> element.
3. RTCPeerConnection is capable of both sending and receiving video/audio streams with same connection object. You can set setRemoteDescription() on Sender as well. You don't have to maintain separate Sender and Receiver connection objects. Major improvement here could be you combine Sender and Receiver classes in to one Connection class. This way you create only n-1 connections, for n participants, at each participant side. And on server you need to track only n connections and not n*(n-1).
4. RTCPeerConnection.onaddstream is deprecated . Use RTCPeerConnection.ontrack property
5. Serve web pages over secure channel(HTTPS). Because browsers won't let your web page access media hardware over insecure(HTTP). ref . Localhost(127.0.0.1) is exception.
   You can configure tomcat7-maven-plugin in pom.xml to serve pages on HTTPs. Steps to setup HTTPs are in the README.md file.
6. You need to have more timeout delay . 2 seconds is very less. Clients may have very low latency streaming among them, due this direct P2P connection, and high latency connecting to your server. So if they can't connect to server doesn't mean they stopped communicating. Once you establish connection between clients the server's role is over until they logoff explicitly.
7. Due to Chrome autoplay policy you can't start playing other's video directly. So had to add an overly over the page to force user interaction. This won't be an issue once you have login implemented.
8. Acquire local media streams before you create Room object, preferably immediately after page load and before user get past overlay. If user delays providing device access permissions, your Room object will have already completed all connection procedures with other peers without sharing any local audio/video streams. If you handle it later you'll have to add tracks/streams to all connections again.
9. Did little bit of restructuring. On server side I moved public inner classes from MeetSessions.java to separate files. It was getting hard to understand the code. Something with the index.html .
   
   I've tested the code in LAN/Wi-Fi using Windows PC, Android phone, and tablet. If you host your server in public domain you may need TURN server as well for these reasons .