- 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