Re: [rtcweb] SDP and ssrc-group,

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
>
>