[whatwg] Extending HTML 5 video for adaptive streaming

@acolwell:
Is the appendData method one your suggesting or one already specified/existing?

@robert:
Some problems with concept of blobs being appended to, or as I have
previously described as "Streaming Blobs" was mentioned at
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/032221.html
I'm not exactly sure what that meant - but I'd expect the ideas
discussed are similar.

On Fri, Jul 1, 2011 at 9:13 AM, Robert O'Callahan <robert at ocallahan.org> wrote:
> On Fri, Jul 1, 2011 at 4:59 AM, Aaron Colwell <acolwell at google.com> wrote:
>
>> I've also been looking at the WebRTC MediaStream API and was wondering if
>> it
>> makes more sense to create an object similar to the LocalMediaStream
>> object.
>> This has the benefits of unifying how media streams are handled independent
>> of whether they come from a camera or a JavaScript based streaming
>> algorithm. This could also enable sending the media stream through a
>> Peer-to-peer connection instead of only allowing a camera as a source. Here
>> is an example of the type of object I'm talking about.
>>
>
> I think MediaStreams should not be dealing with compressed data except as an
> optimization when access to decoded data is not required anywhere in the
> stream pipeline. If you want to do processing of decoded stream data (which
> I do --- see
> http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html),
> then introducing a decoder inside the stream processing graph creates all
> sorts of complications.
>
> I think the natural way to support the functionality you're looking for is
> to extend the concept of Blob URLs. Right now you can create a binary Blob,
> mint a URL for it and set that URL as the source for a media element. The
> only extension you need is the ability to append data to the Blob while
> retaining the same URL; you would need to initially mark the Blob as "open"
> to indicate to URL consumers that the data stream has not ended. That
> extension would be useful for all sorts of things because you can use those
> Blob URLs anywhere. An alternative would be to create a new kind of object
> representing an appendable sequence of Blobs and create an API to mint URLs
> for it.
>
> Note that with my API proposal above, you can get a MediaStream from a media
> element that's using any URL and send that through a PeerConnection.
>
> Rob
> --
> "If we claim to be without sin, we deceive ourselves and the truth is not in
> us. If we confess our sins, he is faithful and just and will forgive us our
> sins and purify us from all unrighteousness. If we claim we have not sinned,
> we make him out to be a liar and his word is not in us." [1 John 1:8-10]
>



-- 
Adam Malcontenti-Wilson

Received on Thursday, 30 June 2011 17:20:12 UTC