examples: dont fiddle with srcObject if already set

[fippo]

dont attempt to set srcObject if it is already set in the examples.

This covers two cases:

• ontrack with an audio and a video track
• early media (see discussion in does MSID still work? (was: example 13: getReceivers semantics) #1128)

[taylor-b]

The early media case isn't relevant in these specific examples, since they don't set srcObject before the track event fires. But the point that it will fire twice, with an audio and video track, is valid, so LGTM.

[taylor-b]

One issue may be that when the track event is first fired, as currently specified the stream will only include one track (the one in the event).

So will it be an issue if srcObject is set while the stream only has an audio track, then the video track is added in the next microtask? Or is this guaranteed to work? I've run into some issues with this kind of thing in Chrome, but was unsure if it was a bug or expected behavior.

[taylor-b]

Created #1135 for the above issue.

Can we mention in a comment somewhere why the !srcObject check is needed? Which I'd assume is to avoid invoking the media element load algorithm twice.

[fippo]

added a comment "don't set srcObject again if it is already set." to the samples. Which made me wonder if the check should be more specific and only avoid setting the same stream again but the example would blow up with multiple streams anyway.

We don't seem to have a description of what the consuming code is supposed to do with the track and stream from ontrack anywhere.

[stefhak]

Comment to #1129 (comment): the intention is that once the MediaStream is attached to a video element (via srcObject), tracks can come and go and things should work. E.g. if a new audio track is added, the existing video and audio should continue to play with the new audio track being mixed in.