- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 06 Dec 2011 07:44:07 +0100
- To: Travis Leithead <travis.leithead@microsoft.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>, "public-device-apis@w3.org" <public-device-apis@w3.org>
On 12/06/2011 02:45 AM, Travis Leithead wrote: > As per my Action 461 [1], and as requested by this task force, I've put together the first draft of the scenarios for media capture [2]. Thanks a lot! > This draft is a combination of scenarios mingled with some commentary, issues, and points of discussion. Actually, I'm a bit disappointed with the scenarios part of this; there are a lot of cases (rewind, take snapshot and so on) that I'd recognize as scenarios / use cases, but they are not called out to a degree where I can recognize them as specific scenarios; they are rather buried within the commentary. Would it be possible to pull out the specific scenarios that you would like us to support, independent from the possible / current / proposed implementation descriptions? Some detailed commentary: - header: This should be listed as a WEBRTC/DAP task force item, not a DAP item. - intro: the use of the word "recording" should be avoided for the WebRTC scenarios, since the whole subject of recording sessions is still open in WEBRTC. "Capture" is the most common word, I think. - 3.1 stream initialization: The result of initialization will have to be available as a MediaStream. As long as the WebRTC API is totally dependent on the MediaStream concept, this is not a question. If you want to suggest other forms of the available capture, those may be alternatives, or be something that can be converted into a MediaStream, but current text is too weak on this point. - 3.2 reinitialization: We (WebRTC editors) have discussed moving the "ended" event from the MediaStream to the MediaStreamTrack; it seems to be easier to define it crisply there. - 3.6.3 It's unclear for me what you are pointing to when you refer to the WebRTC "take a picture" scenario. I can't find it in our scenarios document. - 3.10.1 In a streaming case, you may support rewind through recording to a tail-drop buffer. So it's not impossible, just complex. > Writing this document has given me a wonderful opportunity to mentally explore a variety of possible API designs and patterns. It also started pushing me in a particular direction which you might be able to tease out from the document. With the Chair's permission, I'd like to write down my ideas in the form of a media capture API member submission and send them to this group for further discussion. I would expect that it would take me about a week to get it all written down. > > Thanks, and feedback welcome. > > [1] https://www.w3.org/2009/dap/track/actions/461 > [2] https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html > > -Travis > > > > >
Received on Tuesday, 6 December 2011 06:44:50 UTC