RE: [Exposed] attribute on our APIs

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Wednesday, May 20, 2015 1:10 PM
> To: Mathieu Hofman; Martin Thomson
> Cc: Stefan Håkansson LK; public-media-capture@w3.org; Iņaki Baz Castillo;
> annevk@annevk.nl
> Subject: Re: [Exposed] attribute on our APIs
> 
> Den 20. mai 2015 21:57, skrev Mathieu Hofman:
> > I realize this is bigger than the Exposed attribute, and I actually think it's not
> clear how things should behave (or are even implemented today).
> >
> > While using the `srcObject` is the specified way to attach a MediaStream to
> a VideoElement, both Firefox and Chrome still support the `createObjectURL`
> API.
> > The generated URL is tied to the domain, and *today* can be used in other
> windows. Here is a fiddle to show this:
> http://jsfiddle.net/mhofman/z5ake180/
> > The caveat in Chrome is that the windows needs to be in the same process
> (one way to trigger this is window.open, or simply duplicate the tab). I'm not
> sure how Firefox handles its processes but it looks like the stream url is
> usable from all windows no matter how they're created.
> 
> 
> 
> Interesting; I think this is a bug in Chrome, and not something that was
> intended to work.
> 
> We shouldn't allow this if it only works some of the time.
> (the default in Chrome is one process per tab, I think except for tabs
> open from the same security origin.)

Correct, the tabs needs to be related in chrome (duplicate a tab does this, so does opening a new window with same origin though JS or anchor).
I'm not sure if this limitation is at the URL level or at the media layer, but I think I've successfully passed Blob URLs between processes in Chrome before (using SharedWorker), so it could very well be a limitation at the media layer.

> 
> > Now to me this shows that there is *some* browser support to access and
> render a MediaStream in another window.
> >
> > I realize we're late along the process for the MediaStream and Capture
> spec to be talking about adding structured cloning support, but here are a
> few things to consider:
> > - WebRTC is only getting now to the point where apps are moving further
> than the basic one-on-one video chat use case. These new use cases require
> more complex UX where the limit of using a single window is getting felt.
> Firefox Hello and Google Hangouts have a very interesting approach to
> having the UI outside of a regular page, but this "works" right now because
> calls are initiated and handled entirely using proprietary browser extensions
> and never involve a regular web page. If you want to transition a regular web
> app to such a multi-window model, we're out of luck.
> > - Screen sharing as a new type of media stream is barely getting stabilized
> as a spec. Because of that, some use cases are starting to emerge just now.
> Being able to pop others' video out and have them float over while sharing
> another tab or app is something that would be extremely useful.
> > - postMessage data throughput performance have historically been poor,
> transfer support is very limited, transferControlToProxy is nowhere to be
> seen, WebSockets in Workers has barely landed in Firefox, all of which has so
> far made usage of workers fairly impractical in the wild. However these
> things have been specified and are slowly getting there. At Citrix we would
> definitely like to access the pixels of a screen sharing stream directly in a web
> worker and process it there. While I realize we could get the ImageData in
> the main thread and send that over postMessage, this approach is inefficient
> at best since we incur the cost of copying a lot of large buffers.
> >
> > I think we shouldn't block ourselves out of potentially interesting use cases
> that we are just starting to think about now, simply because it might be
> complex for browser to implement down the road.
> >
> 
> You can, of course, get a videostream from one tab to another by using a
> PeerConnection....

PeerConnection involves sockets, encoding, decoding, which introduces latency, high CPU usage, scaling, artifacts, etc. Oh and other little pesky detail, you cannot access pixels of remote streams anyway...

> 
> > While I don't want to delay LC, what's the best approach to make sure we
> can one day support these use cases?
> >
> > Mathieu

Received on Wednesday, 20 May 2015 20:33:55 UTC