Re: Describing recording by means of the Media Source interface

On 08/23/2012 04:55 PM, Rich Tibbett wrote:
> Harald Alvestrand wrote:
>> I'm scanning the Media Source interface, and seeing how it describes
>> data formats for the buffers it uses.
>>
>> It seems to me logical to describe the recording interface in such a way
>> that:
>>
>> If there exists a video stream v, a media source msrc and a media stream
>> ms, and (conceptually) msProducesData(buffer) is called every time data
>> is available at the recording interface,
>> then the following code:
>>
>> // Setup
>> v.src = window.URL.createObjectURL(msrc);
>> buffer = msrc.addSourceBuffer(mimetype)
>> // So far unknown setup for the recorder interface
>>
>> // playback
>> msProducesData(data) {
>> buffer.append(data)
>> }
>>
>>
>> should produce the same display (possibly somewhat delayed due to
>> buffering) as
>>
>> v.src = window.URL.createObjectURL(ms)
>>
>> The media source definition is available here:
>>
>> http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html 
>>
>>
>>
>> It seems to me that if we can make sure this actually works, we'll have
>> achieved a little consistency across the media handling platform.
>>
>
> I've been trying to figure out exactly the purpose of having access to 
> _real-time_ buffer data via any type of MediaStream Recording API. It 
> is fairly clear that byte-level access to recorded data could be 
> solved with existing interfaces, albeit not in real-time as the media 
> is being recorded to a file but once a file has already been recorded 
> in its entirety and returned to the web app.

People have told me that they can't keep a long video recording in 
memory, and they don't want to land it on file until they know that it 
belongs there (especially on devices where the distinction isn't clear).

Applications that don't need access to a whole recording shouldn't need 
to store all of it; a chunked interface is a simple way of saying "once 
I've taken responsibility for this chunk, the browser doesn't have to 
remember it any more".

Received on Thursday, 23 August 2012 15:59:40 UTC