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 
garbage-collected.

                   Harald
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