Re: MediaStreamTrack Lifecycle and Media Flow

On 2013-05-07 18:56, Cullen Jennings (fluffy) wrote:
>
> This looks good from GUM point of view but when the track is used in
> context of webrtc, particular a track that has a remote source, I
> think we probably need to say a bit more.  I'd like to get at the
> what causes the differences from "black" packets flowing across the
> web vs no packets flowing across the web.

I agree, that is something that remains to be sorted out. To me 
"silence" and "black" would still be flowing (although some sort of BW 
savings technique such as DTX and CN might be applied on the wire); but 
there should be ways to suppress sending as well.

This is something we need to discuss in webrtc context.

>
>
> On Apr 18, 2013, at 2:38 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>
>> 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 Wednesday, 8 May 2013 06:27:48 UTC