Black screen in voip call when other side shows their webcam

[babolivier]

Steps to reproduce

1. Create a voip video call
2. 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: 85f6c3b-react-18c82d57ae0a-js-16ca09eed811, olm version: 3.2.8

Homeserver

abolivier.bzh

Will you send logs?

Yes

[SimonBrandner]

Is this reproducible? Are they also on Element Web/Desktop?

[babolivier]

Not sure how reproducible this is. They're on Element Desktop, and have rageshaken.

[callahad]

Just had the same occur: @afranke couldn't see my video. I'm using Element Web Nightly on Firefox 96.

[adminibt]

Same problem here. We are using Element Desktop 1.9.8 (Windows). This is not reproducible. Is there any way we can help?

[SimonBrandner]

Are all people experiencing this on develop?

Possibly regressed by matrix-org/matrix-js-sdk#2104, CC @dbkr

[lukasIO]

Experiencing the same problem
Version Desktop Element: 1.9.9

[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.

[dbkr]

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.

[SimonBrandner]

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 🤔

I can't reproduce the bug either.

Neither can I

[lukasIO]

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...

[w4tsn]

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) 🤷 It does not seem to matter if the peer is on Windows or Linux I think, I've seen this problem with both

[dbkr]

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.

[dbkr]

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?)

[babolivier]

In my case it's indeed only the video that's missing.

[afranke]

Yep, with @callahad I’m getting his voice but not his video.

[dbkr]

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).

[dbkr]

Have added logging in matrix-org/matrix-react-sdk#7721 to try & catch this: once that's merged, please continue sending bug reports whenever you see this bug.

[novocaine]

We haven't received reports of this for a few days - are people still experiencing it?

[SimonBrandner]

Probably a long shot but matrix-org/matrix-js-sdk#2157 could have had some effect?

[ara4n]

This could be the same bug which is causing grey tiles in matrix-video-chat (element-hq/element-call#211)

[adminibt]

We still have this problem. Using Element Desktop 1.10.1.

[t3chguy]

matrix-org/matrix-js-sdk#2157 is not included in 1.10.1 given it only merged 3 days ago.

[novocaine]

@lukasIO are you still experiencing this?

[lukasIO]

Since (more or less) two days the issues have stopped showing up for me 🎉

[SimonBrandner]

Is anyone else seeing this, or can we close this now?

[novocaine]

Let's close it for now, can re-open if someone is still experiencing it

[afranke]

It just happened again to me with @jsparber (he could see me, but I only saw a black screen instead of their image).

[babolivier]

Just had this issue with @MatMaul, we're both rageshaking

[dbkr]

Again, nothing particularly informative in these logs unfortunately. Any particular things you're doing when experiencing this?

[babolivier]

Again, nothing particularly informative in these logs unfortunately. Any particular things you're doing when experiencing this?

Nope, just started a video call. I had a few calls with Mathieu in the past few weeks and they worked fine, but I was using a different connection, so it's probably related to some broadband providers' network configs (though Jitsi didn't have this issue). We tried terminating the call and have him call me (I initiated the first call) and the issue was still there.

[dbkr]

Hmm, network config is unlikely to make one stream work where the others were fine (unless it's a really, really low-bandwidth connection). If you are able to inspect the streams with webrtc-internals as above that could provide inspiration, or if there's a certain reliable way of reproducing it.

I'm going to remove the regression label as this was added when we thought it might be regressed by a certain PR, but it looks like it's not that simple.

[xBelladonna]

I have been experiencing this issue and perhaps a related one, but it may be the same thing. I call regularly with my friend and their webcam often starts black, but they have several cameras and toggling between them seems to fix the issue for the duration of the call. In addition, I also seem to experience the same problem, but I have no additional cameras. However, toggling the audio input device away from default and back again seems to do the trick oddly enough! Both of us see the same thing on our respective local machines: a 1:1 black square where our video previews should be, and receiving black frames from the other. I thought I'd comment here before opening a new issue both since it's possibly the same issue and also possibly fixed by Element Call. If it is indeed new, I can open another issue.