Consider not triggering the stream:added event for the default Chrome stream

[DamonOehlman]

When initiating a peer connection on Chrome, when no "real" streams or data channels have been added to the peer connection before creating an offer a "default" stream is added by Chrome. This stream currently triggers the stream:added event which will generally result on a video element being added to the DOM which is rendered as a black area because the stream itself contains no data.

While I have implemented code to deal with this behaviour within an experimental ui package (rtc-ui) I think that quickconnect should not trigger a stream:added event for this default stream (it is labelled as such and can be detected) as it is not useful for rendering purposes. My understanding is that it exists only so the process of gathering ice candidates and establishing connectivity for audio and video streams can be done as quickly as possible.

[DamonOehlman]

I have done some investigation on this, and I believe there may be some risk to implementing any logic like this. It certainly seems that chrome badges any remote stream that does not have a specific id or label with the label and id of "default". This in turn means that a remote stream that has been captured firefox will be given the same treatment as the fake chrome stream.

I think the best thing that can be done is to ensure that the stream is playable before adding it to the DOM. This can be done by monitoring the loadedmetadata and canplay events of a video element that is attached to a stream. I made a small convenience package to assist with this behaviour: canplay