W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2012

Re: Direct assignment of MediaStream to <video> (Re: PROPOSAL: Use events instead of callbacks)

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 20 Mar 2012 13:29:28 +0100
Message-ID: <4F687828.3050606@ericsson.com>
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 03/16/2012 10:59 PM, Anant Narayanan wrote:
> On Mar 15, 2012, at 12:48 PM, Travis Leithead wrote:
>> * I'm not comfortable overloading the src property. This opens the
>> door to a lot of weird discrepancies between content attribute src
>> and IDL attribute src. I don't want to open the door to
>> URL-accepting properties becoming extensible by other arbitrary
>> specs. I think File API established the convention for this
>> extensibility by creating the blob: protocol.
>
> If we decide to go ahead with URLS we have to deal with the
> portability of strings. For instance, what happens if the web page
> passes the URL to another web site, which the user then opens in a
> different tab, where a video.src assignment is made?
>
> URLs now have to be tied to the origin to which they were issued and
> the UA must enforce this. This is not a problem with URLs as they
> exist today as possession of the URL implies access to the data (and
> in the case of blob: the URL itself contains the data). This is not
> true for MediaStreams - MediaStreams are transient, issued to only a
> certain origin, and perhaps even just a tab.

If I read the File API spec correctly ([1]), the URL created by 
"createObjectURL" would only be usable in the origin where it was created.

I wonder if MediaStreams are really so different from blob's/file's (or 
Streams) that it would make sense to define another way. createObjectURL 
is after all an established and expected pattern, it seems natural to me 
to extend it to MediaStreams.

[1] http://www.w3.org/TR/FileAPI/#originOfBlob

Translating these
> requirements to a URL feels rather clunky to me, and are best
> represented as objects (that are not by their very nature,
> portable).
>
>> Specifying the "streaming behavior" as is noted in [5] is very
>> important; I strongly support that, and I think it needs to happen
>> irrespective of whichever "binding" approach is used for media
>> elements.
>
> +1. roc's proposal for MediaStreamProcessing
> (https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html)
> has ideas in similar vein.
>
> -Anant
Received on Tuesday, 20 March 2012 12:29:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:09 UTC