- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Fri, 20 Jul 2012 15:45:39 +0200
- 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