Re: MediaStreamRecorder ideas

On 12/09/2011 01:24 PM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
> 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.

Regarding this, I assume that (if becoming reality) the just proposed 
Quota API (<http://wiki.whatwg.org/wiki/Quota>) - that may become a 
WebApps WG item - can be a tool to protect from filling more than you want.

>
> 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 <mailto: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
>     <mailto:tommyw@google.com>]
>     *Sent:* Thursday, December 08, 2011 4:36 AM
>     *To:* public-webrtc@w3.org <mailto:public-webrtc@w3.org>;
>     public-media-capture@w3.org <mailto: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.

Received on Tuesday, 13 December 2011 17:34:31 UTC