Re: [rtcweb] SDP and ssrc-group,

Am not against allowing 'apt' with FEC, but forcing a PT to be consumed for each FEC stream could get out of hand, particularly for combined simulcast/SVC cases. 

> On Oct 28, 2014, at 10:51 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:
> 
> I think Justin meant the “initial SSRC” in the a=ssrc-group lines carries significance (as the source), not the order of a=ssrc lines.
> 
> What if new FEC schemes defined for bundle / unified plan (such as those below) followed the example of RTX by including apt=100 in their fmtp parameters? So PT can be used to associate source and FEC flows without declaring any SSRCs or groups.
> 
> We can also improve on RTX by allowing apt=100,101 for FEC.
> 
> When we consider more complex cases like RTX/FEC with simulcast and scalable streams in unified plan, using PT association may be better than declaring many SSRCs (which is also problematic in cases of collisions, dynamic sources, switching mixers, etc.).
> 
> Mo
> 
> 
> On 10/29/14, 1:22 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> Sounds like a reasonable idea to me, but don't you have to specify a strict pecking order? RTX before FEC doesn't sound right to me, but that's pure prejudice/bias (FEC is always present, and optional stuff his last)
> So how would you decide that order? A hat? PT value? Order of PT on the m line? Order of the fmtp attributes? Something else? Or can we simply fix the order, since there are only a small number of variations to consider?
> 
>> On Oct 28, 2014 9:24 PM, "Justin Uberti" <juberti@google.com> wrote:
>> So it's not clear to me that a=ssrc:X fmtp:Y is actually legal, without any fmtp parameters, or that it clearly indicates that only PT Y is to be sent on that SSRC. As such, I consider this solution to be wishful thinking.
>> 
>> I think it would be easier if we defined FEC/FID semantics such that the initial SSRC was to be used for the primary encoding, and any subsequent SSRCs were used for the secondary/tertiary streams. (e.g. RTX or FEC)
>> 
>> e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC:
>>   
>>      m=video 30000 RTP/AVP 100 101 108 109 110 111
>>      c=IN IP4 233.252.0.1
>>      a=rtpmap:100 VP8/90000
>>      a=rtpmap:101 VP9/90000
>>      a=rtpmap:108 rtx/90000
>>      a=rtpmap:109 rtx/90000
>>      a=fmtp:108 apt=100
>>      a=fmtp:109 apt=101
>>      a=rtpmap:110 interleaved-parityfec/90000
>>      a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000
>>      a=rtpmap:111 non-interleaved-parityfec/90000
>>      a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000
>>      a=ssrc:1234
>>      a=ssrc:2345
>>      a=ssrc:3456
>>      a=ssrc:4567
>>      a=ssrc-group:FID 1234 2345
>>      a=ssrc-group:FEC-FR 1234 3456 4567
>> 
>> SSRC 1234 is the primary encoding (VP8 or VP9)
>> SSRC 2345 is RTX (either PT 108 or 109, as needed)
>> SSRC 3456 is FEC (either PT 110 or 111, depending on impl)
>> SSRC 4567 is FEC (either PT 110 or 111, depending on impl)
>> 
>> 
>>> On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:
>>> >
>>> > Makaraju, Maridi Raju (Raju) wrote:
>>> > > OPUS does have a built-in FEC so no need for red+ulpfec.
>>> >
>>> > As discussed previously on this list [1] the built-in FEC only covers
>>> > the SILK layer. Existing codec-agnostic mechanisms were perfectly
>>> > adequate for protecting CELT-mode packets, so we didn't invent something
>>> > new.
>>> >
>>> > [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html
>>> [Raju] Thanks and appreciate the reference.
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb