Re: [whatwg] Enabling/disabling tracks in MediaStreams

[ᛏᚮᛘᛘᚤ]

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? This will definitely simplify implementation, and
confuse web developers less imho. MSTracks coming and going doesn't feel
right. Especially since there are no callbacks/events that a MS changes.

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 should happen when a stream with two or more video tracks is associated
to a  tag? Just render the first enabled one?

/Tommy

On Mon, Jul 18, 2011 at 20:38, Ian Hickson  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...".
>
> If you could explain how you are interpreting the current text I would be
> happy to fix the problematic area to be clearer (it's not clear to me
> what's unclear at the moment).
>
>
> On Mon, 18 Jul 2011, Harald Alvestrand wrote:
> >
> > What is the scenario in which this behavioiur is useful?
>
> The muting feature exists in order to allow authors to mute outgoing video
> while leaving outgoing audio and while still having a local video montior.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'




-- 
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.

Re: [whatwg] Enabling/disabling tracks in MediaStreams

[Ian Hickson]

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...".

If you could explain how you are interpreting the current text I would be 
happy to fix the problematic area to be clearer (it's not clear to me 
what's unclear at the moment).


On Mon, 18 Jul 2011, Harald Alvestrand wrote:
> 
> What is the scenario in which this behavioiur is useful?

The muting feature exists in order to allow authors to mute outgoing video 
while leaving outgoing audio and while still having a local video montior.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Enabling/disabling tracks in MediaStreams

[Anant Narayanan]

On 7/18/11 5:29 AM, Harald Alvestrand wrote:

Additional question:

What is the scenario in which this behavioiur is useful?


One use case is to selectively disable the video track in an ongoing 
audio/video session without disrupting audio in reaction to a congested 
network.


-Anant

Re: [whatwg] Enabling/disabling tracks in MediaStreams

[Harald Alvestrand]

Additional question:

What is the scenario in which this behavioiur is useful?

On 07/18/11 14:17, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) 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)

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)

And to get it back again has to create a new MediaStream object from the
LMS:

LocalMediaStream ->  MediaStream2
Track1(E)   Track1(E)
Track2(E)   Track2(E)
Track3(E)   Track3(E)

Is this interpretation correct?


/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.