- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Dec 2019 07:29:35 +0000
- To: public-webrtc-logs@w3.org
> @youennf `track.label` has been there forever, and is merely short for > > ```js > (await navigator.mediaDevices.enumerateDevices()) > .find((d => d.deviceId == track.getSettings().deviceId).label > ``` This algorithm is only true for capture tracks, but there are many different types of tracks. A single getter with different meanings for each track type does not seem really useful to me if you have to know the track type to apply the correct processing on track.label. track.label is also conveying a lot of information, all in one string, which has drawbacks. For instance, as a website I might want to localise my web page. If my website user wants a 'French' version, I would like to provide it, even if the OS is English based. This would mean translating 'Main screen' to 'Ecran principal' for instance... More focused values (like is a track associated with a default device?) seem more appropriate in that case and could be more easy to use for other representations (speech synthesis for instance). One case where we could think track.label is useful is remote tracks. In practice, remote track labels do not seem all that useful, especially in cases where there is an SFU (content switching, pre-reserved tracks...). Localisation might make things even more complex here. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/128#issuecomment-567370778 using your GitHub account
Received on Thursday, 19 December 2019 07:29:36 UTC