element-web
element-web copied to clipboard
element-hq
Black screen in voip call when other side shows their webcam
Steps to reproduce
- Create a voip video call
- Black screen instead of camera
Outcome
What did you expect?
The other side's camera shows up
What happened instead?
Black screen shows up
There's an error in the javascript console: "DOMException: The fetching process for the media resource was aborted by the user agent at the user's request."
Will rageshake, and ask my friend to do it as well.
Operating system
Arch Linux
Browser information
Firefox 96.0
URL for webapp
develop.element.io
Application version
Element version: 85f6c3b21f80-react-18c82d57ae0a-js-16ca09eed811, olm version: 3.2.8
Homeserver
abolivier.bzh
Will you send logs?
Yes
Not sure how reproducible this is. They're on Element Desktop, and have rageshaken.
Just had the same occur: @afranke couldn't see my video. I'm using Element Web Nightly on Firefox 96.
Same problem here. We are using Element Desktop 1.9.8 (Windows). This is not reproducible. Is there any way we can help?
Are all people experiencing this on develop?
Possibly regressed by https://github.com/matrix-org/matrix-js-sdk/pull/2104, CC @dbkr
The errors in the rageshake look like ones we get often due to the fact that we pause the media element when changing the feed, so the previous play request just doesn't work and throws that exception, but then we call play again anyway, so I don't think they're relevant. I'm not sure what else it would be though: I can't really see how that change would cause it, and I can't reproduce the bug either.
Oh, but given the range of versions above (1.9.8, 1.9.9, develop, nightly) it doesn't appear specific to develop/nightly, so not a release blocker.
The errors in the rageshake look like ones we get often due to the fact that we pause the media element when changing the feed, so the previous play request just doesn't work and throws that exception, but then we call play again anyway, so I don't think they're relevant.
Yeah, I don't think those are very relevant either.
I'm not sure what else it would be though: I can't really see how that change would cause it, and
It was more of a long shot, though I wonder what changed that people are seeing this a lot now :thinking:
I can't reproduce the bug either.
Neither can I
Are there any additional infos that we can provide to help you reproduce this? It's blocking our daily use on ems.host right now...
This is also happening to us on ems.host at the moment. Element version of me and my peer I tested with is 1.9.9, I'm using Desktop on Fedora Linux and my peer is using it on Windows. If my peer switches to Android it works while it reproduces consistently with this peer when using Desktop. Peer is on another home server though. Also happens with other colleagues from same home server but not as consistent. Seems to happen more often when I start a call. When they call me back it usually works (but not today with the peer I test with) :shrug: It does not seem to matter if the peer is on Windows or Linux I think, I've seen this problem with both
I still can't reproduce this with any combination of desktop / chrome / firefox calling each other. If anyone feels confident doing so, I'd like to know if the side with the black screen is receiving video or not, which you can find you by going to (in chrome) chrome://webrtc-internals, finding the right tab for element's browser tab and finding the "Stats graphs for RTCInboundRTPVideoStream_xxxxxxxxxx (inbound-rtp)" (where the x's are some numbers). You should be able to tell fairly easily whether it's getting video (number of packets & frames increasing) or not, eg. here's mine getting video:
If it is getting video, you could try right-clicking the video, choosing 'inspect', then you can refer to that video element as $0 in the console and see if telling it to play manually helps: $0.play():
We can also try to add more debugging to track down what's going on here.
Just as a note: for us this is happening very consistently (=always) and is not limited to video. There's neither audio nor video. I'll try to get the webrtc insights in the next call.
OK, if you're not getting any media at all then that's a very different problem and would want a separate issue. I assume for others this is just the video that is missing and the audio is fine both ways (or have I completely mis-interpreted this issue?)
Just made another call and this time my local video preview was frozen on one side. It's possible this could be the same issue. I could un-freeze it by making a new MediaStream object and adding just the video track from the old stream to the new one, then setting the new stream as the source (ie. making a new stream with no audio track).
Have added logging in https://github.com/matrix-org/matrix-react-sdk/pull/7721 to try & catch this: once that's merged, please continue sending bug reports whenever you see this bug.
We haven't received reports of this for a few days - are people still experiencing it?
Probably a long shot but https://github.com/matrix-org/matrix-js-sdk/pull/2157 could have had some effect?
This could be the same bug which is causing grey tiles in matrix-video-chat (https://github.com/vector-im/matrix-video-chat/issues/211)
https://github.com/matrix-org/matrix-js-sdk/pull/2157 is not included in 1.10.1 given it only merged 3 days ago.
It just happened again to me with @jsparber (he could see me, but I only saw a black screen instead of their image).
Again, nothing particularly informative in these logs unfortunately. Any particular things you're doing when experiencing this?