[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 <video> tag? Just render the first enabled one?

/Tommy

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

Received on Wednesday, 20 July 2011 05:28:46 UTC