Re: [whatwg] File API Streaming Blobs

FYI I'm working on an experimental extension to Chromium to allow media data
to be streamed into a media element via JavaScript. Here is the draft
spec<http://html5-mediasource-api.googlecode.com/svn/tags/0.2/draft-spec/mediasource-draft-spec.html>
and
pending WebKit patch <https://bugs.webkit.org/show_bug.cgi?id=64731> related
to this work. I have simple WebM VOD playback w/ seeking working where all
media data is fetched via XHR.

Aaron

On Mon, Aug 8, 2011 at 7:16 PM, Charles Pritchard <chuck@jumis.com> wrote:

> On 8/8/2011 2:51 PM, Glenn Maynard wrote:
>
>  On Mon, Aug 8, 2011 at 4:31 PM, Simon Heckmann <simon@simonheckmann.de<mailto:
>> simon@simonheckmann.de**>> wrote:
>>
>>    Well, not directly an answer to your question, but the use case I
>>    had in mind is the following:
>>
>>    A large encrypted video (e.g. HD movie with 2GB) file is stored
>>    using the File API, I then want to decrypt this file and start
>>    playing with only a minor delay. I do not want to decrypt the
>>    entire file before it can be viewed. As long as such as use case
>>    gets covered I am fine with everything.
>>
>>
>> Assuming you're thinking of DRM, are there any related use cases other
>> than crypto?  Encryption for DRM, at least, isn't a very compelling use
>> case; client-side Javascript encryption is a very weak level of protection
>> (putting aside, for now, the question of whether the web can or should be
>> attempting to handle DRM in the first place).  If it's not DRM you're
>> thinking of, can you clarify?
>>
>>
> Jonas Sickling brought up a few cases for XHR-based streaming of
> arraybuffers: progressive rendering of word docs and PDFs.
> WebP and WebM have had interesting packaging hacks. Packaging itself,
> whether DRM or not, is compelling.
> PDF supports embedded data, a wide range of formats. GPAC provides many
> related tools (MP4 based, I believe):
> http://gpac.wp.institut-**telecom.fr/<http://gpac.wp.institut-telecom.fr/>
>
> The audio and video tags drop frames
> It seems to me that if a listener is not registered to the stream, data
> would just be dropped.
>
> As an alternative, the author could register a fixed length circular
> buffer.
>
> For instance, I could create  1 megabyte arrayview, run
> URL.createBlobStream(**ArrayView)
> and use .append(data). That kind of structure may support multicast
> (multiple audio/video elements)
> and improved XHR2 semantics. The circular buffer, itself, is easy to
> prototype: subarray
> works well with typed arrays.
>
> Otherwise relevant, is the work on raw audio data
> that Firefox and Chromium have released as experimental extensions.
> It does work on a buffer-based system.
>
> -Charles
>
>
>
>
>
>
>
>