Re: MediaStream Constructor

On 05/10/2012 06:00 AM, Randell Jesup wrote:
> On 5/9/2012 11:20 PM, Anant Narayanan wrote:
>> Hi all,
>>
>> We discussed earlier today about the possibility of combining 
>> multiple MediaStreams into a single stream via it's constructor; in 
>> the context of allowing multiple calls to getUserMedia to obtain a 
>> stream for each camera. Even if we don't end up allowing that, it 
>> might be useful in other contexts.
>>
>> Robert O'Callahan has suggested that we extend the MediaStream 
>> constructor to take a list of Objects, which can be a combination of 
>> MediaStreams or MediaStreamTracks.
>>
>> [Constructor MediaStream(obj1, obj2, obj3, ..., objN)];
>>
>> This behavior is much in line with functions like Array.concat [1], 
>> and highlights the flexibility JS programmers are accustomed to, 
>> since we are not restricted with type safety as much as other languages.
>>
>> I haven't mentioned MediaStreamTrackLists though, because I think 
>> they are a redundant type that may simply be represented as an array 
>> of MediaStreamTracks. If there are good reasons to keep the 
>> MediaStreamTrackList around, please do let me know. Otherwise, we can 
>> modify the MediaStream object to be:
>
> Well, in theory the arrays of local and remote streams are 'live' 
> arrays, and it also was said on the list that they don't compact when 
> one is removed (to make them easy to match up with SDP m= lines) - 
> though I have to say that MediaStreams don't map well to m= lines if a 
> MediaStream as < or > 1 stream of a given type...
>
> We need to have a clear mapping of MediaStreams, MediaStreamTracks, 
> and SDP m= lines including for complex cases with tracks and streams 
> being added and removed.
Correction: MediaStreamTracks don't map to m= lines, they map to SSRCs.
m= lines map to media types.

The msid draft proposes signalling their index values using an 
SSRC-specific attribute; it would be convenient not to have to resignal 
all the tracks (and avoid interesting race conditions) when a track is 
deleted.

>
>

Received on Thursday, 10 May 2012 05:45:01 UTC