Re: API points for ICE/DTLS warmup

On 2015-07-31 10:01, Stefan Håkansson LK wrote:
> On 28/07/15 19:43, Peter Thatcher wrote:
>>      My preference would be
>>      Option J: PC.onaddtrack is fired with a real track (after all we will in
>>      many cases not get any info about this track after this point - all info
>>      must come in that initial SDP - so it can just as well be created),
>>      however this track stays muted until there is any media coming from the
>>      sending side (and this can happen only after the sending app does
>>      sender.replaceTrack).
>> ​So, have a real track come out of the receive side, even if there is a
>> null track​ on the send side.  I like that.  I think it makes sense.  In
>> fact, I don't think we need to have it muted when it comes out.  I think
>> we can just have it appear as a normal track.
> It would be a normal track, but I definitely think it should be muted
> until RTP data allowing decoding and rendering starts arriving (which in
> turn could only happen after the sending app has done replaceTrack).
> The muted -> unmuted transition would fire an event and would allow the
> app to optimize the UI.
> (If the app on the receiving side instead just creates a MediaStream and
> wires it up to a video element, the element's poster would be shown
> until video starts arriving if I understand things right.)

Having the track muted would not introduce anything new. We already have 
that for regular received tracks.

 From the spec:

"Initialize track's muted attribute to true. See the MediaStreamTrack 
section about how the muted attribute reflects if a MediaStreamTrack is 
receiving media data or not."

"When an RTCPeerConnection receives data on an RTP source for the first 
time, it MUST update the muted state of the corresponding 
MediaStreamTrack with the value false."


Received on Thursday, 6 August 2015 08:40:56 UTC