Re: Issue 80: filterParameters

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;
>>
>> };
>>
>>
>