- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Thu, 6 Aug 2015 08:40:01 +0000
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Peter Thatcher <pthatcher@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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