Re: MediaStreamRecorder ideas

Hi,
Great summary of my ramblings!

Regarding C, it is to protect weaker platforms (or from misbehaving sites).
If you only have very little disk (netbooks/chromebooks/tablets) etc etc
you don't want to fill it to the brim with temp video data.

And regarding E it is to simplify uploading the video to
your favorite site. The scratch data probably needs to be stored on disk,
and not in RAM. Even the standard says "create a file". I don't feel
strongly about this though.

/Tommy

On Thu, Dec 8, 2011 at 18:32, Travis Leithead <travis.leithead@microsoft.com
> wrote:

>  Let me translate this into a set of requirements:****
>
> A. The ability to stop a recording independently of retrieving the
> recorded data****
>
> B. Stop recordings automatically when MediaStreams end****
>
> C. Circular buffer for size time/limitation****
>
> D. Indicate the recording format with a MIME type****
>
> E. Use a File (rather than Blob) for recording output.****
>
> F. peek() to be able to extract recorded data so far without stopping the
> recorder.****
>
> ** **
>
> May I suggest one more based on your points below:****
>
> G. Ability to discover what recording MIME types are available in the UA**
> **
>
> ** **
>
> I'm totally behind A, B, & D, as these just seem obvious to me.****
>
> ** **
>
> Followup questions:****
>
> * Can you think of any scenarios that would necessitate C, other than UA
> size limitations? It seems like circular buffers are great for DVR
> scenarios, but you'd need a lot more ability to control the output (like
> seek support). Many of these scenarios are already supported by
> <video>--can we find a way to make them work together?****
>
> * Why File? Over Blob, a File adds "name" and "lastModifiedDate". What
> will the "name" be? It seems unnecessary since you'd need a way of naming
> the recording when you extract it, or before you start recording. For
> "lastModifiedDate" the recording is conceptually "in memory" and not
> necessarily committed to disk (though implementations will likely record to
> disk in a temp location, since recordings can be very large).****
>
> * As I've mentioned before, making the recording output a Stream [1]
> solves requirement F, since you can get the immediate recorded stream, and
> "collect" it into a Blob, and/or slice it up as desired.****
>
> ** **
>
> [1] http://dvcs.w3.org/hg/webapps/raw-file/tip/StreamAPI/Overview.htm ****
>
> ** **
>
> -Travis****
>
> ** **
>
> *From:* Tommy Widenflycht (ᛏᚮᛘᛘᚤ) [mailto:tommyw@google.com]
> *Sent:* Thursday, December 08, 2011 4:36 AM
> *To:* public-webrtc@w3.org; public-media-capture@w3.org
> *Subject:* MediaStreamRecorder ideas****
>
> ** **
>
> In my not-so-humble opinion the MediaStreamRecorder isn’t usable right
> now, and the API needs to be changed. I suggest the following changes as a
> minimum delta:****
>
>    1. MediaStreamRecorder should have a stop() method. Calling this will
>    stop the recorder but not throw away the data, the data will live until the
>    recorder is garbage collected. If the associated MediaStream stops/ends the
>    recorder should do so as well. Also the UA should be allowed to have a
>    maximum file size/time length and be allowed to throw away the oldest data
>    circular buffer style.****
>    2. MediaStream::record should take a optional MIME type (which may
>    have parameters). If no MIME type is given the UA can pick whatever is most
>    suitable, but if a MIME type is given it must be used. If the UA doesn’t
>    support the type or recording in general it should return a null pointer.
>    ****
>    3. MediaStreamRecorder::getRecordedData should return a File (instead
>    of a Blob) and stop recording. MediaStreamRecorder will optionally support
>    a peek() method that will return a Blob of the data recorded this far. This
>    will make life easier for weaker UAs.****
>
>  Thoughs?****
>
> ** **
>
> /Tommy****
>
> ** **
>
> --
> Tommy Widenflycht, Senior Software Engineer
> Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
> Org. nr. 556656-6880
> And yes, I have to include the above in every outgoing email according to
> EU law.****
>



-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to
EU law.