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

On 2013-01-24 17:35, Jim Barnett wrote:
> Forwarding a discussion from another list.
>
> Glenn,
>
> It’s true that we have not been considering DVR/PVR as use cases.
> Chairs, should we contact the Recording and Downloading Task force? From
> looking at their wiki, it sounds like some of their use cases are
> outside our defined scope, but it would be foolish if our work was
> incompatible with what they need.

Speaking with my chair hat on: yes, I think we should contact them. But 
I don't think we should let that stop the process to go to FPWD. We have 
a proposal that satisfies the scenarios we have defined, and publishing 
it could actually facilitate the discussions with teh "Recording and 
Downloading TF" as our work will become known to a broader audience.

Stefan

>
> -Jim
>
> *From:*Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Thursday, January 24, 2013 11:14 AM
> *To:* Jim Barnett
> *Cc:* Frederick.Hirsch@nokia.com; public-device-apis@w3.org;
> public-webrtc@w3.org; W3C Web and TV; Ed Shrum
> *Subject:* Re: Call for Consensus to publish a First Public Working
> Draft of "MediaStream Recording API", deadline 31 Jan 2013 [resend
> adding DAP]
>
> Thanks for your response.  My primary concern for my first comment is
> that this specification should be able to support DVR/PVR functions.
> Although it doesn't seem specifically designed for this purpose, it
> appears to provide significant support in that direction. I would also
> note that the Web & TV IG has initiated a Recording and Downloading
> Media task force [1] which I expect will produce a requirements
> document. IMO, it would be detrimental if DAP produces a Media recording
> API that does not satisfy the requirements coming from this activity.
>
> [1] http://lists.w3.org/Archives/Public/public-web-and-tv/2012Nov/0033.html
>
> Regards,
>
> Glenn
>
> On Thu, Jan 24, 2013 at 8:23 AM, Jim Barnett <Jim.Barnett@genesyslab.com
> <mailto:Jim.Barnett@genesyslab.com>> wrote:
>
> 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 <mailto:glenn@skynav.com>]
> *Sent:* Thursday, January 24, 2013 9:21 AM
> *To:* Frederick.Hirsch@nokia.com <mailto:Frederick.Hirsch@nokia.com>
> *Cc:* public-device-apis@w3.org <mailto:public-device-apis@w3.org>;
> public-webrtc@w3.org <mailto: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
>
> ]]
>
>
>
>
>

Received on Friday, 25 January 2013 08:21:01 UTC