Define behavior when a cycle is detected

[achronop]

Nothing can prevent from setting the captured stream to the srcObject of the HTMLMediaElement that is producing the stream. This can happen in a direct and indirect way. For example:

// direct
stream1 = element1.captureStream();
element1.srcObject = stream1;

//indirect
stream1 = element1.capturedStream();
element2.srcObject = stream1;
stream2 = element2.captureStream();
element1.srcObject = stream2;

More complicated scenarios can exist if the stream is driven first to the WebAudio API and returns after to the producing element.

This issue is about how the HTMLMediaElement must behave when that happens. I see two options here. One is to throw an error and the second to produce silenced or disabled/muted tracks. Both have tradeoffs. The first is more explicit but it might break existing functionality. The second is less involving but the error might slip unnoticed.

[alvestrand]

Thought: If we define that captureStream() produces a track that is initially muted, and that a HTMLMediaElement will unmute the output stream when data becomes available, and that data is not considered available when the srcObject is a muted stream, it all becomes quiet. Of course, if the HTMLMediaElement has a preroll image set, people probably expect to see that on the output stream, which means that the issue returns in a different form.

I don't see the risk being great enough to warrant throwing an error, but consistency is good.

[achronop]

That covers the beginning of the stream. However, the cycle might be formed later, after the stream has been working for some time. Maybe the stream has been running already attached to another element. In this case, the track will be unmuted when the cycle is formed.

It is my opinion as well that it is more like an unwanted side effect rather than an error. It would be better to prevent by going silent or muted or even ending the track rather than throwing an error.

[guest271314]

Nothing can prevent from setting the captured stream to the srcObject of the HTMLMediaElement that is producing the stream.

if (element.srcObject !== null && element.srcObject.id !== stream.id) {
  element.srcObject = stream;
}

?

[Pehrsons]

I think this is well defined by the html spec, given that #24 goes through.

In the direct and indirect cases, the load algorithm will remove all selected/enabled tracks, such that the corresponding captured MediaStreamTracks end, when the srcObject attribute gets assigned. These cases shouldn't lead to a cycle.

A case involving WebAudio acts the same, as long as it involves assigning the srcObject attribute.

Cases that allow letting tracks through would involve adding a track from the captureStream() stream to the media element's srcObject stream. IIRC for video this adds a track to the VideoTrackList, which ends when selected; and for audio a track is also added and enabled automatically -- and tracks that occur multiple times will render louder.