- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 29 Jun 2018 08:17:39 +0000
- To: public-webrtc-logs@w3.org
Currently, the receiver's streams is an internal slot, but it is exposed in the ontrack event. I agree this information should be exposed, else we force people to listen to ontrack & friends to maintain their own version of this "slot". But even with r.getStreams(), you might not have any streams though (streamless track) so you can't rely on streams' states. Because transceivers are reusable `r.track.ended` will be false even for inactive ones (ended is a state you can't get out of). What we do have is `r.track.muted`, but I don't think this works either, unless I'm mistaken they are supposed to be muted by default and become unmuted when frames arrive? Is that true? Maybe `r.track.readyState == 'live'`, or is this the same as unmuted? I would argue that if you give me a PC I should be able to inspect its state without having had to listen to a history of events to piece together what its state are from ontrack & friends. This would be useful for any utils. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1890#issuecomment-401283738 using your GitHub account
Received on Friday, 29 June 2018 08:17:41 UTC