- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Wed, 12 Jun 2013 07:58:04 +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 00:04, Robert O'Callahan wrote: > On Wed, Jun 12, 2013 at 8:33 AM, Jim Barnett <Jim.Barnett@genesyslab.com > <mailto:Jim.Barnett@genesyslab.com>> wrote: > > Hmm, I thought we had agreed that MediaStreams can be reactivated. > If they can’t, then ‘ended’ is the right name for the attribute, and > attempting to add a Track to an ended stream should raise an error. > I’m in favor of letting them be reactivated – I can’t see any reason > not to do it. > > > 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. > I propose doing roughly what the MediaStreams Processing proposal did: > add an "auto-end" constructor parameter to MediaStream that defaults to > true, so that the stream permanently ends as soon as there are no > non-ended tracks and there was at least one non-ended track in the past. > But authors can set the parameter to false to indicate that the stream > should not automatically end just because there are no tracks. I'm still a bit confused around if stream can leave its "last" state. So my preference depends on that. If a stream can leave its last state, then I think renaming that state to active-something, as Jim proposes, makes sense. It feels very straight forward; as long as there's some activity in the stream (live tracks) the stream is active. An empty stream, regardless if it's emptied with removeTracks() calls or created with no args to the constructor, have no activity and is therefore inactive. 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. new : (ended == false) and "has no tracks" active : ended == false ended : ended == true /Adam
Received on Wednesday, 12 June 2013 05:58:30 UTC