- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Thu, 27 Aug 2015 12:01:01 +0000
- To: Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2015-08-26 23:57, Peter Thatcher wrote:
> It looks like we'll soon be adding PeerConnection.createRtpSender, which
> is a way to create an RtpSender before one has a track to send.
>
> The logic corollary is PeerConnection.createRtpReceiver, which would be
> a way to create an RtpReceiver before any media negotiation has
> occurred. In other words, it would serve the same purpose as
> "offerToReceiveVideo".
>
> In both implementing offerToReceiveVideo and using it in JS, I found it
> awkward. I think the following example code would be more natural:
>
> var receiver = pc.createRtpReceiver("video");
> // The offer now acts like it currently does with "offerToReceiveVideo = 1".
> var offer = pc.createOffer();
> // JS can use the receiver.track immediately.
>
>
> I think this would be more natural, and more logically consistent with
> PeerConnection.createRtpSender.
>
>
> If you'd like to see how it would look in a PR, here it is:
>
> https://github.com/w3c/webrtc-pc/pull/279/files
I like this approach when you explicitly create a new receiver.
It eliminates the confusing with offerToReceiveAudio/Video whether the
numbers represents *extra* media descriptions that should be added on
top of those created by the addTrack() API or if the number represents a
total.
/Adam
Received on Thursday, 27 August 2015 12:01:28 UTC