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

Re: Next steps on RTCRtpSender "doohickey" proposal

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 8 May 2014 12:27:39 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1CFDFD74@ESESSMB209.ericsson.se>
On 2014-05-08 11:54, Harald Alvestrand wrote:
> On 05/08/2014 09:56 AM, Stefan Håkansson LK wrote:
>>> This is needed to make it possible to polyfill AddStream without adding
>>> a bunch of special cases.
>> I think the vast majority of apps needing polyfill send only one
>> MediaStream, and then there is no need to carry the StreamId over via
>> API and SDP.
>
> Apps that are the same on both sides need not worry; they can do
> whatever they want.
> Apps that talk to something that is not themselves need to not make
> assumptions about what the other app will or will not do.

My view is that the space we aid is so limited that it is not worth the 
extra complexity.

For example, imagine a case where there are three tracks, belonging to 
two different streams, that are being sent. With streamId in the 
addTrack API the remote end can assemble those two streams from the 
incoming tracks. But it would still out of band info about what each 
stream represents (e.g. to be able to display in the right element). And 
if you send that out of band, you can just as well send info about how 
the remote end should assemble the incoming tracks into streams.
Received on Thursday, 8 May 2014 12:28:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC