- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Wed, 12 Jun 2013 11:03:24 +0200
- To: robert@ocallahan.org
- CC: Jim Barnett <Jim.Barnett@genesyslab.com>, Travis Leithead <travis.leithead@microsoft.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2013-06-12 08:05, Robert O'Callahan wrote: > On Wed, Jun 12, 2013 at 5:58 PM, Adam Bergkvist > <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote: > > On 2013-06-12 00:04, Robert O'Callahan wrote: > > I think it's helpful to have a permanent "ended" state. For > example, an > application might handle "ended" (or "inactive") the way Youtube > does, > and change state to display different UI. It's unexpected and > confusing > if the stream can suddenly revive again underneath, and would likely > lead to application bugs. > > > I don't really see these issues if active/inactive is documented > properly. > > The media elements can be played again after they end. > > > Yes but only if the application itself calls play() In which case it's > not unexpected. > > If a stream can leave its last state, then I think renaming that > state to active-something, as Jim proposes, makes sense. > > > I agree. > > If the last state is final, then I think we should keep it as ended. > But in that case, what's the state of a stream created with no args > to the constructor? It seems like we need a "new" state to represent > this since we can't use ended == true here. It possible to figure > out the "new" state right now, but it's not as obvious as the other > states. > > What I proposed above is that a stream transitions to the "ended" state > when it has no active tracks but did at some point in the past. That works, but the strange thing is that a stream can "recover" from not having any tracks in one case, but returning it to the track-less state is fatal. I agree that a final ended state is useful, but it would make more sense to base it on something else that all tracks being removed or becoming ended. I'll take a stream received via a PeerConnection as an example. dispatched at B-side by the addstream event: active a-side removes all tracks: inactive a-side re-adds live tracks: active a-side ends-all tracks: inactive a-side does removeStream(): ended Perhaps only streams created by getUserMedia() and PeerConnection should reach the ended state. That may bring us back to [1]. /Adam [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22270
Received on Wednesday, 12 June 2013 09:03:49 UTC