Re: Media Capture TF Update

On Tue, 02 Apr 2013 19:07:19 +0200, Glenn Adams <glenn@skynav.com> wrote:

>
> On Tue, Apr 2, 2013 at 8:40 AM, Mandyam, Giridhar <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.

Glenn,
thanks for adding the Web&TV IG into the loop.

Bryan,
this work seems to be relevant for your TF work. Would it be possible to  
have a kick-off call soon of such TF and start looking at the use cases as  
well as collect all the existing specs (including this one) that may  
(partially) address them?

/g



>
>
>>
>>
>>> 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]Sent: Monday, April 01, 2013  
>> 12:51 PM
>> To: Mandyam, Giridhar
>> Cc: 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> 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)
>>
>>
>



-- 
Giuseppe Pascale
Product Manager TV & Connected Devices
Opera Software