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

2016-03-17 22:34 GMT+01:00 Bernard Aboba <Bernard.Aboba@microsoft.com>:
> If you set same rtx payload in the encoding with different payload it will
> be incorrect
>
> [BA] This one we can fix by removing rtx.payload as an encoding parameter,
> and making it a codec parameter (“apt”) instead.

This is a better solution than the current one. Still I think ORTC is
mapping RTP parameters in a too much flexible and non-semantic way.
I've already said this before, but I cannot support that RTX or FEC
are considered "codecs".

"codecs" are audio or video codecs (or DTMF stuff). RTX/FEX are
encoding mechanisms. IMHO period.

And it happens that RTX/FEX are related to a specific *real* codec, so
IMHO they are properties of the codec itself, or said in another way,
each codec has (and MUST have) a corresponding and specific encoding
settings.

But instead of that, ORTC mimics SDP syntax and defines encodings in a
different object, so here the first problem for implementors as they
must check that every "encoding" points to a real codec, and also that
the same SSRC value is not set for a real codec and encoding.rtx.ssrc,
etc.

I know that having encoding.codecPayloadType as optional works for
"RTP routing rules" (as Robin has explained in this or other
thread/issues), but this is not about incoming RTP mapping, but about
RTP parameters description.

If we have a layered based design, we have the following:

1) Bottom layer are streams, and each stream has a unique SSRC value.
A stream should have a "type" property which may have these values:
- "media": let's say real audio/video + RED (no RTX here).
- "redundant": RTX, FEC...

2) In each type:"media" stream there are real codecs with defined PT values.

3) In each type:"redundant" stream there are PTs for RTX, FEC, etc,
having each one a codecPayloadType that MUST match a PT of a codec in
some type:"media" stream.

Probably there is some complex stuff when it comes to RED/FEC sent
over the type:"media" stream and so on...

IMHO something like this would be a more "semantic" syntax than the current one.




> if you set fec.mechanism to red+ulpfec 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.
>
>
> [BA] One of the consequences may be that sender.send() and
> receiver.receive() have to become async.  The alternative (have the onerror
> eventhandler called with a fatal error after sender.send() or
> receiver.receive() return) seems ugly at best.

I don't think the problem here is whether an error is thrown
synchronously or asynchronously.


Regards.



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

Received on Thursday, 17 March 2016 22:29:33 UTC