search

steveseguin / vdo.ninja

VDO.Ninja is a powerful tool that lets you bring remote video feeds into OBS or other studio software via WebRTC.
https://vdo.ninja
Other
2.83k stars 809 forks source link

Some people disappearing or some losing sound #971

Closed superseby2 closed 2 years ago

superseby2 commented 2 years ago

Thank you so much @steveseguin for such an amazing product!

So far I have been using it with max 2 people in a room and everything went smoothly everytime. But the other day, we organized an event with 7 people and we experienced 2 things :

I suspect it could be turn related as some of us were from offices and might have been annoyed with firewall rules (I didn't change the default settings of turnservers). Note: one of the participant was on his mobile.

Regarding the version I am using, as silly as it sounds, It appears that I simply used the main branch :( (last commit being from 2022-04-30). I will definitively switch to v21.2.

Would you have any pointers for me to help me know where/what/how to debug?

Thanks again.

superseby2 commented 2 years ago

Reading your documentation. Could it be websocket related with potential problems on your public wss api? (that might not explain the sound problems though :thinking: ). Our event was yesterday 2022-07-07.

steveseguin commented 2 years ago

Hey supersby2,

I would suggest that you use the stable branch; v21.2, as that's what's pretty much on https://vdo.ninja/ It's based on code that's largely been solid for a few months now.

That said, I've had two reports in the last couple months of audio not working always between participants; I've yet to fully identify the issue for that, but it tended to be in a larger room (while using vdo.ninja), with CPU overload perhaps being the problem in that case.

Firefox or Safari has been an issue for me in the past; Safari in particular has a bit of a bug where if reconnecting, it might not always reconnect with everyone. I can replicate this issue in any size room, and I've yet to fully fix it; it's due to a bug where Safari doesn't go into a disconnected state despite the remote guest disconnecting.

7 people can be a bit much for older mobile devices. In those cases, I'd add &roombitrate=0 to the mobile user, so their camera is only shared with the director, or I'd add &broadcast mode to all guests, and have just the director share video with the group. The goal here would be to have the underpowered guests to not send video to everyone in the room; just audio. Rather, they send video only to the director/scene.

With version v22-beta, I've been trying to work out these issues, adding in more smarts for mobile devices and fix the safari issue. I haven't fixed the sound drop-out problem yet, which happens where a CPU is overloaded, but it's on my to do list to try solving it again.

Understanding the device/browser that each guest had, and who wasn't able to see who, can help identify where the problems are in the network and maybe what is causing them.

You can use https://vdo.ninja/ in any tests as well, as I don't often get people mentioning issues failed peer connections with that version.

The websocket server has historically been pretty stable. If someone can't connect to it, then reconnecting shouldn't fix it. It can be an issue if you have 100's of people joining from the same IP address however, as flood protection will kick in then.

I'd be happy to try to replicate your setup here and see if I can replicate the issue; I'd just need to know browser + devices and any special URL settings used.

superseby2 commented 2 years ago

Thank you Steve !

I've switched to v21.2 now.

Now that you mentioned CPU overload. I was broadcasting myself and being the director on my small 4cores old laptop and my CPU went over the roof. Could it be me the weak point , impacting others ?

I read more about broadcast mode. I will definitively try it. I may need to host the director on some better hardware as, as I understand it, more stress will be put on it.

I will gather specs of the guests and get a better understanding on who had issue and when during the cast.

I'll update back when I know more.

Thanks again.

superseby2 commented 2 years ago

Already got one feedback from one of them. Setup : Chrome/MacOs / Regular DSL Box He got many times the message in attachment

image

Retrying many times by reloading the page. It finally managed to get in

steveseguin commented 2 years ago

Where are they located?

Was their connection bad? Were they on a VPN?

That message, if it appears a lot, implies a bad connection to the websocket server. It's hosted on Google Cloud tho, so that's unusual.

If you add &proxy to the guest's URL, it will try to connect via Cloudflares edge nodes instead

I'd suggest your guests not use Wifi if at possible. It is possible for me to deploy something closer to your guest, but that may not be enough.

On Fri., Jul. 8, 2022, 4:47 a.m. superseby2, @.***> wrote:

Already got one feedback from one of them. Setup : Chrome/MacOs / Regular DSL Box He got many times the message in attachment

[image: image] https://user-images.githubusercontent.com/32198925/177954635-6378b44d-5e14-4351-b3f3-755688d8eef8.png

— Reply to this email directly, view it on GitHub https://github.com/steveseguin/vdo.ninja/issues/971#issuecomment-1178724868, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATU2UWUYR76JUG7V4N5DFDVS7TKVANCNFSM527X5BHA . You are receiving this because you were mentioned. Message ID: @.***>

superseby2 commented 2 years ago

Sorry for the super late reply. I could not manage to have more feedbacks from my guests. I've planned more room conferencing soon, will try to have everyone on LAN (tough to do those days). I will report back if the issue raises again. Thanks again.