- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Tue, 5 Aug 2014 04:17:47 +0000
- To: "public-ortc@w3.org" <public-ortc@w3.org>
Should the "kind" argument be mandatory (not optional) in RTCRtpReceiver?
If done, the RTCRtpReceiver interface would look like this:
[Constructor(DOMString kind, RTCDtlsTransport transport, optional RTCDtlsTransport rtcpTransport)]
partial interface RTCRtpReceiver : RTCStatsProvider {
readonly attribute MediaStreamTrack track;
};
Not that "readonly attribute MediaStreamTrack track" is also used in the WebRTC 1.0 RTCRtpReceiver definition:
https://www.w3.org/2011/04/webrtc/wiki/images/6/63/WebRTC_RTCSender-Receiver.pdf
Related Issue #139:
In ORTC API, the "kind" of RTCRtpReceiver.track is unset before packets are received. While we have RTCRtpCodecCapability.kind, there is no equivalent attribute within RTCRtpParameters (or RTCRtpCodecParameters). As a result, when RTCRtpReceiver.receive(RTCRtpParameters) is called, the browser cannot deduce the "kind" of track it will be dealing with, which results in delays in setting up the audio or video pipeline.
Does it make sense to pass the "kind" in the RTCRtpReceiver constructor?
[Constructor(RTCDtlsTransport transport, optional RTCDtlsTransport rtcpTransport, optional DOMString kind)]
Looking at the proposal for integration of RTCRtpReceiver in WebRTC 1.0, it looks like this problem does not arise there:
https://www.w3.org/2011/04/webrtc/wiki/images/6/63/WebRTC_RTCSender-Receiver.pdf
In WebRTC 1.0 RTCRtpReceiver.track is not nullable, so RTCRtpReceiver.track.kind is presumably available.
RTCRtpReceiver is vended when a remote track is added. Since this happens when the sender adds a track (e.g. sender = pc.addTrack(mst);), the "kind" of the added track is set on both the sender and the receiver.
Received on Tuesday, 5 August 2014 04:18:17 UTC