- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Sun, 12 Jan 2014 09:45:55 +0000
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 12/01/14 02:07, Silvia Pfeiffer wrote: > On Sun, Jan 12, 2014 at 12:12 AM, Stefan Håkansson LK > <stefan.lk.hakansson@ericsson.com> wrote: >> On 2014-01-10 18:38, Martin Thomson wrote: >>> On 10 January 2014 01:13, Stefan Håkansson LK >>> <stefan.lk.hakansson@ericsson.com> wrote: >>>> I may be wrong... >>> :) >>> >>> I was planning to propose a change to the API that would necessitate >>> an error on addStream. More on that later, it requires a better >>> explanation than I want to hide on this thread. >> >> Looking forward to it (and I sort of hope it will be addTrack rather >> than addStream)! > > Just be aware: there's already an onaddtrack event in HTML5: > http://www.w3.org/TR/html5/embedded-content-0.html#handler-texttracklist-onaddtrack Yes, and as I understand it the MediaStreams and MediaStreamTracks have been designed with that in mind. > . > > Cheers, > Silvia. > >> But, without going into details, the current discussion seems to evolve >> around when the check of whether or not there are resources available to >> actually transmit the tracks of the added stream or not is carried out >> at addStream time, or later (createOffer); and how the application gets >> to know about that a track can not be sent (is it at addStream, by an >> event fired on the DooHickey, or by polling the stats API). >> >> I am fine with any way - but it is clear we need to agree. >> >> And I would argue that having that error at addStream is not that >> helpful, because things can change later. Say you addStream, and then >> add one more track to the MediaStream (this was really another argument >> why we should addTrack rather than addStream to PeerConnection). Or say >> you change resolution and framerate on a track being sent by working >> with the Constraints of that track, and now the PeerConnection can't >> handle it any more. And some people have been pointing out the CPU clock >> may be lowered in frequency due to overheating at any time. >> >> Stefan >> >
Received on Sunday, 12 January 2014 09:46:21 UTC