W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > December 2019

Re: [mediacapture-screen-share] Specify track.label (#128)

From: youennf via GitHub <sysbot+gh@w3.org>
Date: Fri, 13 Dec 2019 18:40:11 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-565558677-1576262410-sysbot+gh@w3.org>
> Site may want to put what's currently being captured in a button:

For camera/microphone sources, I do not see track labels as really useful to show to users.
Do we know websites using it this way?

I would be interested in understanding what native applications are doing and what would be needed to offer the same feature set. Might be interesting to know what web app developers are requesting in that area as well.

> [Sharing: Alice's Presentation XX]

Sure, so track.label would be 'XX' I guess.

Probably track.label would be used according the display type.
And would make most sense for "window", "application" and "browser".
In some cases, the label for "window" might be useful but not always, which might be an issue for websites to adopt this.

In case of "window" and maybe "browser", the name can change (say you change the name of the presentation). If it becomes an important part of the UI, it would need to be kept in sync, hence some eventing mechanism.

In terms of specification, we could define label values according the display type.
Or we could beef-up MediaTrackSettings with new information since the web application might anyway need to query the settings to generate its own label.

I am not against the idea, at least as long as we are not leaking new information.
I am wondering how much websites will actually use it and how much effort we should put there.

> This also seems true regardless of how many sources are being shared concurrently.

Not really, if there is only one source from Alice, [Alice] is probably the most meaningful information.

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/128#issuecomment-565558677 using your GitHub account
Received on Friday, 13 December 2019 18:40:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:35 UTC