Re: Issue 444: RTX APT capability?

See inline [RR]:


On April 8, 2016 at 4:09:00 AM, Sergio Garcia Murillo (sergio.garcia.murillo@gmail.com) wrote:

On 08/04/2016 1:27, Robin Raymond wrote:

2.  In WebRTC 1.0, do you expect there to be multiple “rtx” entries within parameters.codecs[], one for each codec that is being retransmitted?  For example, codecs[i].sdpFmtpLine = “a=fmtp:99 apt=98;rtx-time=3000” for one rtx line and codecs[j].sdpFmtpLine = “a=fmtp:100 apt=101;rtx-time=3000” for another one.   
a.       Would you support an WebRTC 1.0 PR that would remove rtx entries in codecs[] and add unsigned short rtxPayloadType to the RTCRtpCodecParameters dictionary?  

[RR] I would hands down fully support this change as a setting within the existing codec parameter. I think it removes the ambiguity and needless cross referencing across codecs. It’s just much easier this way.


[SM] +1 but take into account that rtx has also the rtxtime parameter so we would need a rtxPayloadType  and a rtxTime parameters, I think it is better to move it to it's own dictionary:
 
[RR] Correct, it needs to in a sub dictionary. Also needs to be a capability for the same reason.



//New dictionary
dictionary RTCRtpCodecRTXParameters {
             payloadtype               payloadType;
             unsigned long             rtxtime;
};

dictionary RTCRtpCodecParameters {
             DOMString                 name;
             payloadtype               payloadType;   
             ...
             RTCRtpCodecRTXParameters  rtx;                       // NEW: rtx.payloadType
};

[SM] Take also into account that if we remove the RTX from the codecs, we would need to add an rtxSSRC whenever there is an ssrc attribute. Currently it is set only in the encodings, that would mean that include a new case of invalida parameters: all encodings with same ssrc MUST HAVE the same rtxSSRC.


[RR] Not sure I understand what you mean but to be clear SSRCs need not (and should not) be defined with the codec. The PT describes the interpretation of the packet’s codecs. Multiple encodings can use different SSRCs and yet share the same PT definition.





Personally, I believe we either need to do this uniformly in both ORTC and WebRTC 1.0, or not do it.

3.       Do you advocate keeping FEC and RED as codecs with RTCRtpCapabilities and RTCRtpCodecParameters? 

 



[RR] I see those exactly like RTX codec. They are settings within the same codec. The only difference RTX requires a unique PT per codec, whereas the same PT value for FEC, RED could be shared across codecs (respectively).



That is the main difference between RTX and FEC,RED.
TX relates 1-to-1 to a Codec payload while FEC/RED has a 1-to-1 relationship with a RTP stream. As we don't have any object that represents an RTP Stream (same ssrc can be set on different encodings), there is not a single place where we can set the FEC/RED parameters and would need to be set in all encodings with same ssrc (same as the rtxSSRC above).


[RR] Again, the PT can define how to interpret the packet that arrives independent of SSRCs that might use it. Yes, I understand the RTX is a 1-to-1 and FEC is a n-to-1 relationship. The point is that the definition of the codec can have a shared PT relationship where each codec that uses the FEC can reuse the same PT within its definition of the codec thus avoiding the cross referencing a codec issue just like it is done for RTX.



For example:

vp8codec.payloadType = 101;

vp8codec.rtx.payloadType = 102;

vp8codec.fec.payloadType = 100;



h264codec.payloadType = 105;

h264codec.rtx.payloadType = 106;

h264codec.fec.payloadType = 100;



Thus VP8 and H264 have their own RTX PT (as required because RTX is “dumb") but a shared FEC has a shared PT for both VP8 and H264 thus eliminating the “feature” codec aspect of it. Yes, rtx / fec would need to include other properties like rtxTime and mechanism and that’s why they need to be sub-dictionaries.

This removes a lot of the ambiguities that happen when trying to cross reference across normal codecs to feature codecs.





Best regards
Sergio