Re: Issue 80: filterParameters

Which is to say, I'd be happy with clockRate


On Mon, Jun 9, 2014 at 6:21 PM, Peter Thatcher <pthatcher@google.com> wrote:

> We call it clockrate in our implementation.
>
>
> On Mon, Jun 9, 2014 at 6:04 PM, Bernard Aboba <Bernard.Aboba@microsoft.com
> > wrote:
>
>>  hzRate is kind of silly.  Do you have a better suggestion? Maybe
>> clockRate?
>>
>> On Jun 9, 2014, at 5:56 PM, "Peter Thatcher" <pthatcher@google.com>
>> wrote:
>>
>>   I like preferredPayloadType being there like you put it.  And I think
>> preferredId on RtpHeaderExtension would be fine, too, the more I think
>> about it.
>>
>>  By the way, what's up with "hzRate"?  Isn't that kind of redundant?  It
>> sounds to me like calling it "rateRate" or maybe "poundsWeight".  Is there
>> a deeper meaning that I'm missing?
>>
>>
>> On Mon, May 19, 2014 at 2:15 PM, Bernard Aboba <
>> Bernard.Aboba@microsoft.com> wrote:
>>
>>>  Peter said:
>>>
>>>
>>>
>>> “​Now that we've removed ​filterParameters/createParameters, I think we need
>>>
>>>  to find another way to make the simple use case and simple example
>>> work.  I
>>>
>>> really don't want our "simple example" to be dependent on a JS library,
>>> or
>>>
>>> have to choosing ssrcs.   I'd like the simple examples to remain simple.
>>>
>>>
>>>
>>> So what can we do?  Here is an idea:
>>>
>>>
>>>
>>> 1.  Allow passing in RtpCapabilities into RtpSender.send and
>>>
>>> RtpReceiver.receive.  That way, the signalling could just exchange
>>>
>>> capabilities and not have to create RtpParameters for the simple case.
>>>
>>>
>>>
>>> 2.  Send and receive with the preferredPayloadType.  The sender just
>>> picks
>>>
>>> some SSRC, and the receiver automatically locks onto them, as if the JS
>>> had
>>>
>>> listened to "onunsignalledrtp" and added SSRCs manually.
>>>
>>>
>>>
>>>
>>>
>>> That doesn't support header extensions (since the receiver wouldn't know
>>>
>>> the IDs) or layering or FEC, but that might be OK for the simple use
>>> case.
>>>
>>>
>>>
>>>
>>>
>>> Are there dragons that I'm not thinking of that would make this not work?
>>>
>>> ”
>>>
>>>
>>>
>>> [BA] Agree that with preferredPayloadType, RTCRtpCodec should have
>>> enough info to setup a single stream audio or video call by exchanging
>>> capabilities.
>>>
>>>
>>>
>>> Also agree that currently headerExtensions wouldn’t work because there
>>> are no IDs (would preferredID fix this? Do we care?).
>>>
>>>
>>>
>>> Am wondering how much we can do with features and rtcpFeedback as
>>> currently defined.
>>>
>>>
>>>
>>> For example, we should be able to figure out what feedback messages
>>> (e.g, PLI, FIR) are available for repair with the single-stream video.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> partial interface RTCRtpSender {
>>>
>>>     void send (optional RTCRtpParameters parameters, optional
>>> RTCRtpCapabilities remoteCapabilities);
>>>
>>> }
>>>
>>>
>>>
>>> partial interface RTCRtpReceiver {
>>>
>>>     void receive (optional RTCRtpParameters parameters, optional
>>> RTCRtpCapabilities remoteCapabilities);
>>>
>>> }
>>>
>>>
>>>
>>> dictionary RTCRtpCapabilities {
>>>
>>>     sequence<RTCRtpCodec> audioCodecs;
>>>
>>>     sequence<RTCRtpCodec> videoCodecs;
>>>
>>>     sequence<DOMString>   headerExtensions;
>>>
>>>     Capabilities          features;
>>>
>>>     Capabilities          rtcpFeedback;
>>>
>>> };
>>>
>>>
>>>
>>>
>>>
>>> dictionary RTCRtpCodec {
>>>
>>>     DOMString       name = "";
>>>
>>>     unsigned short? hzRate = null;
>>>
>>>     unsigned short  preferredPayloadType;
>>>
>>>     unsigned short? numChannels = 1;
>>>
>>>     Capabilities    formats;
>>>
>>> };
>>>
>>>
>>
>