- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 29 Jun 2018 08:33:41 +0000
- To: public-webrtc-logs@w3.org
henbos has just created a new issue for https://github.com/w3c/webrtc-pc: == RTCRtpReceiver.getStreams() and RTCRtpSender.getStreams() == The sender's set of streams is negotiated and shows up at the other end as the receiver's [[AssociatedRemoteMediaStreams]] slot. This is exposed in the ontrack event, but without listening to that event, there is no way for the application to know which streams belong to a receiver. As of recently we even have RTCRtpSender.setStreams(), but there is no RTCRtpSender.getStreams(). Why support controlling something but not checking its current value, forcing the application to do additional bookkeeping. As a side note, not having RTCRtpSender/RTCRtpReceiver.getStreams() makes shimming getLocalStreams()/getRemoteStreams() difficult. We may not care about supporting legacy APIs but we should care about supporting legitimate use cases highlighted by them. It's not unreasonable for an application to want to know about their streams. Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1921 using your GitHub account
Received on Friday, 29 June 2018 08:33:43 UTC