Christer Holmberg <> Fri, 31 August 2012 08:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C84F21F8501 for <>; Fri, 31 Aug 2012 01:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.572
X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dOGJJ8TdwEve for <>; Fri, 31 Aug 2012 01:53:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2241921F84FD for <>; Fri, 31 Aug 2012 01:53:51 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-c0-50407b9d1bd8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 64.BB.25676.D9B70405; Fri, 31 Aug 2012 10:53:50 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Fri, 31 Aug 2012 10:53:49 +0200
From: Christer Holmberg <>
To: Harald Alvestrand <>, Bernard Aboba <>
Date: Fri, 31 Aug 2012 10:53:48 +0200
Thread-Topic: [MMUSIC] H.264 SVC and BUNDLE
Thread-Index: Ac2HP7LkeXQkgNcnSXaMAq1DNJBrngADk32g
Message-ID: <>
References: <>, , <>, <>, <035101cd8636$3b654160$b22fc420$@com>, <>, <> <BLU002-W2102260755F0099C2AA98E93A70@phx.gbl>, <> <BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A3DCD92ESESSCMS0356e_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvre68aocAg68neS32L7nMbHGsr4vN YuryxywOzB5XJlxh9Xjcc4bNY8mSn0wBzFFcNimpOZllqUX6dglcGS/3d7IVzJnCWNHe+5Gx gXFqA2MXIyeHhICJxLMFB1kgbDGJC/fWs3UxcnEICZxilJj0eSUzhLOAUeLwt1tAHRwcbAIW Et3/tEEaRAQiJW48PcoMEmYWUJe4ujgIJMwioCqx6dN1JhBbWEBLYmPHYyaIcm2J35+6GCFs I4mbK48xg9i8AuESa3oWsECsmsAi8W7PabAEp4CuRNO2RrAGRqDjvp9aAzaIWUBc4taT+UwQ RwtILNlznhnCFpV4+fgfK0S9qMSd9vWMEPX5EleWXWKCWCYocXLmE5YJjKKzkIyahaRsFpIy iLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRODcxMye93EgvtSgzubg4P0+vOHUTIzAG D275rbqD8c45kUOM0hwsSuK81lv3+AsJpCeWpGanphakFsUXleakFh9iZOLglGpgVO3fvvrt PTnf+C9p5ZMmT3/mc09itsQnh5l7Hih+YGYp14ite+/JEJgdEdpwb0Hghwq3J/whby+KMC3d d7lN5Y9b84KlE1J/zvFp5781o1JcWqeQbeLb8pn1i8TznrBVLxUt2b/o+u1HUQ9SWEMXyfhe yJ1b2/fLQpBxX9oUlidhXDfm7Pa/osRSnJFoqMVcVJwIADgztGqPAgAA
Cc: "" <>
Subject: Re: [MMUSIC] H.264 SVC and BUNDLE
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Aug 2012 08:53:57 -0000


One question is of course whether we are going to move ahead with the m=bundle proposal. In that case, I guess the m=video lines would look like they do today, and the question is how we describe the multiplexed SVC within the m=bundle line.



From: [] On Behalf Of Harald Alvestrand
Sent: 31. elokuuta 2012 9:13
To: Bernard Aboba
Subject: Re: [MMUSIC] H.264 SVC and BUNDLE

On 08/31/2012 03:30 AM, Bernard Aboba wrote:
Harald said:

I lack the background to think about this... in existing equipment, if you want to do SST, but would be willing to do MST if the other end did not support SST, how would your offer look (without BUNDLE)?

My head hurts a little when trying to guess, but from your question it sounds like you've done it, so it's better if you just paste an example.

(BTW, this is really an MMUSIC discussion)

[BA] RFC 6190 gives several examples of SST and MST offers:
7.3.1<>.  Example for Offering a Single SVC Session
7.3.2<>.  Example for Offering a Single SVC Session Using scalable-layer-Id
7.3.3<>.  Example for Offering Multiple Sessions in MST
7.3.4<>.  Example for Offering Multiple Sessions in MST Including Operation with Answerer Using scalable-laye

7.3.5<>.  Example for Negotiating an SVC Stream with a Constrained Base Layer in SST
I believe that the answer to your question is closest to example 7.3.5 (SST) with a bit of 7.3.4 (MST) thrown in. Notice that Payload types 97 and 99 are similar but not the same (97 is SST, 99 is MST):
Aha - so you'd send 3 video M-lines, an SST-only application would zero out the second and third, while an MST-only application would zero out the first, and one capable of doing both would accept all 3? and one could look at the payload type (96/97 vs 98 or 99) to decide which one a particular video stream belonged to?

It makes no sense (to my mind at least) to multiplex L1 and L2 together, but one could multiplex SST with L1 and save one port in the "both are supported" case:

a=group:BUNDLE SST L1

I think this would create sessions that would not create an unsolvable problem; if all were accepted, the decoder would have to look at the payload type of the first packet on an SSRC to figure out whether a particular SSRC was using SST or MST for that particular payload.


      a=group:DDP L1 L2

      m=video 20000 RTP/AVP 97 96

      a=rtpmap:96 H264-SVC/90000

      a=fmtp:96 profile-level-id=53001e; packetization-mode=0;

      a=rtpmap:97 H264-SVC/90000

      a=fmtp:97 profile-level-id=53001f; packetization-mode=1;


      m=video 20002 RTP/AVP 98

      a=rtpmap:98 H264/90000

      a=fmtp:98 profile-level-id=4de00a; packetization-mode=0;



      m=video 20004 RTP/AVP 99

      a=rtpmap:99 H264-SVC/90000

      a=fmtp:99 profile-level-id=53001F; packetization-mode=1;

       mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,



      a=depend:99 lay L1:98

On 08/30/2012 11:19 PM, Bernard Aboba wrote:
Harald said:
> My assumption has always been that if you were operating on a network
> that could only apply diffserv to separate 5-tuples, you would allocate
> the SSRCs comprising a multilayer encoding to different 5-tuples.

[BA] RFC 6190 Section 1 says:

   This memo defines two basic modes for transmission of SVC data,

   single-session transmission (SST) and multi-session transmission

   (MST).  In SST, a single RTP session is used for the transmission of

   all scalability layers comprising an SVC bitstream; in MST, the

   scalability layers are transported on different RTP sessions.

[BA] So it is possible either to use multiple 5-tuples (MST) or a single 5-tuple (SST).  However, my understanding
is that the SST approach is more popular than MST.

> This choice seems to be a choice that the application writer should take
> before deciding whether or not to use BUNDLE, so it's a little hard to
> see what the relationship to BUNDLE is.

[BA] The open question has been how to indicate the desire for both layered coding and BUNDLE in SDP,
given the backward compatibility issues we have talked about.  For example, if it is desired to do SST and
BUNDLE, do you signal MST and BUNDLE on different ports in the offer and then if SST and BUNDLE are
supported by the answer, have the answer respond with BUNDLE as well as dependency groups using
the same port?  That would seem to imply an assumption that every MST implementation can also do SST.
Or do do you signal SST and BUNDLE on the same port, and then if the response indicates that the SDP
was rejected, formulate an alternative offer (MST with BUNDLE?  H.264/AVC with BUNDLE?
SST without BUNDLE??)