Re: RED and FEC and RTX (and related questions!)

2016-03-04 21:35 GMT+01:00 Sergio Garcia Murillo
<sergio.garcia.murillo@gmail.com>:
> What worries me about this API is that there are a lot of points of failure:
>
> If you don't set rtx sssrc to same value in each encoding, it will be
> incorrect
> If you don't set same fec ssrc than media ssrc it will be incorrect
> If you set same rtx payload for to encoding with different payload it will
> be incorrect
> if red ssrc is not set same as media ssrc it will be incorrect
> if you set fec.mechanishm to red+fec in one encoding, but you don't add an
> encoding with fec, it will be incorrect
>
> I foresee it will be a nightmare to both, check for all the preconditions
> that need to be fulfilled in order to verify the encoding parameters, and to
> actually implement software in top that is aware of all the constrains above
> that are not obvious by just checking at the api.

I agree. As I've noted in https://github.com/openpeer/ortc/issues/405,
when it happens that each codec should have its specific encoding
parameters, it comes to my mind that each ' codec'  should have an
'encoding'  object within it. Something like this, which IMHO is much
less error prune:


“vp8” codec:

{
  name        : 'vp8'
  payloadType : 100
  ssrc        : 1821827098
  rtx:
  {
    payloadType : 96,
    ssrc        : 4154144015
  }
}

“vp9” codec:

{
  name        : 'vp9'
  payloadType : 101
  ssrc        : 1821827098
  rtx:
  {
    payloadType : 97,
    ssrc        : 4154144015
  }
}

“ulpfec” codec:

{
  name        : 'uplfec'
  payloadType : 117
  ssrc        : 1821827098
  rtx:
  {
    payloadType : 98,
    ssrc        : 4154144015
  }
}






> IMHO, the API should make easier to fill all the restrictions. Especially I
> don't understand why some values like ssrcs and payload types has to be set
> by the application and not generated internally by the ORTC api and be
> exposed read only to the app.
>
> Internally the ortc stack would find valid ssrcs, payload type numbers, and
> fill all the data with the known restrictions

The API does not mandate setting SSRC nor some other fields. The JS
app gets the local codecs by retrieving the "ORTC capabilities" in
which payload types are already defined.

The important point here is how the *complete* data looks (the full
RtpParameters of a RtpSender or RtpReceiver including SSRCs, payloads,
etc), so we can signal them to the remote peer and it cans signal them
to its local ORTC stack.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Friday, 4 March 2016 21:58:21 UTC