Re: Capabilities for RTX/FEC/RED

On 05/11/2014 23:43, Bernard Aboba wrote:
> In addition to support within Parameters, we also need to describe how FEC, RTX and RED are indicated in Capabilities.
>
> One way to indicate support for RTX might be to modify RTCRtpCodecCapability as follows:
>
> partial dictionary RTCRtpCodecCapability {
>      DOMString                 name;
>      DOMString                 kind;
>      payloadtype               preferredPayloadType;
>      payloadtype               preferredRtxPayloadType;
> };
>
> Since FEC mechanisms are exposed in RTCRtpCapabilities, we can discover what mechanisms are available (assuming we actually define an MTI FEC scheme so we have at least one).
>
> dictionary RTCRtpCapabilities {
>      sequence<RTCRtpCodecCapability> codecs;
>      sequence<RTCRtpHeaderExtension> headerExtensions;
>      sequence<DOMString>             fecMechanisms;
> };
>
> However, I am wondering how we discover some other details about FEC (whether it can be supported stand-alone or with RED, the preferredPayload types, etc.).
> In other words, should we have sequence<RTCFecCapability> instead of sequence <DOMString>?
>
> There is also an underlying assumption here, which we should perhaps state explicitly, which is that RED is used to package FEC along with the encoding, not for redundant encodings of more than one codec.  It is this assumption which allows us to discover RED capabilities and set RED parameters as part of FEC capability/parameters, rather than on its own (as would be the case if it were treated as a codec).

I think we should not cover FEC at all  until there is an agreement on 
what is going to be required in RTCWEB. Defining an API for RED/FEC is 
completely different than doing so for ssrc-multiplexing, and if we try 
to create a magic-fit-all solution we may end up with a suboptimal 
solution or even worst, a non working solution when the final decision 
is made.

Best regards
Sergio

Received on Wednesday, 5 November 2014 23:06:34 UTC