Re: What does MediaStreamRecorder.getRecordedData() actually return?

On 11/09/2013 5:57 AM, Adam Bergkvist wrote:
> On 2013-09-11 06:54, cowwoc wrote:
>> Hi,
>>
>> http://dev.w3.org/2011/webrtc/editor/webrtc-20111004.html#dom-mediastreamrecorder-getrecordeddata 
>>
>> reads:
>
> You're looking at a really old version (2011-10-04) of the spec.
>
> The MediaStream recording stuff has been moved to a dedicated spec [1].
>
> /Adam
>
> [1] 
> https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/MediaRecorder.html
>

Thanks, but this only answers my last question. The rest of the 
questions still hold:

 1. It's not clear (to me at least) whether the data being returned
    consists of the compressed WebM audio+video (muxed) data or
    something else. Perhaps the document should be more explicit?
 2. In the case of the incoming MediaStream I can see the browser having
    no problem returning a compressed stream, but does this imply that
    the outgoing MediaStream must compress the audio+video before
    passing it into the recorder? This implies that localhost recording
    app (without a remote end) is more expensive than it needs to me.
    Certainly this is an edge-case, but it's worth considering.

     Looking at 
https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/MediaRecorder.html#blob-event 
<https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/MediaRecorder.html#blob-event> 
the API returns a Blob but looking at 
http://www.w3.org/TR/2009/WD-FileAPI-20091117/#dfn-Blob there is no way 
to get bytes out of a Blob. I believe the API is supposed to refer to a 
subclass (e.g. File) which allows us to read the bytes (e.g. using 
FileReader). Shouldn't the recorder API exposes a sub-class?

Gili