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:

5.1.3:
"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."

10.3:
"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."

/Adam

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