- From: Glenn Adams <glenn@skynav.com>
- Date: Tue, 2 Apr 2013 11:07:19 -0600
- To: "Mandyam, Giridhar" <mandyam@quicinc.com>
- Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>, W3C Web and TV <public-web-and-tv@w3.org>
- Message-ID: <CACQ=j+etW5=DtWv=iRTt+JQarBwRfTyq24207TJnPY3iQEqe1g@mail.gmail.com>
On Tue, Apr 2, 2013 at 8:40 AM, Mandyam, Giridhar <mandyam@quicinc.com>wrote: > ** ** > > Hi Glenn,**** > > First off, I think it would be beneficial if the Web & TV IG conducted a > review of all specs being developed by the Media Capture TF. Do you have > any guidance as to how to kick off such a review? > The issue for me is whether there is an explicit intention that this Recording API be used for recording externally sourced media streams. If there is an intention that it be used, then clearly the Recording TF in the Web & TV IG needs to do a careful review. However, if there is an intention that it not be used, then such a review might not be needed, and in such a case the language and title of the your group's work needs to reflect this intention. At present, it is no possible to discern the intended usage. I'm copying the Web & TV IG on this email, so perhaps one of its chairs may take this up further. > **** > > ** ** > > > Is the Recording API intended to be use to record externally sourced > media being played back through HTMLMediaElement?**** > > ** ** > > The Recording API has a constructor that takes a MediaStream as input, and > a MediaStream is composed of MediaStreamTracks.**** > > ** ** > > Please see > http://dev.w3.org/2011/webrtc/editor/archives/20130320/getusermedia.html#track-source-types, > which describes the sources of MediaStreamTracks. The current sources are > “microphone”, “camera” and “photo-camera” (there is also a “none” source > for when a MediaStream is created but user permission has not been > provided). We have discussed adding a “remote” source, which could account > for externally-sourced media. **** > > ** ** > > So currently the Recording API IMO is not defined for externally-sourced > media the way I read it. Nevertheless, we have discussed in the Media > Capture TF the possibility for tracks to have an external or remote source, > and therefore they could be generated by e.g. locally-stored files.**** > > ** ** > > That being said, there is a proposal to retrieve tracks from an > HTMLMediaElement, see: > http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/0066.html. > When this issue gets resolved, then the Recording API language could be > changed according to your suggestions. But I think it is premature to > change the language in the Recording API to be more restrictive at this > point in time.**** > > ** ** > > -Giri**** > > ** ** > > ** ** > > ** ** > > *From:* Glenn Adams [mailto:glenn@skynav.com] > *Sent:* Monday, April 01, 2013 12:51 PM > *To:* Mandyam, Giridhar > *Cc:* public-device-apis@w3.org > *Subject:* Re: Media Capture TF Update**** > > ** ** > > ** ** > > On Mon, Apr 1, 2013 at 10:24 AM, Mandyam, Giridhar <mandyam@quicinc.com> > wrote:**** > > As per my action item from the last call, I will call the group's > attention to ongoing specification work in the Media Capture Task Force > (jointly run by the DAP and WebRTC Working Groups). I strongly encourage > DAP members to review and provide feedback to the Media Capture TF mailing > list (http://lists.w3.org/Archives/Public/public-media-capture/) on these > specifications. > > The group originally was chartered to develop the primary Media Capture > and Streams specification, with the primary JS method known as > getUserMedia(). Since that time, the group has also developed the > Recording API (which is in FPWD status) and the Image Capture API (which is > now a group Editor's Draft and I am the editor). > > 1. Media Capture and Streams: > http://dev.w3.org/2011/webrtc/editor/archives/20130320/getusermedia.html. > 2. Recording API: > https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/MediaRecorder.html > 3. Image Capture API: http://gmandyam.github.com/image-capture/ > Note that I plan on checking this into Mercurial soon, after I > reverify with the latest version of respec.js**** > > ** ** > > Is the Recording API intended to be use to record externally sourced media > being played back through HTMLMediaElement? If it is not, then I would like > to see the following changes:**** > > - rename the specification to a name that qualifies its usage to local > device captured media content**** > - add language to abstract and overview sections that qualifies the > intended usage**** > > If it is intended to support recording of externally sourced media, then > the group needs to widen the participation in the spec process to bring in > people from the HTML Media TF and the Web & TV IG.**** > > ** ** > > Regards,**** > > Glenn Adams (for CoxCom)**** > > **** >
Received on Tuesday, 2 April 2013 17:08:12 UTC