Subject: [MMUSIC] FEC support in unified plan.

From: "Roni Even" <[email-masked]>
Date: Mon, 2 Sep 2013 15:14:03 +0300

Hi,

The unified plan propose that each SDP m-line will describe a media source
(http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01#se
ction-2.3) or a media stream track.

When looking at FEC, it looks like this may not be simple.

The first case is when sending an offer for  a base layer and enhancement
layer of an SVC stream with two FEC streams, one protects the base layer and
the other protects the base and enhancement layers.

This can be described using the following SDP with one m-line (show partial
SDP) for video. Note that SVC does not define the ssrc-grouping support.
Here all stream are from the same source.

a=group:BUNDLE m1 m2 

m=audio 56600 RTP/SAVPF 109

a=msid:ma ta

a=mid:m1

a=ssrc:53280

a=rtpmap:109 opus/48000

m=video 56602 RTP/AVPF 100 101 110 111 - Main camera

a=msid:ma tb

a=mid:m2

a=rtpmap:100 H264/90000   - Base layer

a=rtpmap:101 H264-SVC/90000 - Enhancement layer.

a=depend:101 lay L1:100 - dependencies

a=rtpmap:110 1d-interleaved-parityfec/90000

a=fmtp:110 L=5; D=10; repair-window=200000

a=rtpmap:111 1d-interleaved-parityfec/90000

a=fmtp:111 L=10; D=10; repair-window=400000

a=ssrc:1000 cname:[email-masked]

a=ssrc:1010 cname:[email-masked]

a=ssrc:2110 cname:[email-masked]

a=ssrc:2120 cname:[email-masked]

a=ssrc-group:FEC-FR 1000 2110

a=ssrc-group:FEC-FR 1000 1010 2120

a=ssrc-group:DDP 1000 1010

The other case is when there is a TelePresence system with three cameras
each is a media source. Each camera source is described using an SDP m-line.
Each stream can have FEC protection but it is allowed to have one FEC stream
that protects all three streams.

In this case the FEC stream cannot be part of one of the sources but may
need its onw SDP m-line but it will not have an msid since it is not a media
stream track. So the offer may look

a=group:BUNDLE m1 m2 m3 m4 R1

a=group:FEC-FR m2 m3 m4 R1

m=audio 56600 RTP/SAVPF 109

a=mid:m1

a=msid:ma ta

a=ssrc:53280

a=rtpmap:109 opus/48000

m=video 56602 RTP/AVPF 100 - left camera

a=mid:m2

a=msid:ma tb

a=rtpmap:100 H264/90000 

a=ssrc:1000 cname:[email-masked]

m=video 56602 RTP/AVPF 101- Middle camera

a=mid:m3

a=msid:ma tc

a=rtpmap:101 H264/90000 

a=ssrc:1010 cname:[email-masked]

m=video 56602 RTP/AVPF 102 - Right camera

a=mid:m4

a=msid:ma td

a=rtpmap:102 H264/90000 

a=ssrc:1020 cname:[email-masked]

m=video 56602 RTP/AVP 110        

a=rtpmap:110 1d-interleaved-parityfec/90000

a=fmtp:110 L=5; D=10; repair-window=200000

a=mid:R1

a=ssrc:2020 cname:[email-masked]

does this solution works for the unified proposal.

We may have similar issues with simulcast if we describe the different
simulcast options using more than one SDP m-line since they are from the
same media source.

Roni

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 02 Sep 2013 17:36:24 +0200

On 09/02/2013 02:14 PM, Roni Even wrote:
> (http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-01#section-2.3) 
> or a media stream track.
>
> The first case is when sending an offer for  a base layer and 
> enhancement layer of an SVC stream with two FEC streams, one protects 
> the base layer and the other protects the base and enhancement layers.
>
> This can be described using the following SDP with one m-line (show 
> partial SDP) for video. Note that SVC does not define the 
> ssrc-grouping support. Here all stream are from the same source.
>
> a=group:BUNDLE m1 m2
>
> m=video 56602 RTP/AVPF 100 101 110 111 -- Main camera
>
> a=msid:ma tb
>
> a=mid:m2
>
> a=rtpmap:101 H264-SVC/90000 -- Enhancement layer.
>
> The other case is when there is a TelePresence system with three 
> cameras each is a media source. Each camera source is described using 
> an SDP m-line. Each stream can have FEC protection but it is allowed 
> to have one FEC stream that protects all three streams.
>
> In this case the FEC stream cannot be part of one of the sources but 
> may need its onw SDP m-line but it will not have an msid since it is 
> not a media stream track.
>

This is actually important for the msid draft's procedures for handling 
"unknown source packets".

If the a=ssrc:2020 is only present in the answer, and the first RTP 
packet with SSRC=2020 arrives before the answer does, what should the UA do?

In the current rules, it says "this is an error" and discards the packet 
(assuming that the msid-semantic:WMS line is present), or buffers it if 
it feels like it (no guarantees).

is it OK for the semantics of a multiple-stream repair stream to discard 
the first few packets?

> So the offer may look
> m=video 56602 RTP/AVPF 100 -- left camera
>
> a=mid:m2
>
> a=msid:ma tb
>
> a=rtpmap:100 H264/90000
>
> m=video 56602 RTP/AVPF 101-- Middle camera
>
> a=mid:m3
>
> a=msid:ma tc
>
> a=rtpmap:101 H264/90000
>
> m=video 56602 RTP/AVPF 102 -- Right camera
>
> a=mid:m4
>
> a=msid:ma td
>
> a=rtpmap:102 H264/90000
>
> simulcast options using more than one SDP m-line since they are from 
> the same media source.
>
> Roni
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Roni Even" <[email-masked]>
Date: Mon, 2 Sep 2013 20:42:06 +0300

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harald Alvestrand
Sent: 02 September, 2013 6:36 PM
To: [email-masked]
Subject: Re: [MMUSIC] FEC support in unified plan.

Hi,

a=group:BUNDLE m1 m2 

a=msid:ma ta

a=mid:m1

a=ssrc:53280

a=rtpmap:109 opus/48000

a=msid:ma tb

a=mid:m2

stream track.

If the a=ssrc:2020 is only present in the answer, and the first RTP packet
with SSRC=2020 arrives before the answer does, what should the UA do?

In the current rules, it says "this is an error" and discards the packet
(assuming that the msid-semantic:WMS line is present), or buffers it if it
feels like it (no guarantees).

is it OK for the semantics of a multiple-stream repair stream to discard the
first few packets?

[Roni Even] so this is the case for appID where the offer provides the appID
for the receives stream to allow the mapping. 

So the offer may look

a=mid:m1

a=msid:ma ta

a=ssrc:53280

a=rtpmap:109 opus/48000

a=mid:m2

a=msid:ma tb

a=rtpmap:100 H264/90000 

a=mid:m3

a=msid:ma tc

a=rtpmap:101 H264/90000 

a=mid:m4

a=msid:ma td

a=rtpmap:102 H264/90000 

a=mid:R1

 

Roni