I'm currently working on a library that sends a MediaStreamTrack from one electron window to another one via an RTCPeerConnection.
The problem I currently have is that everything works fine except remote tracks. A MediaStreamTrack of my camera is created on localhost and can be sent without any problem but when I'm trying to send a track, which I'm receiving from an external server, then it only shows black frames.
It's the same problem as here I guess.
What I've checked
The track is getting received (I checked chrome://webrtc-internals) and the video element is in a playing state. I don't see any errors, neither in the console nor in webrtc-internals.
Additionally the stream/track is enabled and not muted. Using captureStream() on the source window results in the same.
Capturing and streaming a video element with an external source is working without any problems.
Possible reason
I think the problem might be that the initial stream is coming from a domain that is not localhost and for which reason it is impossible to restream it. In the w3c standard, it is described as follows:
A track could have contents that are inaccessible to the application. This can be due to anything that would make a track CORS cross-origin. These tracks can be supplied to the addTrack() method, and have an RTCRtpSender created for them, but content MUST NOT be transmitted. Silence (audio), black frames (video) or equivalently absent content is sent in place of track content.
Idea
I'm not sure if the "possible problem" I mentioned above is the real problem but one idea I had was to rewrite the request and response headers to match localhost but it didn't work. I guess it doesn't affect WebRTC connections.
Electron hooks I used:
session.defaultSession.webRequest.onBeforeSendHeaders();
session.defaultSession.webRequest.onHeadersReceived();