W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2011

RE: Assigning MediaStream objects to HTML media elements

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Thu, 15 Dec 2011 18:22:48 +0000
To: Rich Tibbett <richt@opera.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B38381CB397@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com>
>-----Original Message-----
>From: Rich Tibbett [mailto:richt@opera.com]
>Right now in the W3C proposal developers are expected to indirectly mint
>a new temporary URL (via window.URL.createObjectURL) to assign a
>MediaStream to a video/audio element. To coincide with direct assignment
>of a Stream object to a video element, our work also defined how Stream
>objects that have been assigned to HTML media elements should be labeled
>if or when a developer attempts to resolve the src URL/URI. We settled
>on 'about:streamurl' to be a reserved, though unresolvable, about: URI,
>to indicate that the media element is displaying/playing an object that
>implements the MediaStream interface (and hence the media element is in
>stream mode and has all the behaviors of that mode as defined in [1]).
>This direct object assignment requires less code to assign Stream
>objects to video/audio elements. It works really well to date in all
>Opera implementations and we'd like to apply this behavior to the W3C
>spec pending further discussion and feedback.

I'm not sure how I feel about this. I don't believe that we should support _both_ direct-assignment as well as createObjectURL; what would the best-practices be? What would be the advantage to using one vs. the other? Will this just confuse web developers?

If we decide that we shouldn't support both, then my preference is the existing design because it's a pattern already [or soon to be] familiar to web developers. As you mention, direct-assignment requires a new, carefully specified behavior for the src attribute of various HTML elements, not to mention it seems weird to assign an object to an attribute that typically takes URLs...

An alternative (thinking out of the box a little), is to forget the createObjectURL approach, and add an extension to the HTMLMediaElement solely for the purpose of assigning a Media Stream:

partial interface HTMLMediaElement {
   void enterStreamingModeViaMediaStream( MediaStream stream);

I still prefer createObjectURL, but there may be some merits to something like that...

Regarding how the video/audio tag enter "streaming" mode and their behavior, I definitely agree that this needs to be specified. Either with getusermedia or via WebRTC.
Received on Thursday, 15 December 2011 18:24:00 UTC

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