What does MediaStreamRecorder.getRecordedData() actually return?

Hi,

http://dev.w3.org/2011/webrtc/editor/webrtc-20111004.html#dom-mediastreamrecorder-getrecordeddata 
reads:

Letdatabe the data that was streamed by the|MediaStream 
<http://dev.w3.org/2011/webrtc/editor/webrtc-20111004.html#mediastream>|object 
from which the|MediaStreamRecorder 
<http://dev.w3.org/2011/webrtc/editor/webrtc-20111004.html#mediastreamrecorder>|was 
created since the creation of the|MediaStreamRecorder 
<http://dev.w3.org/2011/webrtc/editor/webrtc-20111004.html#mediastreamrecorder>|object.

     I find this sentence a bit confusing in light of the fact that you 
have both an incoming and outgoing MediaStream

 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 
http://dev.w3.org/2011/webrtc/editor/webrtc-20111004.html#idl-def-BlobCallback 
the recorder 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?

     How often does BlobCallback get invoked? I believe applications 
will need the ability to indicate whether they prioritize low-latency or 
high throughput. One approach would be for the application to request a 
callback frequency and the browser to try to honor that (within reason).

Gili