Re: [MMUSIC] H.264 SVC and BUNDLE
"Cullen Jennings (fluffy)" <fluffy@cisco.com> Wed, 19 September 2012 16:39 UTC
Return-Path: <fluffy@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E5821F86BA for <mmusic@ietfa.amsl.com>; Wed, 19 Sep 2012 09:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Level:
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AebdNMKDEowS for <mmusic@ietfa.amsl.com>; Wed, 19 Sep 2012 09:39:14 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 546B221F869C for <mmusic@ietf.org>; Wed, 19 Sep 2012 09:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5627; q=dns/txt; s=iport; t=1348072754; x=1349282354; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=b5DpvM+9QH9ISvdoGeyOIpNDvQ+KlnUuYzxIbXFeBjo=; b=J44OzNqUzNgAkEsN03GmWcQBn9vp57zEbVkMPw4E9dUufCxxr+Gqbjp6 AYxIxksdfXfZeUmw4FqRN6Mq2YXXZH+6CE4epklUddRTF6ifu1XPFuf1W /c2P1ISmV5T/U6dHl1NXCaYOd8Vtoap4QolmUhVrto7uFXgJvk5wDZHJ3 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkoFANDzWVCtJV2a/2dsb2JhbABCA6pVkW6BCIIgAQEBAwEBAQEPAVsEBwULAgEIGC4nCyUCBA4FIodPAwYGC5ptoBAEijpigx2CRGADiCGLb4FUixeDIYFpgmaCFw
X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="123013333"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 19 Sep 2012 16:39:13 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8JGdDGj000863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 16:39:13 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Wed, 19 Sep 2012 11:39:10 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Thread-Topic: [MMUSIC] H.264 SVC and BUNDLE
Thread-Index: AQHNloVLMhpQ5M3/Q0ylwrKrMlDtkw==
Date: Wed, 19 Sep 2012 16:39:10 +0000
Message-ID: <11997BCA-DD8D-4823-AB51-4D4999F31590@cisco.com>
References: <503E0B63.3020708@ericsson.com>, , <E17CAD772E76C742B645BD4DC602CD8106A9810E@NAHALD.us.int.genesyslab.com>, <7F2072F1E0DE894DA4B517B93C6A05853409FF2F4C@ESESSCMS0356.eemea.ericsson.se>, <035101cd8636$3b654160$b22fc420$@com>, <03FBA798AC24E3498B74F47FD082A92F177393B8@US70UWXCHMBA04.zam.alcatel-lucent.com>, <503FCAA1.5080500@alvestrand.no> <BLU002-W2102260755F0099C2AA98E93A70@phx.gbl>, <503FDBA1.9000003@alvestrand.no> <BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl>
In-Reply-To: <BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19192.002
x-tm-as-result: No--48.401500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2B2A419943A1D34E938C1B4D7277E7C7@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] H.264 SVC and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Sep 2012 16:39:15 -0000
If you do what have been suggesting for bundle, the offer of SVC with bundle looks exactly the same with the exception that an a=bundle line gets added and if the receiver supports bundle, they know they put things on the same port. We can talk about this more but I have a hard time imaging anything else working with existing SDP. So the only change to SDP in offer below is the addition of line "a=group:BUNDLE SST L1 L2" a=group:BUNDLE SST L1 L2 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; a=mid:SST m=video 20002 RTP/AVP 98 a=rtpmap:98 H264/90000 a=fmtp:98 profile-level-id=4de00a; packetization-mode=0; mst-mode=NI-T; a=mid:L1 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, 3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>; a=mid:L2 a=depend:99 lay L1:98 I have a hard time imagining any SIP UAS that would did SVC that would have a problem with this even if it did not understand bundle. On Aug 30, 2012, at 7:30 PM, Bernard Aboba <bernard_aboba@hotmail.com> 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-layer-id > > 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): > > Offer: > 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; > > a=mid:SST > m=video 20002 RTP/AVP 98 > a=rtpmap:98 H264/90000 > a=fmtp:98 profile-level-id=4de00a; packetization-mode=0; > mst-mode=NI-T; > a=mid:L1 > 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, > 3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>; > a=mid:L2 > 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??) > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic
- Re: [MMUSIC] H.264 SVC and BUNDLE Bernard Aboba
- Re: [MMUSIC] H.264 SVC and BUNDLE Harald Alvestrand
- Re: [MMUSIC] H.264 SVC and BUNDLE Christer Holmberg
- Re: [MMUSIC] H.264 SVC and BUNDLE Harald Alvestrand
- Re: [MMUSIC] H.264 SVC and BUNDLE Christer Holmberg
- Re: [MMUSIC] H.264 SVC and BUNDLE Harald Alvestrand
- Re: [MMUSIC] H.264 SVC and BUNDLE Cullen Jennings (fluffy)