1066082 - provide an API listing all the active streams

Status: NEW

(Core :: WebRTC: Audio/Video, defect, P3)

Description

[Florian Quèze [:florian]]

This is needed to implement the redesign in attachment 8485640 [details].

The front-end code needs an API returning a list of all the streams related to a tab.

For each of them, we need to know the hostname of the document that called gUM.

To get the full list for the global sharing indicator, we could either call the activeMediaCaptureWindows getter first and then call this new API once of each window with active shares, or we could possibly pass null as the aWindow parameter.

Could/should this list also include the pending requests?

Related IRC conversation from #media on Monday:
21:28:46 - jesup: flo-retina: stop/mute: instead of booleans, we would provide track identifiers plus any ancillary data needed to a) display status, b) allow the UI to tell us to stop/mute a track
21:30:02 - jesup: flo-retina: basically instead of accumulating booleans, it would accumulate a list with each entry having whatever data we decide is needed.
21:32:46 - flo-retina: so I guess adding this list of entries for each stream is the first piece that needs to be implemented?
21:41:53 - jesup: flo-retina: yes.  then defining the properties they need. How should the communication happen, through observers and (say) a json encoding of the data?  (a little painful for me to generate, but not too hard if it's a fairly 'flat' set of properties).  Typically there's one set of streams in the page, with one camera and one mic (and maybe one share) open
21:44:00 - flo-retina: I guess if we want to JSON encode we could easily do it on the JS side
21:45:46 - flo-retina: I was kind of expecting the list to return objects implementing an xpcom interface that would give the stream type, media source, device name, a settable boolean for muted, and a way to stop the stream.
22:53:55 - jesup: flo-retina: sure, that can be done I think
22:54:19 - jesup: flo-retina: I wasn't sure how "separated" the UI had to be from the backend impl (especially with e10s)
[...]
23:08:49 - flo-retina: jesup: do you have an estimate of how much work returning that list would be, and how soon it could be done? It seems to be the first piece of the puzzle, blocking more or less everything else for that redesign.
23:42:10 - jesup: flo-retina: can you detail what in particular you would want available from it?  (doesn't have to be the type/struct level, but stuff like "name of device", "muting status", "unique ID", (others?).  Commands would be "stop", "mute", "preview start", "preview end", "start".  I think we could allow "preview" during active capture, which means we could have mic levels or (in the future) camera...
23:42:12 - jesup: ...snaps of an already-capturing stream
23:43:39 - flo-retina: your list already contains most things. We would also want 'type' (audio/video?), media source ("camera", "screen", "application", "window", ...)
23:43:59 - jesup: sure

Comment 1

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

fyi