Subject: [payload] Question regarding SVC (RFC 6190)

From: Magnus Westerlund <[email-masked]>
Date: Thu, 6 Oct 2011 15:53:45 +0200

Hi,

In my thinking of multi-stream handling I have considered SVC a bit. But
I don't find anything in the RFC that specifies how a receiver actually
determine in an MST usage the SSRCs in the various sessions that are
actually caries NALUs associated with a particular source.

The setup is a single end-point, with two video cameras and a microphone
that captures a lecture hall, it sends these two video streams using
multicast and MST NI-T packetization mode in lets say three different
RTP sessions each on different multicast groups.

This setup results in that each of the three RTP sessions will have two
SSRCs in each session carrying either of the sessions. Both video
cameras and thus all the SSRCs will be associated with the same CNAME as
they are part of the same synchronization context and need to be synced
with the audio stream coming from that room.

Can someone please explain how a receiver can determine which SSRC that
are to be bound together and carries NALUS part of the same source stream?

Based on that the spec says that SSRC shall be assigned as RFC 3550
says, they don't carry the same value.

Is this a big bug in the spec, needing a solution like SRCNAME we
suggested in:
https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and-simulcast/

Or am I missing to find the explanation in the RFC. I will confess that
I haven't read it from first to last word.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 6 Oct 2011 06:56:54 -0700

Grouping (a:group or ssrc-group) handles that, no?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Thursday, October 06, 2011 9:54 AM
> To: [email-masked]
> Subject: [payload] Question regarding SVC (RFC 6190)
> 
> Hi,
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 6 Oct 2011 16:41:51 +0200

> Grouping (a:group or ssrc-group) handles that, no?

Well, group is part of the examples using the DDP (Decoding Dependency)
semantics to group the RTP sessions together. However, that doesn't
resolve the SSRC grouping issue.

And a=ssrc-group can only group SSRC within a single RTP session. It
can't group the SSRCs from several sessions as being related.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 6 Oct 2011 07:51:27 -0700

I agree that those semantics can satisfy your needs in certain scenarios but not all. But the question is whether you need to cover every possible scenario with such semantics or produce new semantics for that purpose.

-acbegen

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, October 06, 2011 10:42 AM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]
> Subject: Re: [payload] Question regarding SVC (RFC 6190)
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 7 Oct 2011 09:16:24 +0200

On 2011-10-06 16:51, Ali C. Begen (abegen) wrote:
> I agree that those semantics can satisfy your needs in certain
> scenarios but not all. But the question is whether you need to cover
> every possible scenario with such semantics or produce new semantics
> for that purpose.

>From an SVC perspective it is clear that this issue only arises in MST
sessions. And in reality it only becomes a real problem when a given
CNAME sends more than a single SVC encoded source.

>From my perspective, the reasonable thing to do is to put it on the
issue list for thing that needs a solution when developing scalable or
other payload formats that has relation between SSRC and their packet
flows, especially in other RTP sessions.

I think the general topic should be discussed in AVTCORE but clearly
PAYLOAD interest must be involved. An Ericsson co-author and I will
submit before the deadline a draft discussing RTP's multi-stream
architecture in a general case. This is a follow up on the
https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and-simulcast/
that I presented in Quebec in AVTCORE.

When we agree on a general direction for handling these type of issues,
PAYLOAD WG can consider to update the SVC payload format to resolve the
identified issue following those agreements.

Cheers

Magnus Westerlund
(As individual)

---

From: Jonathan Lennox <[email-masked]>
Date: Sun, 9 Oct 2011 22:15:36 -0400

Hi, Magnus --

> actually caries NALUs associated with a particular source.

[...]

> says, they don't carry the same value.

RFC 6190 doesn't explicitly say it, and I agree that's a flaw, but I was certainly under the impression that for mutli-session MST, the relevant part of 3550 was section 8.3:

8.3 Use with Layered Encodings

   For layered encodings transmitted on separate RTP sessions (see
   Section 2.4), a single SSRC identifier space SHOULD be used across
   the sessions of all layers and the core (base) layer SHOULD be used
   for SSRC identifier allocation and collision resolution.  When a
   source discovers that it has collided, it transmits an RTCP BYE
   packet on only the base layer but changes the SSRC identifier to the
   new value in all layers.

That said, I think there would definitely be value in a way to do cross-session SSRC grouping, whether that's in RTCP or in SDP (or both).

--
Jonathan Lennox
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Oct 2011 09:58:07 +0200

On 2011-10-10 04:15, Jonathan Lennox wrote:
>> In my thinking of multi-stream handling I have considered SVC a
>> bit. But I don't find anything in the RFC that specifies how a
>> receiver actually determine in an MST usage the SSRCs in the
>> various sessions that are actually caries NALUs associated with a
>> particular source.
> 
> [...]
> 
>> Based on that the spec says that SSRC shall be assigned as RFC
>> 3550 says, they don't carry the same value.
> 
> 
> RFC 6190 doesn't explicitly say it, and I agree that's a flaw, but I
> was certainly under the impression that for mutli-session MST, the
> relevant part of 3550 was section 8.3:
> 

Well, this section says should, so it isn't required by the RTP base
specification. Thus I do think it really should be explicit about the
issue.

In addition there are reasons to question this recommendation as it is
potentially problematic. Maybe not seriously so in the case of scalable
codecs.

> 
> That said, I think there would definitely be value in a way to do
> cross-session SSRC grouping, whether that's in RTCP or in SDP (or
> both).

Updated drafts will be available no later than Monday for our proposal
in AVTEXT for this particular solution. A general discussion piece will
show up in AVTCORE.

-- 

Magnus Westerlund