- From: Peter Thatcher <pthatcher@google.com>
- Date: Tue, 5 Aug 2014 09:51:57 -0700
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Cc: "public-ortc@w3.org" <public-ortc@w3.org>
Wouldn't the RtpReceiver know if it's audio or video as soon as the RtpParameters are passed into receive()? If you have audio codecs, you are audio. If you have video codecs, you are video. If you have neither, error out. If you have both, error out. And previous to calling receive(), I think .track should be null. I think it's OK for it to be nullable even if the WebRTC 1.0 is not. On Mon, Aug 4, 2014 at 9:17 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote: > 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 16:53:05 UTC