Re: Update of Doohickey/AddTrack proposal

On 02/12/2014 01:55 PM, Adam Bergkvist wrote:
> On 2014-02-11 22:04, Harald Alvestrand wrote:
>
>>>
>>> Out of the five streams, which one should this side use? Other tracks
>>> may come shortly that only belongs to a subset of the streams the
>>> first track belonged to. It's probably one of those streams I should
>>> use, but this becomes quite hard to manage.
>>>
>>
>> What do you mean by "use"?
>>
>> The track must be added to all streams that it's identified in
>> signalling to belong to, and no others.
>
> By "use" I, e.g., mean render. If a track is received, and it has info
> (from the sending side) that it belongs to five different
> MediaStreams. Which MediaStream should the receiving side render? It
> clearly needs app specific info from the sender side.

Agreed, any app receiving five streams needs to know what to do with them.

After all these mails, I think I revert to my original proposal from
Seattle:

- Removing AddStream is too hard, let's not do it.

I have a backup proposal, which is:

- Remove AddStream from the direct API
- Add two new functions:
  - AddStreamId (takes a stream as argument, tells the PC only that the
stream is
    interesting)
  - AddTrack (adds a track to the signalling)
- Document AddStream as an utility function that does AddStreamId +
AddTrack on all member tracks

MSIDs are produced only for tracks that are a member of at least one
stream added with AddStreamId.
(I haven't thought about transporting the track ID of tracks without a
stream yet.)

At the receiving side, an onaddstream event gets fired every time a new
stream ID is seen in an msid in signalling, and an onaddtrack event gets
fired every time a new track is identified.

This allows an app to either produce MediaStreams at the receiver (as is
the case today), or produce isolated tracks (which can be delivered
without a MediaStream) exactly the way a non-WebRTC application would be
doing.

But again, it seems that a complete proposal along these lines (or along
some other lines) should be made by some of the people who argued in
favour of removing AddStream. They understand the properties of that
proposal that they don't want to lose; I feel that I don't.

-- 
Surveillance is pervasive. Go Dark.

Received on Wednesday, 12 February 2014 18:27:01 UTC