- From: Peter Thatcher <pthatcher@google.com>
- Date: Wed, 22 Oct 2014 13:48:30 -0700
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Cc: "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <CAJrXDUHTVPQ10mVAeYAE9c5LU=rdGJbG-aXcnx3ink5yenmpbg@mail.gmail.com>
I'd prefer FEC/RED/RTX capabilities to be explicit rather than included in the codecs. And I think similarly for RTX parameters: be explicit rather than codec parameters. On Wed, Oct 22, 2014 at 1:38 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote: > Peter said: > > Good point. I suppose we could do this: > > > > dictionary RTCRtpParameters { > DOMString muxId = ""; > sequence<RTCRtpCodecParameters> codecs; > > * RTCRtpPayloadTypes red; RTCRtpPayloadTypes > fec;* > ... > }; > > > > dictionary RTCRtpPayloadTypes { > > payloadtype payloadType; > > payloadtype rtxPayloadType; > > } > > > > But maybe that's just as ugly as putting them in the codecs list. > > > > [BA] There is still the potential need to configure rtx-time, so some > dictionary additions are probably needed. > > > > Note that if we don’t include RTX/RED as codecs, we need to modify > RTCRtpCapabilities to allow them to be discovered some other way. > Strangely, FEC capabilities are advertised twice, once as a codec > (presumably a codec for each FEC mechanism), and again via fecMechanisms. > > > > > > dictionary *RTCRtpCapabilities* { > > sequence<*RTCRtpCodecCapability*> codecs > <http://internaut.com:8080/~baboba/ortc/ortc-10-10-2014.html#widl-RTCRtpCapabilities-codecs> > ; > > sequence<*RTCRtpHeaderExtension*> headerExtensions; > > sequence<DOMString> fecMechanisms; > > }; > > > > > > > > > > > > On Fri, Oct 17, 2014 at 12:58 PM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > > Hi Peter, > > While it is not very common to have RTX and FEC enabled simultaneously, in > theory I think it could be possible to have an RTX stream for the RED/FEC > payload. With your approach that would not be possible, as FEC would not be > a codec. It is a restriction I could live with, but we should make it clear > stated. > > Best regards > Sergio > > > On 17/10/2014 19:54, Peter Thatcher wrote: > > They aren't real codecs, so it's kind of ugly going in "codecs", and it > isn't completely obvious that doing so is necessary. It's also not obvious > to use "APT" in an RTX "codec", not to mention that it's also kind of ugly. > > > So, perhaps we could do something like this: > > dictionary RTCRtpParameters { > DOMString muxId = ""; > sequence<RTCRtpCodecParameters> codecs; > > * payloadtype redPayloadType; payloadtype > fecPayloadType;* > ... > }; > > dictionary RTCRtpCodecParameters { > > DOMString name; > payloadtype payloadType; > * payloadtype rtxPayloadType;* > ... > > }; > > > > > > Note that this does not tell the browser to send RTX, FEC, or RED. To do > so, one must put in the correct per-encoding control points under > RtpEncodingParameters. This merely specifies the payload types to send or > receive > > in a way that's a little cleaner and more obvious than putting them in > the list of RtpCodecParameters. > > > > > > Thoughts? > > > > > > >
Received on Wednesday, 22 October 2014 20:49:39 UTC