Subject: RE: [AVT] draft-schierl-mmusic-layered-codec

From: Jonathan Lennox <[email-masked]>
Date: Sun, 05 Nov 2006 21:49:10 -0500

Thomas Schierl wrote:
> In the SVC payload format draft in section 6.2, we proposed a random
> mechanism using SSRC subspaces. Anyway, you are right with the
> collision problem. For that reason we propose to use this mechanism
> within single-sender scenarios only. A further reason for that is
> that you cannot differentiate between senders by the implicitly
> assigned SSRCs.     

To clarify further, when you say "single sender" you actually mean "single
source", right?  I.e., when this mechanism is used, the implicit assumption
is that all the SSRCs used in an RTP session correspond to a single media
stream?

When used with H.264 SVC, this would require the use of packetization mode 2
(DON headers), right?   Otherwise there's no way to reconstruct decoding
order.

Have you given any thought to how this interacts with the RTP retransmission
payload, which also multiplexes based on SSRC?

-- 
Jonathan Lennox -- Layered Media
[email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sun, 5 Nov 2006 19:33:52 -0800

> is that all the SSRCs used in an RTP session correspond to a single  

Remember that receivers have an SSRC too, and should send RTCP.

Colin

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 6 Nov 2006 10:30:34 -0800

> Remember that receivers have an SSRC too, and should send RTCP.

To Jonathan: The draft may not use the best possible terminology, but  
the gist of the term "single sender" is that there is an entity which  
has complete control over all forward (media) channel SSRC usage.   
And yes, we assume that in one session there is only a single SVC  
scalable bitstream being conveyed (with a given PT).  Is this a  
serious restriction?

To Colin: We have not forgotten the RTCP traffic.  There are ways how  
the sender could handle SSRC collisions.  They are in the draft.   
What the draft could be clearer at is how to handle RTCP traffic in a  
MANE.  the most straightforward way would be to a) identify the  
traffic (by the PT values), and b) "translate" those packets by  
looking into the destination SSRCes (the ones in the report block(s))  
and forwarding them to the appropriate IP multicast group(s).   Which  
has the small problem that the RTCP RRs cannot be encrypted, but that  
does not seem a major issue to me.

Stephan