- From: Tommy Widenflycht <tommyw@google.com>
- Date: Tue, 26 Jul 2011 15:03:26 +0200
On Tue, Jul 26, 2011 at 07:30, Ian Hickson <ian at hixie.ch> wrote: > > > > If you send two MediaStream objects constructed from the same > > LocalMediaStream over a PeerConnection there needs to be a way to > > separate them on the receiving side. > > What's the use case for sending the same feed twice? > There's no proper use case as such but the spec allows this. > > > > I also think it is a bit unfortunate that we now have a 'label' property > > on the track objects that means something else than the 'label' property > > on MediaStream, perhaps 'description' would be a more suitable name for > > the former. > > In what sense do they mean different things? I don't understand the > problem here. Can you elaborate? > label on a MediaStream is a unique identifier, while the label on a MediaStreamTrack is just a description like "Logitech Vision Pro", "Line In" or "Built-in Mic". I too find this a bit odd. > > > On Wed, 20 Jul 2011, Tommy Widenflycht (?~[~O?~Z??~[~X?~[~X?~Z?) wrote: > > On Mon, Jul 18, 2011 at 20:38, Ian Hickson <ian at hixie.ch> wrote: > > > On Mon, 18 Jul 2011, Tommy Widenflycht (??~[~O??~Z????~[~X??~[~X??~Z??) > wrote: > > > > > > > > I am very confused regarding the below paragraph from the latest > > > > spec: > > > > > > > > When a track in a MediaStream parent is disabled, any > > > > MediaStreamTrack objects corresponding to the tracks in any > > > > MediaStream objects that were created from parent are disassociated > > > > from any track, and must not be reused for tracks again. If a > > > > disabled track in a MediaStream parent is re-enabled, from the > > > > perspective of any MediaStream objects that were created from parent > > > > it is a new track and thus new MediaStreamTrack objects must be > > > > created for the tracks that correspond to the re-enabled track. > > > > > > > > After cloning a LocalMediaStream it looks like this: > > > > > > > > LocalMediaStream -> MediaStream1 > > > > Track1(E) Track1(E) > > > > Track2(E) Track2(E) > > > > Track3(E) Track3(E) > > > > > > > > and as I interpret the spec it looks like this if Track1 in the > > > > LocalMediaStream is disabled: > > > > > > > > LocalMediaStream -> MediaStream1 > > > > Track1(D) Track2(E) > > > > Track2(E) Track3(E) > > > > Track3(E) > > > > > > Correct so far (though I'd avoid the term "cloning" since it's not > > > quite what's going on here -- the spec uses "forking", which may be > > > closer though is still not ideal). > > > > > > > So Track1 disappears from the MediaStream1 object and doesn't come > > > > back even if Track1 in the LMS object is enabled: > > > > > > > > LocalMediaStream -> MediaStream1 > > > > Track1(E) Track2(E) > > > > Track2(E) Track3(E) > > > > Track3(E) > > > > > > No, it'll create a new track object: > > > > > > LocalMediaStream -> MediaStream1 > > > Track1(E) Track4(E) > > > Track2(E) Track2(E) > > > Track3(E) Track3(E) > > > > > > This is specified in the sentence that starts "If a disabled track in > > > a MediaStream parent is re-enabled...". > > > > Thanks for the explanation. To me this sounds overly complicated, why > > not just make it so that an disable of a track will override the track > > settings for forked MediaStreams? > > I don't understand what you mean. How would that be different? > > If I may make an analogy to the real world: plumbing. Each fork of a MediaStream is a new joint in the pipe, my suggestion introduces a tap at each joint. No matter how you open and close the tap at the end (or middle); if any previous tap is closed there's nothing coming through. The spec currently removes and add the entire pipe after the changed joint. > > > Also some follow-up questions regarding the new TrackLists: > > > > What should happen when a track fails? Should the entire stream fail, > > the MSTrack silently be removed or the MSTrack disassociated with the > > track (and thus becoming a do-nothing object)? > > What do you mean by "fails"? > Yanking the USB cable to the camera for example. This should imho stop the MS, not just silently send black video. > > What should happen when a stream with two or more video tracks is > > associated to a <video> tag? Just render the first enabled one? > > Same as if you had a regular video file with multiple tracks. > > And that is? Sorry, this might be written down somewhere and I have missed it. /Tommy -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 And yes, I have to include the above in every outgoing email according to EU law.
Received on Tuesday, 26 July 2011 06:03:26 UTC