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

Re: Detailf for teleconf tomorrow

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 6 Dec 2012 07:51:31 -0800
Message-ID: <CABcZeBOEB8B9k7QqDg_qdv4oLqbQ0oXzygTJgJ5EXPegJiBfQA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Adam Bergkvist <adam.bergkvist@ericsson.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
I've reviewed these slides, but I don't see that any of the proposed
solutions
addresses the alleged problem, namely that you can't usefully generate
SDP prior to device consent.

All of these approaches attempt to fix this by providing a placeholder
stream
before consent that can be added to the PC, thus enabling negotiation
to continue. Unfortunately, because the stream is a placeholder and consent
and device selection are currently intertwined, I don't think this is going
to work.

The problem is that in many cases the properties of media you are sending
depend on the device that is generating it. For instance, if i have two
cameras,
only one of which is H.264 capable, then I need to know which camera
the user is going to select *before* I offer H.264. I suppose you might
choose to offer only the common subset that all your devices can do,
but now you're asking for a re-offer in a large number of cases.

In the spirit of making simple things easy and hard things possible, I
suggest
a different approach:

1. Keep the current API the same.
2. Add a new API to PC that will let you create dummy streams with
    arbitrary properties and then plug them into real streams.

For instance:

var placeholder_stream = pc.AddStreamPlaceholder({
     {
       audio:true,
       video:true,
     }
);

pc.createOffer(...);

getUserMedia({audio:true, video:true},
             function(stream) {
               stream.placeholder = placeholder_stream;  // New property
               pc.addStream(stream);
             });

A design like this would have a number of advantages:
1. It would make the current idiom continue to work.
2. It would avoid having the notion that streams exist but aren't ready.
3. It would allow the application to directly tell the PC about what
properties
    it wanted the placeholders to have.

-Ekr


On Wed, Dec 5, 2012 at 11:35 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> I meant to send these much earlier, but clearly forgot.
>
> I'd also like to suggest a swap with Travis.  I think that what Travis
> is presenting will be more of the API fundamentals.  The outcome of
> that discussion might be relevant to what I'm going to cover.
>
> On 5 December 2012 05:29, Adam Bergkvist <adam.bergkvist@ericsson.com>
> wrote:
> > On 2012-12-05 09:49, Stefan Håkansson LK wrote:
> >>
> >> Time: 5pm - 6:30pm CET (December 6 2012)
> >>
> >> Zakim:
> >> *UW_MdCap*
> >> Tuesday, 6 December, 16:00-17:30 UTC (11:00am-12:30pm Boston local)
> >> Zakim Bridge +1.617.761.6200, conference 6227 ("mcap")
> >>
> >> IRC: irc.w3.org, #mediacap
> >>
> >> Agenda items:
> >>
> >> * Representation of MediaStreamTracks in a MediaStream (Adam)
> >
> >
> > Enclosed my slides for tomorrow.
> >
> > /Adam
>
Received on Thursday, 6 December 2012 15:52:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:03 GMT