- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 25 Jan 2013 11:02:01 +0900
- To: "public-web-and-tv@w3.org WG" <public-web-and-tv@w3.org>
Hi Bryan and Download TF,
It seems there is some discussion on recording API (using
speech) by the Speech API CG, and I'm wondering if somebody
from the Download TF is interested in this.
Thanks,
Kazuyuki
-------- Original Message --------
Subject: Re: Call for Consensus to publish a First Public Working Draft
of "MediaStream Recording API", deadline 31 Jan 2013 [resend adding DAP]
Resent-Date: Thu, 24 Jan 2013 16:15:11 +0000
Resent-From: public-web-and-tv@w3.org
Date: Thu, 24 Jan 2013 09:14:17 -0700
From: Glenn Adams <glenn@skynav.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
CC: Frederick.Hirsch@nokia.com <Frederick.Hirsch@nokia.com>,
public-device-apis@w3.org <public-device-apis@w3.org>,
public-webrtc@w3.org <public-webrtc@w3.org>, W3C Web and TV
<public-web-and-tv@w3.org>, Ed Shrum <ed.shrum@cox.com>
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 02:02:36 UTC