Re: [rtcweb] SDP and ssrc-group,

Indeed, that was my original concern also.

Using the order of ssrc-ids on the ssrc-group may be the simplest way to 
solve it, but not sure if it would allow more complex FEC scenarios, 
like one FEC stream protecting two media flows (maybe not relevant at all).

I have been surfing at the ietf rfcs, and found and interesting one 
rfc6364 which defines  fec-source-flow and fec-repair-flow media 
attributes that can be used with a=group:FEC-FR, hat would allow exactly 
what we need:

         v=0
         o=ali 1122334455 1122334466 IN IP4 fec.example.com
         s=FEC Framework Examples
         t=0 0
         a=group:FEC-FR S1 R1
         m=video 30000 RTP/AVP 100
         c=IN IP4 233.252.0.1/127
         a=rtpmap:100 MP2T/90000
         a=fec-source-flow: id=0
         a=mid:S1
         m=application 30000 UDP/FEC
         c=IN IP4 233.252.0.2/127
         a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
         a=repair-window:150ms
         a=mid:R1

We would need to port thatould neerc-group semantics, like for example

      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 fec-source-flow: id=0
      a=ssrc:2345
      a=ssrc:3456 fec-repair-flow: encoding-id=0;
      a=ssrc:4567 fec-repair-flow: encoding-id=0;
      a=ssrc-group:FID 1234 2345
      a=ssrc-group:FEC-FR 1234 3456 4567

Best regards
Sergio
On 29/10/2014 5:23, Justin Uberti 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 
> <mailto: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 <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb