RE: revised recording proposal

Hello,
I'll echo what has been stated in that I also like where this is headed.


1.       It has already been pointed out that an onrecordingerror event handler needs to be specified in the IDL.

2.       timeSlice appears to be optional from the developer perspective, but would it be permissible for a minimum timeSlice to be used from the UA perspective?  In other words, when the developer does not specify a timeSlice, can the UA still return data at pre-set intervals?

3.       To clarify, is the returned Blob consistent with the definition in http://www.w3.org/TR/FileAPI/#dfn-Blob?  If so, we run a risk of having a dependency on a spec that has not progressed significantly along in standardization.

4.       If we are in fact staying consistent with the Blob definition in File API, then it would seem to me that the Formats dictionary as defined should be consistent with how content types are indicated with Blobs.  Media type as defined in RFC 2046 should be sufficient in this case, and is leveraged for the current definition of Blob.type.

5.       Can you (or anyone else on the mailing list) articulate why a Blob is returned versus an ArrayBuffer?

6.       That being said, I think at least for Version 1 of this spec the group should consider having the recording directly write to a file (a la Android MediaRecorder - http://developer.android.com/reference/android/media/MediaRecorder.html or iOS AVAudioRecorder - http://developer.apple.com/library/ios/#documentation/AVFoundation/Reference/AVAudioRecorder_ClassReference/Reference/Reference.html) and move a Blob-based recording interface to Version 2.

-Giri Mandyam, Qualcomm Innovation Center (QuIC)

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Monday, November 19, 2012 1:15 PM
To: public-media-capture@w3.org
Subject: revised recording proposal

Here's my latest revision of the recording proposal, based on discussion in Lyon and on the list.  The main difference from the previous proposal is that I've moved recording into its own MediaRecorder class, with a constructor that takes a MediaStream as an argument.  I've kept a single record function with an optional TimeSlice argument, because that seemed to be the most popular choice.  There are questions scattered throughout in brackets [].    The treatment of errors is extremely vague, but I think that's a reflection of where we are.

Please send me any comments.


-          Jim