RE: Call for Consensus to publish a First Public Working Draft of "MediaStream Recording API", deadline 31 Jan 2013 [resend adding DAP]

Glenn,
I’m not sure that I understand your first point.  The API is defined to work with any object of type MediaStream, whether local or remote.  If there is some other object that needs to be recorded, I would think that the question would be how to convert it into a MediaStream.  The getUserMedia spec would be the right place to do that, or possibly a separate spec, but the process should be transparent to the MediaRecorder class.  (There’s a separate discussion going on about whether we want to taint certain MediaStreams to prevent recording for security reasons, but that’s orthogonal to this issue, I think.)

On the issue of where takePhoto() goes, it was originally a method on VideoTrack.  We moved it to the recorder class because it seemed to have a lot in common with recording.  I don’t particularly care where it goes, though I wonder if a new interface is justified, given how limited the functionality is.  I’ll go with whatever the majority decides.


-          Jim

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Thursday, January 24, 2013 9:21 AM
To: Frederick.Hirsch@nokia.com
Cc: public-device-apis@w3.org; public-webrtc@w3.org
Subject: Re: Call for Consensus to publish a First Public Working Draft of "MediaStream Recording API", deadline 31 Jan 2013 [resend adding DAP]

>From my brief read of this draft, I have the following comments:

  *   Document should describe how it the mechanisms defined can be used to record media streams deriving from non-local devices, specifically, how to record media streams obtained from external servers, e.g., streams fetched and presented by HTMLMediaElement.
  *   The members takePhoto() and onphoto should be moved to a separate interface to make the MediaRecorder interface more generic, and not tied to specific types of media sources.
Regards,
Glenn

On Thu, Jan 24, 2013 at 6:31 AM, <Frederick.Hirsch@nokia.com<mailto:Frederick.Hirsch@nokia.com>> wrote:
DAP members:

The Media Capture Task Force [a] is a joint Task Force of the DAP and WebRTC working groups. This is a CfC to publish a FPWD of the  "MediaStream Recording API".

Below I include the mail sent to the WebRTC mailing list, consider this as a CfC for the Device APIs working group as well, and please respond on the DAP public mail list  as well as the public WebRTC mailing list with either +1 or concerns. (I've cross-posted this mail deliberately as CfC responses should be seen by all and I expect relatively low traffic).

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group

[a] http://www.w3.org/2009/dap/#mediacapture


CfC sent to WebRTC list:
[[

During the Media Capture Task Force call on 6 December 2012 [1] we agreed to start a CfC for a First Public Working Draft (FPWD) of the  "MediaStream Recording API" draft once Jim completed some additional
edits, which he has [2].

This is a Call for Consensus (CfC) for the WebRTC WG members to publish  of FPWD of this document.

A FPWD is a draft and can thus continue to be edited and evolve, but  gives visibility of the work to a broader community, and is thus useful.  It also starts the call-for-exclusion process under the W3C Patent Policy.

As with all of our CfCs, positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is Thursday January 31st and all comments should
be sent to public-webrtc at w3.org<http://w3.org>. We can then publish the week after,  assuming that works for the W3C team and editors.

Stefan, for the chairs

[1] Minutes:

http://lists.w3.org/Archives/Public/public-media-capture/2013Jan/0057.html



[2] Draft:

http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/att-0159/RecordingProposal.html


]]