Intent to Implement and Ship: Add MediaStream.active attribute

206 views
Skip to first unread message

Qin, Jiajia

unread,
Jan 20, 2015, 10:19:27 PM1/20/15
to joc...@chromium.org, h...@chromium.org, pe...@chromium.org, to...@chromium.org, blin...@chromium.org

Contact emails

jiaji...@intel.com

 

Spec

http://w3c.github.io/mediacapture-main/getusermedia.html#widl-MediaStream-active

 

Summary

Implement  ‘active’ attribute, ‘onactive’ and ‘oninactive’ events for Mediastream

 

Motivation

Ended is deprecated. Currently we use MediaStream.active attribute to record MediaStream object’s status. A MediaStream can go from inactive to active, and vice versa.

 

The below is the spec changes for this attribute.

ACTION-25: Switch mediastream.inactive to mediastream.active

Replaced ended with inactive for MediaStream (resolves bug 21618).

 

Compatibility Risk

None

 

Ongoing technical constraints

None

 

Will this feature be supported on all six Blink platforms(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

 

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=450463

 

Link to entry on the feature dashboard

small change

 

Requesting approval to ship?

Yes

 

Regards,

Jiajia

 

Philip Jägenstedt

unread,
Jan 21, 2015, 10:39:47 AM1/21/15
to Qin, Jiajia, joc...@chromium.org, h...@chromium.org, pe...@chromium.org, to...@chromium.org, blin...@chromium.org
LGTM

The spec says "queue a task that sets the object's active attribute to
false and fire a simple event named inactive at the objec" and "queue
a task that sets the object's active attribute to true and fire a
simple event named active at the object." Please be very pedantic
about this, so that it's impossible for scripts to observe the
transition in MediaStream.active before the event has fired.
HTMLMediaElement doesn't (per spec) do all attribute transitions right
before the event is fired, and it's quite annoying.

Also, what's the plan for MediaStream.ended? It doesn't make sense in
the new model, so what will it return when a MediaStream has gone from
active to inactive and then back to active again? If that raises any
difficult questions, you might consider removing it at the same time:
https://www.chromestatus.com/metrics/feature/timeline/popularity/526

Philip
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

Harald Alvestrand

unread,
Jan 21, 2015, 11:42:34 AM1/21/15
to Philip Jägenstedt, Qin, Jiajia, joc...@chromium.org, h...@chromium.org, pe...@chromium.org, to...@chromium.org, blin...@chromium.org
The plan for MediaStream.ended is to delete it. There are probably scripts or tools that use it, and could switch to MediaStream.active, so it didn't seem reasonable to go for deleting it instantly.

Seems that we attached counters to it in December; is 0.0003% usage considered small enough that we could just delete it with no further warning?

Philip Jägenstedt

unread,
Jan 21, 2015, 5:28:22 PM1/21/15
to Harald Alvestrand, Qin, Jiajia, joc...@chromium.org, h...@chromium.org, pe...@chromium.org, to...@chromium.org, blin...@chromium.org
Looking at the code it looks like MediaStream.ended and
MediaStream.stop() go together and should probably be removed
together. MediaStream.stop() has higher usage and will break harder
due to being a function:
https://www.chromestatus.com/metrics/feature/timeline/popularity/537

Immediate removal of both isn't unthinkable if the alternative is a
nonsensical API. What approach do you want to take, Jiajia?

Philip

Qin, Jiajia

unread,
Jan 22, 2015, 3:25:39 AM1/22/15
to Philip Jägenstedt, Harald Alvestrand, joc...@chromium.org, h...@chromium.org, pe...@chromium.org, to...@chromium.org, blin...@chromium.org
My implementation is in https://codereview.chromium.org/827673002
Currently, I try not to touch MediaStream.stop() and MediaStream.ended parts. These two features and MediaStream.active are coexist.
In fact, at the beginning, the spec wants to rename MediaStream.ended to MediaStream.inactive. But after a few times changes of spec,
MediaStream.active is different with MediaSteam.ended= false. MediaStream object can go from inactive to active. But once MediaStream.ended equals true, it seems that it can't change back to false.

In old implementation, once there is no MediaStreamTrack in MediaStream using MediaStream::removeTrack, it will set MediaStream.ended to true.
But it conflicts with MediaStream.active since in such situation, mediastream can still change back to active if MediaStream.addTrack is called.

So my approach is only MediaStream::streamEnded() can set MediaStream.ended as true. In other cases, MediaStream.ended keeps false. During this,
MediaStream can change between active and inactive. MediaStream.stop() and MediaStream.ended can be removed in future.

Thanks,
Jiajia

Philip Jägenstedt

unread,
Jan 22, 2015, 3:45:21 AM1/22/15
to Qin, Jiajia, Harald Alvestrand, joc...@chromium.org, h...@chromium.org, pe...@chromium.org, to...@chromium.org, blin...@chromium.org
Thanks Jiajia,

Per said in https://codereview.chromium.org/827673002#msg11 that it's
"probably better to just leave everything related to the ended
attribute and ended event unchanged for a while and just introduce
MediaStream.active /inactive in parallel." (I didn't notice the review
link in the tracking bug, sorry.)

Philip

Chris Harrelson

unread,
Jan 26, 2015, 7:41:47 PM1/26/15
to Philip Jägenstedt, Qin, Jiajia, Harald Alvestrand, joc...@chromium.org, h...@chromium.org, pe...@chromium.org, to...@chromium.org, blin...@chromium.org
LGTM

>>> > send an email to blink-dev+unsubscribe@chromium.org.

>>
>>
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to blink-dev+unsubscribe@chromium.org.
>
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Jochen Eisinger

unread,
Jan 27, 2015, 5:49:03 AM1/27/15
to Chris Harrelson, Philip Jägenstedt, Qin, Jiajia, Harald Alvestrand, h...@chromium.org, pe...@chromium.org, to...@chromium.org, blin...@chromium.org
lgtm3
Reply all
Reply to author
Forward
0 new messages