W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2015

Re: PRs for either PC.createRtpSender or PC.addTrack(..., RtpSenderInit, ...)

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 26 Aug 2015 11:05:04 -0700
Message-ID: <CAJrXDUG7fjW5YarOHhsK4LRE4ZnmqqH7jf1EOJQAVCOok-=how@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Justin Uberti <juberti@google.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
That's a good point about needing more detail in #271.  I have updated it
with more detail about .track being null and what details should be filled
in when the track isn't there.

Please take a look and let me know what more improvements can be made.
Specific text is welcome.

On Tue, Aug 25, 2015 at 6:36 PM, Martin Thomson <martin.thomson@gmail.com>

> On 25 August 2015 at 17:52, Justin Uberti <juberti@google.com> wrote:
> > Having reviewed both PRs, I agree with Adam and Peter. createRtpSender is
> > simple and intuitive.
> That sounds reasonable to me.  I don't think that #271 has enough
> detail (it need to specify that the .track property of the sender is
> null.  It also need to describe the consequences for session
> negotiation: namely that a "default" profile for the specified kind
> will be used.
> Also, I assume that we aren't required to make any sorts of promises
> about hardware codecs; in other words, that browsers will not include
> hardware codecs in any generated session description unless hardware
> codecs are the only possible option.  Hmm, the more I think about
> this, the more that I think that we need to be careful to work out
> what the right approach is - we could leave this up to implementer
> discretion, but that would be sloppy.
Received on Wednesday, 26 August 2015 18:06:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:08 UTC