W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2012

Re: Tracks in multiple Stream . Re: Teasing apart the data API questions

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 18 May 2012 08:39:06 +0200
Message-ID: <4FB5EE8A.8030904@ericsson.com>
To: public-webrtc@w3.org
On 05/17/2012 10:52 PM, Cullen Jennings wrote:
>
> On May 17, 2012, at 2:28 PM, Harald Alvestrand wrote:
>
>> On 05/17/2012 09:03 PM, Cullen Jennings wrote:
>>> Sure, that all makes sense along with the examples you and Harald raised but I should have been more precise in my original email. I'm talking about in the context of a single PeerConenction objects. In all these example there would still only need to be one of theses media streams added to a given PeerConenction object. So, I'm still at the same place of not seeing why we need this that I was when I started this thread...
>> So when you said
>>
>> "I'd like to back up and talk about normal Tracks being attached to more
>> than one stream."
>>
>> you really meant whether it should be possible to have more than one
>> track containing the same stream added to a single PeerConnection object?

Should this not be the other way around: "should it be possible to have 
more than one MediaStream containing the same track added to a single 
PeerConnection object?"

And I agree to that it would not make sense to stop that from happening.

>
> Yes - and apologies for my email not actually saying that in any way
>
>>
>> That's not what I thought you were asking ....
>
> Uh, yah, my fault not yours
>
>> I really don't see the
>> useful situation either, but OTOH adding such a restriction in the API
>> seems quite difficult to me; we would have to specify that the AddStream
>> of a PeerConnection object could fail if one of the tracks inside the
>> stream is already attached to the same PeerConnection, which is a "late
>> surprise".
>
> agree that sort of API error would just make things worse - I think the point I was trying to get to is that they are synchronized.

My personal view is that everything that originates from the same 
getUserMedia context should be kept in sync. I proposed this at TPAC 
last year, but got pushed back; the current assumption AFAIK is that 
everything in the same MediaStream is kept in sync.

Given this, the web author has the option to collect all tracks it wants 
to be kept in sync in one MediaStream (and add that MediaStream to the 
PeerConnection). If the author does not (and sends the tracks in 
different MediaStreams) there is no guarantee that sync is preserved.
Having the same track being sent over the same PC in two (or more) 
MediaStreams is just a special case of this.

>
>>
>> The way I think of the signalling now (NOTE: more comments on
>> draft-alvestrand-rtcweb-msid always welcome!), it would be simple to
>> represent on the wire; "just" allow multiple MSID values for the same
>> SSRC, and send the track once.
>>
>> Other details could be more complex.
>>
>>>
>>> On Apr 23, 2012, at 3:30 PM, Randell Jesup wrote:
>>>
>>>> On 4/23/2012 5:08 PM, Harald Alvestrand wrote:
>>>>> On 04/23/2012 05:01 PM, Cullen Jennings wrote:
>>>>>> On Apr 15, 2012, at 6:42 , Harald Alvestrand wrote:
>>>>>>
>>>>>>> B1: Should the data "channel" be similar to a MediaStreamTrack,
>>>>>>> including the ability to be part of one or more MediaStreams,, be
>>>>>>> connected to consumer entities, be muted, and so on?
>>>>>> I'd like to back up and talk about normal Tracks being attached to
>>>>>> more than one stream. I don't think this makes any sense and certainly
>>>>>> adds to implementation complexity. Lets say we have tracks A , B, and
>>>>>> C. And tow streams S1 and S2. If A and B are in S1, and B and C are in
>>>>>> S2, it effectively mens all three are synchronized so why not just
>>>>>> have all there in a single stream?
>>>>>>
>>>>>> I am missing the use case for a single track in more than one stream.
>>>>> The classical example is when one uses GetUserMedia to get audio and
>>>>> video, and one wishes to extract only the video stream and show it in a
>>>>> preview element, while both the audio and video should be sent to the
>>>>> remote site via a PeerConnection.
>>>> Correct.  Or attach audio from a single mic to two media streams, one for the front camera and one for the rear.  And the two streams may have totally different destinations (different peerconnections, or local display per Harald).
>>>>
>>>> --
>>>> Randell Jesup
>>>> randell-ietf@jesup.org
>>>>
>>>
>>>
>>
>>
>
>
Received on Friday, 18 May 2012 06:39:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 18 May 2012 06:39:34 GMT