Should we revisit and document getUserMedia() track order?

[jan-ivar]

The spec says: "The tracks of a MediaStream are stored in a track set. The track set MUST contain the MediaStreamTrack objects that correspond to the tracks of the stream. The relative order of the tracks in the set is User Agent defined and the API will never put any requirements on the order. The proper way to find a specific MediaStreamTrack object in the set is to look it up by its id."

But #1020 is concerned about deterministic event order between track clones, looking at using track creation order.

If we're chasing determinism at this level, might getUserMedia need to be clearer about whether it creates its audio or video track first?

I suspect audio comes first, given "2. Let requestedMediaTypes be the set of media types in constraints with either a dictionary value or a value of true... 11.3 For each media type kind in requestedMediaTypes ...", and the fact that dictionary members are sorted lexographically.

While use of the word "set" in the sentences above do not link to set, they might be understood to mean the same thing. It reads:

Thankfully, an implementation check reveals the same order in all browsers: audio, video. Is it time to document this?

[bradisbell]

@jan-ivar Is there ever a time when a MediaStream would be returned from getUserMedia() with tracks added later? For example, an audio device is usually available seconds before a video device initializes and starts returning video data. I suppose the opposite could happen. Just thinking ahead, wondering if specifying track order might hurt optimizations in the future that return available tracks immediately and add the other requested track(s) later.

[jan-ivar]

getUserMedia({video: true, audio: true}) is guaranteed to return two tracks. The algorithm ensures that.