- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 18 Apr 2013 11:38:26 +0200
- To: public-media-capture@w3.org
I think, with the changes Martin proposed done, that this looks good. Stefan On 2013-04-17 09:19, Adam Bergkvist wrote: > On 2013-04-16 18:40, Martin Thomson wrote: >> I like this. The text on enabled/muted is clear enough that I believe >> it will avoid confusion altogether. >> >> On 16 April 2013 05:01, Adam Bergkvist <adam.bergkvist@ericsson.com> >> wrote: >>> *** MediaStreamTrack Lifecycle and Media Flow *** >>> >>> The MediaStreamTrack interface lets the script control a single flow of >>> media. The live state indicates that the track source is active and the >>> track renders media. >> >> I don't know what "live state" refers to here. Maybe this is more >> obvious with highlighting on the "live" keyword, but it isn't clear >> from context that you are talking about readyState. >> >> You probably do need to include some more thorough description about >> the actual lifecycle (new/live/ended). The title mentions it, but the >> above doesn't make it clear that you are talking about lifecycle. We >> probably need something like: >> -- >> >>> The MediaStreamTrack interface lets the script control a single flow of >>> media. >> >> A MediaStreamTrack has three stages in its lifecycle. A track begins >> as "new" prior to being connected to an active source. >> >> Once connected, the 'started' event fires and the track becomes >> "live". In the "live" state, the track is active and media is >> available for rendering at a sink (e.g., an HTML <video> or <audio> >> element). >> >> <insert text on muting and rendering> >> >> A track becomes "ended" and the 'ended' event fires when the source of >> a track is disconnected or exhausted. > > Looks good to me. > > My first idea was to say less about the lifecycle (and change the title) > to not introduce redundant information. But at a closer look it's > obvious that the MediaStreamTrack lifecycle is underspecified; most of > the information is in the non-normative Event Summary section. So let's > have it in this section. > > /Adam >
Received on Thursday, 18 April 2013 09:38:49 UTC