Subject: Re: [clue] RTP Muxing Guidance

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Mar 2011 16:39:57 +0100

Lauwers, Chris skrev 2011-02-28 23:18:
> Magnus,
> 
> The "RTP Payload Format for SVC" draft
> (http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-27) proposes
> multiplexing different layers of the same SVC stream within the same
> RTP session (and potentially different SVC streams associated with a
> multi-party conference as well). Based on your analysis below, do you
> consider that an appropriate use of RTP multiplexing?

Yes, it is. The different layers part of an SVC stream do provide
different quality levels for an single source. In cases when you don't
need QoS and rely on MANEs for adaptation, like in cases with a central
bridge then this is appropriate. If you have other requirements then you
may need to use multiple RTP sessions, like in the case of using
multicast and splitting the layers over different addresses to allow
each receiver to join what it is capable of receiving.

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: Thomas Schierl <[email-masked]>
Date: Mon, 07 Mar 2011 16:53:26 +0100

Dear Magnus,

During the standardization process of the RTP payload format for SVC, we 
also found out that the SSRC multiplexing is in some cases an 
appropriate method to distinguish between layers within a single RTP 
session. This for sure has advantages over payload specific methods, 
since generic RTP mechanisms can be used. The fact has further been 
discussed in RFC 6051.

Best regards,
Thomas

On 07.03.2011 16:39, Magnus Westerlund wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>
>

-- 
Visit us at

CeBIT 2011 / March 1-5 / Hanover, Germany / Hall 9, Booth B36 + Hall 15 Booth A24
http://www.hhi.fraunhofer.de/cebit

OFC 2011 / March 8-10 / Los Angeles, Convention Center, USA / booth 2037
http://www.ofcnfoec.org

Web 2.0 / March 28-31 / San Francisco, Moscone West, USA / booth 824
http://www.web2expo.com

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 8 Mar 2011 09:51:34 +0100

> since generic RTP mechanisms can be used. The fact has further been

Sure, it does have some drawbacks but clearly some advantages also. In
general when it comes on how to demultiplex things, one needs to
carefully consider what the goals are, in which application context one
will use it and what drawbacks or limitations one can accept.

The fact that one want to reach many application contexts with SVC RTP
payload format is also the reason one ends up with several alternative
solutions. Thus, the application needs to choose the solution that fits
their requirements.

Cheers

Magnus Westerlund

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Tue, 8 Mar 2011 10:40:32 +0100

We have two important use cases for multiplexing video, sending spatial video streams (e.g. left, center, right camera) and receive video for multiple screens. 

I think both fits into the RTP model with multiple RTP streams on the same RTP session. Currently a separate RTP session for audio and video is used, which gives the possibility to assign individual QoS to audio and video. 

Regards 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: 7. mars 2011 16:40
To: Lauwers, Chris
Cc: CLUE CLUE
Subject: Re: [clue] RTP Muxing Guidance

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 9 Mar 2011 16:27:20 +0100

Hi Espen,

Espen Berger (espeberg) skrev 2011-03-08 10:40:
> We have two important use cases for multiplexing video, sending
> spatial video streams (e.g. left, center, right camera) and receive
> video for multiple screens.

Yes, there is different reasons for how one transmit information within
RTP sessions. Thus there is need to review what the goals and
requirements are here.

> 
> I think both fits into the RTP model with multiple RTP streams on the
> same RTP session. Currently a separate RTP session for audio and
> video is used, which gives the possibility to assign individual QoS
> to audio and video.
> 

It is not unlikely that you are correct, however in general I think
there is need for reviewing goals and requirements. It is also likely
that for example how RTP is to handle multi-view media sources is not a
CLUE issue at all, it belongs in the right AVT group. AVTCore, AVTExt
and Payload are all possible WGs depending on which questions that needs
to be tackled.

I think it is good that people starts thinking about these problems, but
can we please start looking it at from a use case and requirement
perspective and try to write down that. What are the goals, what known
limitations exist etc. Lets start in this area and then later we will
come to the discussion on how to resolve things.

Cheers

Magnus Westerlund