From W3C Wiki
The Media Capture API (a.k.a. navigator.getUserMedia) is developed by a joint task force between the WebRTC and Device APIs Working Groups (see the task force charter which replaced the original task force charter in February 2013).
This page serves as a coordination point for the work in this task force.
April 24th 2012. Minutes: http://lists.w3.org/Archives/Public/public-media-capture/2012Apr/att-0031/minutes-2012-04-24.html
May 9th 2012. Minutes: http://lists.w3.org/Archives/Public/public-media-capture/2012May/0070.html
June 7th 2012. Minutes: http://lists.w3.org/Archives/Public/public-media-capture/2012Jun/0055.html
Aug 23rd 2012. Minutes: http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0149.html
Oct 9th 2012. Minutes http://lists.w3.org/Archives/Public/public-media-capture/2012Nov/0041.html
March 25th 2013. Minutes http://lists.w3.org/Archives/Public/public-media-capture/2013Apr/0006.html
June 5th, 5pm-6pm CET: Joint call with WebRTC on the use of DOM Futures.
F2f meeting held Oct 30 2012
F2f meeting held Feb 5-6 2013
F2f meeting planned for November 14th 2013 (TPAC week).
- Archives of the email@example.com mailing-list are publicly available. This mailing-list should be used for all technical discussions within the group.
- Tracker is used to track actions within the group. We're only using the ACTION section.
- Buganizer, the "Media Capture and Streams" component, is available for tracking issues and bugs.
The group uses IRC to take minutes and exchange info during calls and face-to-face meetings:
- IRC info: #mediacap on irc.w3.org, port 6665
- You may use the W3C Web client, specifying a username and channel #mediacap
- You may find more info on IRC usage at W3C
Note: just a first brain dump; has not been discussed or agreed in any way.//Stefan 2012-04-24
- Proposed http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0024.html
- Both positive and negative feedback
- No conclusion
- dummy track can be used to insert DTMF in (to enable using IVR without access to mic or cam)
- can also be used to speed up negotiation (no need to wait for use consent to use cam/mic to send answer)
- in newer drafts there is a possibility to create dummy audio and video tracks, but no way to assign sources to them
- we need the possibility to use other sources than the actual device to getUserMedia so that users can fake the access to a camera
- there is also another need: the webrtc reqs mandate that the screen should be a valid source (to enable screen sharing)
- need documented in Travis' scenarios document https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html
- documented as req A14 in http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1
- the API(s - there are currently two proposals) developed by the Audio WG may be used, but when they will be compatible with MediaStreams is uncertain
- currently possible with web audio api
- documented as req A15 in http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1
- web audio api possible to use
- Discussed. Pro's and con's
- Current assumption: new direct assignment using srcStream; change to a specific mediastream scheme for minting an URL (http://lists.w3.org/Archives/Public/public-media-capture/2012Oct/0023.html)
- proposed by Anant in telco April 24th 2012 (documented towards the end of http://lists.w3.org/Archives/Public/public-media-capture/2012Apr/att-0031/minutes-2012-04-24.html)
- Travis submitted a proposal on that can be used for this purpose in http://lists.w3.org/Archives/Public/public-media-capture/2012Jul/0069.html
- Update of Travis' proposal: http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v4.html
- Update of Travis' proposal: http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html
- v6 currently being incorporated into gUM document
- Proposed http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0008.html
- Discussion not concluded
- Split out from gUM document
- Proposal from Giri available: http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/0019.html
- Proposed http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0085.html
- Not that much support, more discussion needed
- Concluded that we should not do this in http://lists.w3.org/Archives/Public/public-media-capture/2012May/0060.html
- Proposed http://lists.w3.org/Archives/Public/public-media-capture/2012Apr/0045.html
- Discussion started
- Concluded that we should not do this right now in http://lists.w3.org/Archives/Public/public-media-capture/2012May/0060.html
- Description on how MediaStreams integrate with media elements must be added to the doc
- Jim Barnett has produced a draft: http://lists.w3.org/Archives/Public/public-media-capture/2012May/0064.html
- Is now incorporated in the getUserMedia document
- getUserMedia could return a MediaStream with a video track per camera
- or, getUserMedia could return a MediaStream with one video track (and the user selects which cam to use)
- have seen arguments for both (discussion started at http://lists.w3.org/Archives/Public/public-media-capture/2012Apr/0009.html)
- Discussed and resolved at the June 7 2012 telco. GetUserMedia could ask for max one track per kind, but if several getUserMedia calls are made before entering stable state the UI could be optimized to only bother the user once. See http://lists.w3.org/Archives/Public/public-media-capture/2012Jun/att-0055/minutes-2012-06-07.html, resource reservation
- When are devices (camera/mike) reserved? GetUserMedia, attachment, other?
- When are devices released? Stop stream, stream GC'd, other?
- Was discussed at telco May 9th; agreed to go for option "getUserMedia" reserved/occupies devices
- Anant got actions to write up a proposal accordingly (recorded as Actions 2 and 3 at http://www.w3.org/2011/04/webrtc/mediacap/track/actions)
- In version Aug 13 2012 of http://dev.w3.org/2011/webrtc/editor/getusermedia.html this is included