[whatwg] PeerConnection, MediaStream, getUserMedia(), and other feedback

[Tommy Widenflycht (ᛏᚮᛘᛘᚤ)]

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.