RE: Recording API applicability to Web & TV use cases

Our intent is that the Recording API work with anything of type MediaStream, without regard to its source.   I would think that if there’s a need to treat local streams differently from remote ones, it would apply in more cases than recording, and we would introduce a new MediaStream type.


-          Jim

-          P.S.  Note that cross-origin constraints will allow recording only of MediaStreams that have the same origin as the recording Java Script code (or at least that’s my understanding), so I think that we should keep security questions separate from ones about the technical approach to recording.

From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
Sent: Tuesday, April 02, 2013 3:09 PM
To: public-media-capture@w3.org
Cc: Glenn Adams; W3C Web and TV
Subject: Recording API applicability to Web & TV use cases

Hello All,
I provided a brief summary of the current efforts in the TF to the DAP mailing list recently (please feel free to correct or expand on any of the discussion points below).  As can be seen by the discussion below, there is some concern about  the scope of the Recording API with respect to externally sourced content.  Are there opinions as to whether the Recording API should have language prohibiting its use for externally-sourced MediaStreams?

-Giri Mandyam, Qualcomm Innovation Center

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Tuesday, April 02, 2013 10:07 AM
To: Mandyam, Giridhar
Cc: public-device-apis@w3.org<mailto:public-device-apis@w3.org>; W3C Web and TV
Subject: Re: Media Capture TF Update


On Tue, Apr 2, 2013 at 8:40 AM, Mandyam, Giridhar <mandyam@quicinc.com<mailto: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<mailto:glenn@skynav.com>]
Sent: Monday, April 01, 2013 12:51 PM
To: Mandyam, Giridhar
Cc: public-device-apis@w3.org<mailto: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<mailto: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)