RE: [download] some discussion on recording API by the Speech API CG (was Fwd: Re: Call for Consensus to publish a First Public Working Draft of "MediaStream Recording API", deadline 31 Jan 2013 [resend adding DAP])

Dear Kazuyuki, all,

Regarding DVR/PVR functions, this reminds me of TV-Anytime, which role was to develop solutions for this particular purpose.

One essential feature is to avoid recording several times the same content (e.g. from different sources and possibly based on a user profile in addition to a purposeful recording) hence filling up your harddisk. The second essential feature was of course to provide the metadata necessary to dig out what has been recorded from terabytes of storage (which is no longer an hypothetic reality).

TV-Anytime developed the CRID (Content Reference Identifier) which can be associated with any globally unique identifier to help identifying content (EIDR, ISAN, etc.). CRID is published as RFC4078 (http://tools.ietf.org/html/rfc4078). It can also be used in a variety of innovative applications like associating a programme with its catch-up tv equivalent. It can be implemented in resolving mechanisms waiting for this programme (e.g. if you missed it or want to see it again, or want to share the link) to appear in an on-demand /catch-up tv offer.

If you are interested in requirements around these DVR/PVR and their today's equivalent, please let me know and I'll be happy to contribute these to the community.

Best regards,

Jean-Pierre

-----Original Message-----
From: Kazuyuki Ashimura [mailto:ashimura@w3.org] 
Sent: vendredi, 25. janvier 2013 03:02
To: public-web-and-tv@w3.org WG
Subject: [download] some discussion on recording API by the Speech API CG (was Fwd: Re: Call for Consensus to publish a First Public Working Draft of "MediaStream Recording API", deadline 31 Jan 2013 [resend adding DAP])

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


     ]]






     ____

     __ __





------------------------------------------------------------------------------

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************

Received on Friday, 25 January 2013 07:53:38 UTC