Re: Missing Features: Stream Control

[Harald Alvestrand]

On 10/21/2013 12:03 PM, Sam Dutton wrote:
FWIW I think there's some confusion for web devs: whether to use 
MediaStream.stop() or MediaStreamTrack.enabled = false. (And, of 
course, MediaStream.stop() is 'permanent' -- there's no concept of a 
pause.)


True, and I think that's the difference that people need to focus on: 
stop() is permanent, .enabled can be switched back and forth.




>> know the difference between pause and a broken connection

Good point.



On 19 October 2013 00:42, Aymeric Vitte > wrote:


What I am saying here is that there should be an unique and
unified Streams API supported by all related APIs, each group
where it is relevant should feel concerned instead of thinking
another one might be.

Le 18/10/2013 20:04, Adam Roach a écrit :

On 10/18/13 12:47, Aymeric Vitte wrote:


Le 18/10/2013 19:13, Adam Roach a écrit :

To be clear, the .enabled flag and .stop() method are
already there, and they already pause/unpause the
stream and tear it down, respectively. I'm just
proposing concrete semantics for how they interact
with any PeerConnection that the track is associated with.


But they are not in the Streams proposal, see my other answer.


To make my point clearer: this isn't the right mailing list to
talk about making changes to the API on MediaStream and
MediaStreamTrack. If I had been proposing to change those
APIs, it would have been on the public-media-capture list, not
the public-webrtc list.

All I was trying to talk about is how the existing API
influences the behavior of RTCPeerConnection, which is why I
was talking about it on this list. If you want to propose
changes to MediaStream and MediaStreamTrack, please take them
to public-media-capture.

/a


-- 
Peersm : http://www.peersm.com

node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: Missing Features: Stream Control

[Sam Dutton]

FWIW I think there's some confusion for web devs: whether to use
MediaStream.stop() or MediaStreamTrack.enabled = false. (And, of course,
MediaStream.stop() is 'permanent' -- there's no concept of a pause.)

>> know the difference between pause and a broken connection

Good point.



On 19 October 2013 00:42, Aymeric Vitte  wrote:

> What I am saying here is that there should be an unique and unified
> Streams API supported by all related APIs, each group where it is relevant
> should feel concerned instead of thinking another one might be.
>
> Le 18/10/2013 20:04, Adam Roach a écrit :
>
>  On 10/18/13 12:47, Aymeric Vitte wrote:
>>
>>>
>>> Le 18/10/2013 19:13, Adam Roach a écrit :
>>>
 To be clear, the .enabled flag and .stop() method are already there,
 and they already pause/unpause the stream and tear it down, respectively.
 I'm just proposing concrete semantics for how they interact with any
 PeerConnection that the track is associated with.

>>>
>>> But they are not in the Streams proposal, see my other answer.
>>>
>>>
>> To make my point clearer: this isn't the right mailing list to talk about
>> making changes to the API on MediaStream and MediaStreamTrack. If I had
>> been proposing to change those APIs, it would have been on the
>> public-media-capture list, not the public-webrtc list.
>>
>> All I was trying to talk about is how the existing API influences the
>> behavior of RTCPeerConnection, which is why I was talking about it on this
>> list. If you want to propose changes to MediaStream and MediaStreamTrack,
>> please take them to public-media-capture.
>>
>> /a
>>
>
> --
> Peersm : http://www.peersm.com
> node-Tor : 
> https://www.github.com/Ayms/**node-Tor
> GitHub : https://www.github.com/Ayms
>
>
>

Re: Missing Features: Stream Control

[Aymeric Vitte]

What I am saying here is that there should be an unique and unified 
Streams API supported by all related APIs, each group where it is 
relevant should feel concerned instead of thinking another one might be.


Le 18/10/2013 20:04, Adam Roach a écrit :

On 10/18/13 12:47, Aymeric Vitte wrote:


Le 18/10/2013 19:13, Adam Roach a écrit :
To be clear, the .enabled flag and .stop() method are already there, 
and they already pause/unpause the stream and tear it down, 
respectively. I'm just proposing concrete semantics for how they 
interact with any PeerConnection that the track is associated with.


But they are not in the Streams proposal, see my other answer.



To make my point clearer: this isn't the right mailing list to talk 
about making changes to the API on MediaStream and MediaStreamTrack. 
If I had been proposing to change those APIs, it would have been on 
the public-media-capture list, not the public-webrtc list.


All I was trying to talk about is how the existing API influences the 
behavior of RTCPeerConnection, which is why I was talking about it on 
this list. If you want to propose changes to MediaStream and 
MediaStreamTrack, please take them to public-media-capture.


/a


--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: Missing Features: Stream Control

[Adam Roach]

On 10/18/13 12:47, Aymeric Vitte wrote:


Le 18/10/2013 19:13, Adam Roach a écrit :
To be clear, the .enabled flag and .stop() method are already there, 
and they already pause/unpause the stream and tear it down, 
respectively. I'm just proposing concrete semantics for how they 
interact with any PeerConnection that the track is associated with.


But they are not in the Streams proposal, see my other answer.



To make my point clearer: this isn't the right mailing list to talk 
about making changes to the API on MediaStream and MediaStreamTrack. If 
I had been proposing to change those APIs, it would have been on the 
public-media-capture list, not the public-webrtc list.


All I was trying to talk about is how the existing API influences the 
behavior of RTCPeerConnection, which is why I was talking about it on 
this list. If you want to propose changes to MediaStream and 
MediaStreamTrack, please take them to public-media-capture.


/a

Re: Missing Features: Stream Control

[Aymeric Vitte]

Le 18/10/2013 19:13, Adam Roach a écrit :
To be clear, the .enabled flag and .stop() method are already there, 
and they already pause/unpause the stream and tear it down, 
respectively. I'm just proposing concrete semantics for how they 
interact with any PeerConnection that the track is associated with.


But they are not in the Streams proposal, see my other answer.

--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: Missing Features: Stream Control

[Aymeric Vitte]

Le 18/10/2013 19:31, Stefan Håkansson LK a écrit :

I think we're talking about completely different streams, and what Adam
is proposing is applicable for MediaStreamTracks in the context of a
WebRTC PeerConnection.
I don't see why, a stream is a stream, this would be strange that a 
Streams API is defined and WebRTC is using something different, moreover 
that this does not change the spec, the spec just has to support Streams


--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: Missing Features: Stream Control

[Stefan Håkansson LK]

On 10/18/13 6:57 PM, Aymeric Vitte wrote:
> Should this not be synchronized with the Streams API? Please see recent
> evolutions [1] and thread [2] (where WebRTC streams are mentioned)

I think we're talking about completely different streams, and what Adam 
is proposing is applicable for MediaStreamTracks in the context of a 
WebRTC PeerConnection.

>
> Ccing Webapps and Takeshi/Feras.
>
> Regarding your proposal I was about to propose to add about the same
> thing in Streams: at least a stop method (which would send an EOF) and
> maybe a resume method, or something like your pause/unpause.
>
> For flow control I think I am changing my mind, it looks impossible to
> do a precise flow control with js, so probably the API itself should
> handle it.
>
> Regards,
>
> Aymeric
>
> [1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0152.html
> [2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html
>
> Le 18/10/2013 18:24, Adam Roach a écrit :
>> We've recently had some implementors reach out to ask about how to do
>> certain things with the WebRTC interfaces, and I've been pretty well
>> unable to turn up anything that makes a lot of sense for most of the
>> interesting stream-control interfaces.
>>
>> Some of this is talked about here, with an implication that the author
>> of this wiki page, at least, would be willing to leave some of them
>> unspecified for the first version of WebRTC:
>>
>> http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#Needs_further_discussion.2C_maybe_for_later_versions
>>
>> Unfortunately, I don't think we can leave stream pause/unpause or
>> stream rejection/removal out of the first version of the document. The
>> good news is that I think we have all the interfaces necessary to do
>> these things; we just need to spell out clear semantics for them.
>>
>> As a high-level thumbnail sketch, here's what I think makes sense:
>>
>>  1. To pause a track that you are sending, set enabled=false on a
>> MediaStreamTrack that you have added to a PeerConnection. This
>> information will cause the PeerConnection to stop sending the
>> associated RTP. Maybe this triggers an onnegotiationneeded to set
>> the corresponding m-line to recvonly or inactive and maybe it just
>> stops sending the stream; I'm not sure which makes more sense.
>>   * To unpause, set enabled back to true, and the steps are reversed
>>   * To pause all the MSTs associated with a MediaStream, use
>> enabled on the MediaStream itself.
>>
>>  2. To pause a track that you are receiving, set enabled=false on the
>> MediaStreamTrack that you received from the PeerConnection via
>> onaddstream. This will cause the MST to stop providing media to
>> whatever sink it has been wired to, and trigger an
>> onnegotiationneeded event. The subsequent CreateOffer sets the
>> corresponding m-line to sendonly or inactive, as appropriate.
>>   * As above, this operation can also be performed on a
>> MediaStream to impact all of its tracks.
>>
>>  3. To reject a track that has been offered, call stop() on the
>> corresponding MediaStreamTrack after it has been received via
>> onaddstream, but before calling CreateAnswer. This will cause it
>> to be rejected with a port number of zero.
>>
>>  4. To remove a track from an ongoing session, call stop() on the
>> corresponding MediaStreamTrack object. This will (a) immediately
>> stop transmitting associated RTP, and (b) trigger an
>> onnegotiationneeded event.
>>   * If both the sending and receiving MST associated with that
>> m-line have been stop()ed, then the subsequent CreateOffer
>> sets the port on the corresponding m-line to zero.
>>   * If only one of the two MSTs associated with that m-line has
>> been stop()ed, then the subsequent CreateOffer sets the
>> corresponding m-line to sendonly, receiveonly, or inactive, as
>> appropriate.
>>
>> Does this make sense to everyone? It seems pretty clean, easy to
>> specify, and reasonable to implement. Best of all, we're not changing
>> any currently defined interfaces, just providing clear semantics for
>> certain operations.
>>
>> /a
>>
>
> --
> Peersm :http://www.peersm.com
> node-Tor :https://www.github.com/Ayms/node-Tor
> GitHub :https://www.github.com/Ayms
>

Re: Missing Features: Stream Control

[Adam Roach]

On 10/18/13 11:56, Aymeric Vitte wrote:
Regarding your proposal I was about to propose to add about the same 
thing in Streams: at least a stop method (which would send an EOF) and 
maybe a resume method, or something like your pause/unpause.


To be clear, the .enabled flag and .stop() method are already there, and 
they already pause/unpause the stream and tear it down, respectively. 
I'm just proposing concrete semantics for how they interact with any 
PeerConnection that the track is associated with.


/a

Re: Missing Features: Stream Control

[Aymeric Vitte]

Should this not be synchronized with the Streams API? Please see recent 
evolutions [1] and thread [2] (where WebRTC streams are mentioned)


Ccing Webapps and Takeshi/Feras.

Regarding your proposal I was about to propose to add about the same 
thing in Streams: at least a stop method (which would send an EOF) and 
maybe a resume method, or something like your pause/unpause.


For flow control I think I am changing my mind, it looks impossible to 
do a precise flow control with js, so probably the API itself should 
handle it.


Regards,

Aymeric

[1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0152.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html

Le 18/10/2013 18:24, Adam Roach a écrit :
We've recently had some implementors reach out to ask about how to do 
certain things with the WebRTC interfaces, and I've been pretty well 
unable to turn up anything that makes a lot of sense for most of the 
interesting stream-control interfaces.


Some of this is talked about here, with an implication that the author 
of this wiki page, at least, would be willing to leave some of them 
unspecified for the first version of WebRTC:


http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#Needs_further_discussion.2C_maybe_for_later_versions

Unfortunately, I don't think we can leave stream pause/unpause or 
stream rejection/removal out of the first version of the document. The 
good news is that I think we have all the interfaces necessary to do 
these things; we just need to spell out clear semantics for them.


As a high-level thumbnail sketch, here's what I think makes sense:

 1. To pause a track that you are sending, set enabled=false on a
MediaStreamTrack that you have added to a PeerConnection. This
information will cause the PeerConnection to stop sending the
associated RTP. Maybe this triggers an onnegotiationneeded to set
the corresponding m-line to recvonly or inactive and maybe it just
stops sending the stream; I'm not sure which makes more sense.
  * To unpause, set enabled back to true, and the steps are reversed
  * To pause all the MSTs associated with a MediaStream, use
enabled on the MediaStream itself.

 2. To pause a track that you are receiving, set enabled=false on the
MediaStreamTrack that you received from the PeerConnection via
onaddstream. This will cause the MST to stop providing media to
whatever sink it has been wired to, and trigger an
onnegotiationneeded event. The subsequent CreateOffer sets the
corresponding m-line to sendonly or inactive, as appropriate.
  * As above, this operation can also be performed on a
MediaStream to impact all of its tracks.

 3. To reject a track that has been offered, call stop() on the
corresponding MediaStreamTrack after it has been received via
onaddstream, but before calling CreateAnswer. This will cause it
to be rejected with a port number of zero.

 4. To remove a track from an ongoing session, call stop() on the
corresponding MediaStreamTrack object. This will (a) immediately
stop transmitting associated RTP, and (b) trigger an
onnegotiationneeded event.
  * If both the sending and receiving MST associated with that
m-line have been stop()ed, then the subsequent CreateOffer
sets the port on the corresponding m-line to zero.
  * If only one of the two MSTs associated with that m-line has
been stop()ed, then the subsequent CreateOffer sets the
corresponding m-line to sendonly, receiveonly, or inactive, as
appropriate.

Does this make sense to everyone? It seems pretty clean, easy to 
specify, and reasonable to implement. Best of all, we're not changing 
any currently defined interfaces, just providing clear semantics for 
certain operations.


/a



--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms