Re: [webrtc-pc] editorial: media api introduction

Figured it out and all of a sudden transceivers makes sense. Thanks @taylor-b and also @jan-ivar for listening to hours of rambling on IRC.

With transceivers the lore for when to show a video changes. This moves from the pc iceconnectionstate (which is only valid for initial connection anyway) to the track.onunmute. Which makes sense once one understands the model. But the spec does not explain it at all.

http://w3c.github.io/webrtc-pc/#rtcrtpreceiver-interface step 7 says the initial state of a receivers track is muted. This makes sense because initially the track has not received data. 
It also says "See the MediaStreamTrack section about how the muted attribute reflects if a MediaStreamTrack is receiving media data or not." This links to [terminology](http://w3c.github.io/webrtc-pc/#dom-mediastreamtrack) which refers to mediacapture-main. But mediacapture-main doesn't really explain things in a way which is applicable to remote tracks over a network connection which makes this not very useful.

So it seems we need
1) a quick summary of what i said above for the intro section of the spec
2) an example showing the onunmute
3) more spec-text in step 7 says why the muted state is true initially and when that changes. Possibly this belongs into the description of the track attribute.

https://jsfiddle.net/jkzn0y5x/1/ shows this in Firefox 59 with transceivers (and it adds a muted attribute).
Unfortunately, running the same fiddle in Chrome shows that its initial muted state is false which means onunmute will never fire. Which currently makes it impossible to show people "this is how you are supposed to write that code" because they will say "but it does not work in chrome".

-- 
GitHub Notification of comment by fippo
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1240#issuecomment-356720298 using your GitHub account

Received on Wednesday, 10 January 2018 20:04:25 UTC