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 1. In WebRTC 1.0 RTCRtpReceiver.track is not nullable, so RTCRtpReceiver.track.kind is presumably available. 2. 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 Friday, 1 August 2014 18:21:23 UTC