W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2012

Removing RemoveStream (Re: Stats proposal, updated)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 20 Jul 2012 15:45:39 +0200
Message-ID: <50096103.5020604@alvestrand.no>
To: public-webrtc@w3.org
Changing the subject, since this is a topic that goes beyond stats - 
perhaps we can get someone else to chime in....?

On 07/20/2012 03:00 PM, Stefan Hakansson LK wrote:
> On 07/20/2012 12:49 PM, Harald Alvestrand wrote:
>> On 07/02/2012 05:56 PM, Stefan Hakansson LK wrote:
>> Anyway, I certainly has nothing against exposing stats to the sender
>> app as well, but I think we should do something about the API in that
>> case. I don't like the idea that "removeStream" would create empty
>> entries in the local/remoteStream arrays.
>> Then let's remove "removeStream" altogether, and have the streams
>> remain, but in the Closed state.
> That is one way to do it. Would it enable freeing up resource? I'm 
> thinking about a situation where audio and video is streamed to a 
> remote peer, and the data connection is used as well. If the 
> sender/sending app determines that audio or video will not be used for 
> a while, resources like codecs should be released (but the data 
> connection should remain) to other (web and native) apps.

If the definitions say that a closed MediaStream cannot be reopened, a 
sensible implementation would definitely free up the resources 
associated with that stream on close.
It probably should anyway, instead of waiting for the MediaStream to be 

Received on Friday, 20 July 2012 13:46:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC