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

2016-03-04 19:14 GMT+01:00 Bernard Aboba <Bernard.Aboba@microsoft.com>:

> [...]
>
>
>
> So to enable this in ORTC, we would have the following codec settings:
>
>
>
> “vp8” codec
>
>
>
> codecs[3].name = “vp8”;
>
> codecs[3].payloadType = 100;
>
>
>
> “vp9” codec
>
>
>
> codecs[4].name = “vp9”;
>
> codecs[4].payloadType = 101;
>
>
>
> “ulpfec” codec
>
>
>
> codecs[5].name = “ulpfec”
>
> codecs[5].payloadType = 117;
>
>
>
> “red” codec
>
>
>
> codecs[6].name = “red”;
>
> codecs[6].payloadType = 116;
>
>
>
> “rtx” codec
>

This is rtx for  VP8

>
>
> codecs[7].name = “rtx”
>
> codecs[7].payloadType = 96;
>
>
>

You are missing :

codecs[8].name = “rtx” //For VP9
codecs[8].payloadType = 97;

codecs[9].name = “rtx”; //For RED
codecs[9].payloadType = 98;


You don't need RTX for ulpfec, as it is always encapsulated inside a RED
packet


Then we would set up the encoding parameters for VP8:
>
>
>
> Parameters.encodings[0].ssrc = 1821827098;
>
> parameters.encodings[0].codecPayloadType = 100;
>
> parameters.encodings[0].fec.mechanism = “red+ulpfec”;
>
> parameters.encodings[0].fec.ssrc = X ; // What is the SSRC to be used for
> the red + ulpfec stream?
>

As you are using red, FEC and VP8 shares the same ssrc ( 1821827098)

parameters.encodings[0].rtx.payloadType = 96;  //retransmission of VP8 (PT
> 100)
>
> parameters.encodings[0].rtx.ssrc = 4154144015; //SSRC for the RTX stream
>
>
>
> And VP9:
>
>
>
> Parameters.encodings[1].ssrc = 1821827098; // same SSRC as for VP8
>
> parameters.encodings[1].codecPayloadType = 101;
>
> parameters.encodings[1].fec.mechanism = “red+ulpfec”;
>
> parameters.encodings[1].fec.ssrc = Y ; // What is the SSRC to be used for
> the red + ulpfec stream?  Is this the same as for VP8??
>

Same reason as avobe, it is 1821827098

parameters.encodings[1].rtx.payloadType = 97;  //retransmission of VP9 (PT
> 101)
>
> parameters.encodings[1].rtx.ssrc = 4154144015; //SSRC for the VP9 RTX
> stream (same as VP8 RTX stream?)
>

Yes, RTX ssrc is bounded to the media ssrc, not to the payload.


>
>
> We will also need to have encoding  parameters for red + ulpfec since that
> is also being retransmitted:
>
>
>
> Parameters.encodings[2].ssrc = X; // Does this need to be set twice??
>

If it is set for VP8 and VP8, not sure why not to set it here


> parameters.encodings[2].codecPayloadType = 116;
>
> parameters.encodings[2].rtx.payloadType = 98;  //retransmission of
> red+uplfec (PT 116)
>
> parameters.encodings[2].rtx.ssrc = 4154144015; //SSRC for the RTX of the
> red+ulpfec stream.  Is this the same as for RTX of the VP8/VP9 streams??
>

So you have:

codecs[4].name = “vp9”;
codecs[4].payloadType = 101;

codecs[5].name = “ulpfec”
codecs[5].payloadType = 117;

codecs[6].name = “red”;
codecs[6].payloadType = 116;

codecs[7].name = “rtx” //For VP8
codecs[7].payloadType = 96;

codecs[8].name = “rtx” //For VP9
codecs[8].payloadType = 97;

codecs[9].name = “rtx”; //For RED
codecs[9].payloadType = 98;

Parameters.encodings[0].ssrc = 1821827098;
parameters.encodings[0].codecPayloadType = 100;
parameters.encodings[0].fec.mechanism = “red+ulpfec”;
parameters.encodings[0].fec.ssrc = 1821827098; // Same as media ssrc as we
are using RED
parameters.encodings[0].rtx.payloadType = 96;  //retransmission of VP8 (PT
100)
parameters.encodings[0].rtx.ssrc = 4154144015; //SSRC for the RTX stream


Parameters.encodings[1].ssrc = 1821827098; // same SSRC as for VP8
parameters.encodings[1].codecPayloadType = 101;
parameters.encodings[1].fec.mechanism = “red+ulpfec”;
parameters.encodings[1].fec.ssrc = Y ; // Same as media ssrc as we are
using RED
parameters.encodings[1].rtx.payloadType = 97;  //retransmission of VP9 (PT
101)
parameters.encodings[1].rtx.ssrc = 4154144015; // rtx ssrc is bounded to
media ssrc


Parameters.encodings[2].ssrc = 1821827098; //
parameters.encodings[2].codecPayloadType = 116;
parameters.encodings[2].rtx.payloadType = 98;  //retransmission of
red+uplfec (PT 116)
parameters.encodings[2].rtx.ssrc = 4154144015; // rtx ssrc is bounded to
media ssrc

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.

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.

In fact, do you realice, that the code above can be reduced to: "I want 1
stream, with vp9,vp8, rtx and red+ulpfec"? or:

streams[0].rtx = yes
streams[0].fec = “red+ulpfec”;
streams[0].encodings[0].name = "vp8"
streams[0].encodings[1].name = "vp9"

At least, we should have an encoding parameters factory that takes as input
the information above, and creates the encoding parameters with correct
data and default settings.

Internally the ortc stack would find valid ssrcs, payload type numbers, and
fill all the data with the known restrictions

Then app could change the returned parameters it at will then at own risk,
and be blamed if sets some data that could violate the restrictions.

My 2 cents.

Best regards
Sergio