Re: recording proposal

On 2012-10-05 15:55, Jim Barnett wrote:
> Here is a proposal for recording for discussion on Tuesday’s call.
>
> -Jim and Travis
>

Thanks for putting together this proposal. Some comments inline.

> requestData
>
> This method is a request for the UA to generate a dataavailable event
> containing the data that it has currently gathered. This method thus
> allows the application to poll for data according to its own
> schedule. When this method is called, if recording is true, the UA
> must raise a dataavailable event containing its current Blob of data
> and then start collecting a new Blob. If recording is false, this
> method is a no-op.

I think this is a nice feature.

> dataavailable    MediaStreamEvent
> The UA returns data to the application. This event contains a Blob of
> recorded data.

> various errors TBD    MediaStreamEvent
> TODO

Any particular reason why these are MediaStreamEvents (which carry a 
MediaStream payload)? I think we have two options with the 
"dataavailable" event:

1) Use a simple event that indicates that a data attribute of type Blob 
is ready to be read.
2) Introduce a new event interface with a Blob payload.

Perhaps option 2 is the only reasonable one since we want to support 
sliced recordings which produces several Blobs and it doesn't work well 
with a single Blob attribute.


> 1.6 Open issues

> 2. Should recording be moved into a separate class?

I'm leaning towards that.

> 4.  What are the privacy implications of recording? Does the
> application need to request special permission?

I think we should treat recording and rendering video on a canvas and 
extracting pixel data as equal in terms of privacy. So if the first can 
be done without extra permissions then recording should be allowed too.

BR
Adam

Received on Tuesday, 9 October 2012 10:00:56 UTC