- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 31 Jul 2015 07:59:27 +0000
- To: Peter Thatcher <pthatcher@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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.)
Received on Friday, 31 July 2015 07:59:56 UTC