Re: [mediacapture-main] Should we revisit and document getUserMedia() track order? (#1028)

> What I said was that track order dependency has been "effectively tested in the real world" by Safari and Firefox behaving differently for years (in the case of Safari having no reliable order from one track to the next).

Please look at the very beginning of the issue where your testing claimed
> Thankfully, an implementation check reveals the same order in all browsers: audio, video

The meeting slide states this which is one of the very few points where we agree:
> Safari [sorts by random](https://github.com/w3c/mediacapture-main/issues/1028#issuecomment-2658374796) (lexicographical order of track.id, adapter.js tries to [correct it](https://github.com/webrtcHacks/adapter/pull/969/files)) Needlessly confusing for web developers

> Therefore, we know interoperable websites—by definition—do not rely on track order.
> Kudos to Safari for proving this point and taking one for the team here!

"Needlessly confusing web developers" is not a good thing.

websites may 
1/ not care about the order or do not rely on getTracks() order. There is no problem in having different orders so no action needed.
2/ do what adapter.js does in the legacy addStream method: add all audio tracks, then add all video tracks. Possibly the first of each kind because the use-case for more is quite a niche.
3/ be unmaintained. I do not want to know how many versions of [rtcmulticonnection](https://github.com/muaz-khan/RTCMultiConnection) are floating around.

The public numbers we have show that addStream are still hovering at ~5% of Chrome getUserMedia calls and pretty stable for the last years:
https://webrtchacks.github.io/chromestatus/?buckets=1401,1402,1641
This shows two things:
* the lack of addStream in Safari has not affected this number nor has any decision in this WG.
* there is a stable, non-declining usage of legacy navigator.getUserMedia (and this might well be webkitGetUserMedia). This is not interoperable with Firefox or Safari. Yet developers insist on using those APIs.

Same for https://webrtchacks.github.io/chromestatus/?buckets=1656 which shows `RTCIceServer.url`. Safari throws here, Firefox shows a deprecation on:
```
const pc = new RTCPeerConnection({iceServers: [{url: 'stun:stun.l.google.com:19302'}]})
```
Unshipping this is a great way to test your theory! And we can see if this moves the needle in the public Chrome metrics.

This demonstrates that the working group has a problem with the way it ignores WPT:
https://wpt.fyi/results/webrtc/historical.html?label=experimental&label=master&aligned
This fails in all browsers but Safari. 
[Chromium issue here](https://issues.chromium.org/issues/40490501) with some comments.
[Firefox issue filed by you here](https://bugzilla.mozilla.org/show_bug.cgi?id=1116766).
Since this *throws* in Safari (thank you for taking one for the team but not much impact) this should be higher priority than the merely confusing track order?
Out of curiosity, why is this not part of Interop 2025?

> In case it's unclear to readers, by "folks" we're down to maintainers of non-interoperable chromium-only websites.

"Maintainers" seems the right word, from what I saw the affected product had reached "end of sale".
I'll ping you the name of the person you want to discuss this with over 🐑👁 

-- 
GitHub Notification of comment by fippo
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/1028#issuecomment-2683872057 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 26 February 2025 04:34:38 UTC