- From: Peter Thatcher <pthatcher@google.com>
- Date: Mon, 9 Jun 2014 18:21:00 -0700
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Cc: "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <CAJrXDUGMEEUMGpoTdS2319dx1_N0+3XbCeHeUK-rUFcMabBgWg@mail.gmail.com>
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; >> >> }; >> >> >
Received on Tuesday, 10 June 2014 01:22:08 UTC