RE: revised recording proposal

What occurs if the returned Blob type is not consistent with the recording format that was specified via get/set?  Would this be considered an error?

>> That should never happen.  The UA should raise an error if it is not able to provide the recording format specified by set.


-          Jim

From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
Sent: Thursday, December 06, 2012 3:20 PM
To: Jim Barnett; public-media-capture@w3.org
Subject: RE: revised recording proposal

Thanks for the quick response.  I owe you a proposal for warning/error objects.

> But File inherits from Blob, so it would have the same disadvantages.  The FileReader interface lets the app access the Blob's data as arrayBuffers or text, so the app can use any method that is available to it to save the data to a file.  I don't think that it would have to use FileWriter.  I don't think a File has any magic when it comes to persistence.  A File is just a Blob with a couple of extra attributes.  It would still be up to the app to persist it.

Blob and File are essentially pointers in Javascript, so it is not surprising that a File object can inherit from a Blob.  What a Blob object points to and what a File object points to could be different.  A File is backed by disk memory acc. to my reading of the File API spec ("A File<http://www.w3.org/TR/FileAPI/#dfn-file> interface, which includes readonly informational attributes about a file such as its name and the date of the last modification (on disk) of the file.").  A Blob may or may not be backed by disk memory.  The web application would not know what the Blob is pointing to, so the web application would have to provide its own logic in creating the file.

Maybe it boils down to how important it is to the group to meet Recording requirement #1 in http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html#requirements.  File Writer is not what I would consider a stable specification, and its support is currently sparse (see http://caniuse.com/filesystem).  But if the developer cannot use FileWriter, then I don't know what other kinds of standardized magic are available to convert the returned Blob to a file (although I didn't have any personal aversions to using browser-specific stuff like ActiveX).

On the need for get/set recording options and how they relate to Blob type,

> The app needs to know what formats are available, select the format it wants, and set other attributes.

What occurs if the returned Blob type is not consistent with the recording format that was specified via get/set?  Would this be considered an error?

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Thursday, December 06, 2012 11:00 AM
To: Mandyam, Giridhar; public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: RE: revised recording proposal

Responses in-line

From: Mandyam, Giridhar [mailto:mandyam@quicinc.com]
Sent: Thursday, December 06, 2012 10:48 AM
To: Jim Barnett; public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: RE: revised recording proposal

Thanks for coming out with the revision.  Apologies if I am repeating any comments provided by other persons.


a)      "This document was published by the Web Real-Time Communication Working Group<http://www.w3.org/2011/04/webrtc/> as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-media-capture@w3.org<mailto:public-media-capture@w3.org> (subscribe<mailto:public-media-capture-request@w3.org?subject=subscribe>, archives<http://lists.w3.org/Archives/Public/public-media-capture/>). All feedback is welcome."



I believe this is a deliverable of the Media Capture TF.  This document is not listed among the deliverables in the WebRTC charter.  I think the Media Capture TF charter (i.e. Robin's email) should be explicitly modified to reflect this deliverable.

>>I wasn't sure what to put here. The Media Capture Wiki says "The Media Capture API<http://dev.w3.org/2011/webrtc/editor/getusermedia.html> (a.k.a. navigator.getUserMedia) is developed by a joint task force between the WebRTC<http://www.w3.org/2011/04/webrtc/> and Device APIs<http://www.w3.org/2009/dap/> Working Groups".   That made it sound to me like there wasn't really a separate entity, and since DeviceAPIs doesn't seem to be involved in Recording, I figured that meant that it was a product of the WebRTC group.  But it can be changed.



b)      I do not believe Recording requirement 12 in http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html#requirements is met by the current specification (at least not without several dependencies on other specifications in various states of stability).  Can you please explain why you think pause/resume methods are not desirable?

>> They can be added.  The semantics would be that the Recorder stops gathering data while  paused.  This would be different from the behavior when a Track is paused  (in that case, the Recorder adds filler - silence or black frames - so that synchronization can be maintained.)



c)       2.2 Methods, record:  "If the timeSlice argument has been provided, then once timeSlice milliseconds of data have been colleced, raise a dataavailable event containing the Blob of collected data, and start gathering a new Blob of data."



I am still not convinced time-sliced data is better returned as a blob versus an ArrayBuffer, particularly if latency is an critical concern (i.e. "reliable" streaming).  At very least you will need the extra step of invoking the FileReader I/F (http://www.w3.org/TR/FileAPI/#FileReader-interface) to get at Blob data.

>> Anyone else have an opinion on this?



d)      I believe that the UA will not be in compliance with Recording requirement 1 in http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html#requirements if there is no ability to return a file.  The document needs to clarify this.  Perhaps one approach could be that intermediate data returned when a time-slice is specified is in the form of a Blob (or ArrayBuffer), but a File object is returned when endRecording() is invoked.



I also think we shouldn't have a dependency on File Writer to meet Recording requirement 1 (http://www.w3.org/TR/file-writer-api/), which would be necessary if we return a Blob as opposed to a File as far as I can tell.



>> But File inherits from Blob, so it would have the same disadvantages.  The FileReader interface lets the app access the Blob's data as arrayBuffers or text, so the app can use any method that is available to it to save the data to a file.  I don't think that it would have to use FileWriter.  I don't think a File has any magic when it comes to persistence.  A File is just a Blob with a couple of extra attributes.  It would still be up to the app to persist it.



e)      get/set recording options.  Why is this necessary to expose?  The returned Blob should have the Media type set in the type attribute.
>> The app needs to know what formats are available, select the format it wants, and set other attributes.



f)       I'd like to see more specificity on the error/warning events in the form of a returned error/warning object.  This practice is consistent with other device API specifications (see for instance http://www.w3.org/TR/2010/CR-geolocation-API-20100907/#position-error).

>> Agreed.  A lot of work is needed here.  (And you've agreed to help do it...)

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Friday, November 30, 2012 7:13 AM
To: public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: revised recording proposal

Here's an updated proposal, which I have checked into mercurial at http://dvcs.w3.org/hg/dap/file/802e29e48f73/media-stream-capture/RecordingProposal.html


-          Jim