W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2018

[webrtc-pc] RTCRtpReceiver.getStreams() and RTCRtpSender.getStreams()

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Fri, 29 Jun 2018 08:33:41 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-336911100-1530261220-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:44 UTC