Return-Path: 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 760FA21F875C for ; Thu, 9 Aug 2012 09:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.764 X-Spam-Level: X-Spam-Status: No, score=-100.764 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoE54iHuAglm for ; Thu, 9 Aug 2012 09:57:20 -0700 (PDT) Received: from blu0-omc1-s5.blu0.hotmail.com (blu0-omc1-s5.blu0.hotmail.com [65.55.116.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8DF21F8644 for ; Thu, 9 Aug 2012 09:57:20 -0700 (PDT) Received: from BLU002-W140 ([65.55.116.7]) by blu0-omc1-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Aug 2012 09:57:20 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_2bd16725-02e6-4120-9e53-f5ee1c9557b2_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: Harald Alvestrand Date: Thu, 9 Aug 2012 09:57:19 -0700 Importance: Normal In-Reply-To: <502258CA.5030009@alvestrand.no> References: <50222D44.5040105@alvestrand.no> , <502258CA.5030009@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Aug 2012 16:57:20.0082 (UTC) FILETIME=[09FF9B20:01CD7650] Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Possible BUNDLE alternative syntax: explicit m-line for bundled session X-BeenThere: mmusic@ietf.org 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: Thu, 09 Aug 2012 16:57:21 -0000 --_2bd16725-02e6-4120-9e53-f5ee1c9557b2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said:=20 > Bernard=2C since I'm so easily confused by how people transmit layers of= =20 > layered codecs=2C can you illustrate the particular scheme you want to=20 > use=2C and can't think of how to represent in Jonathan's scheme? [BA] I am looking at RFC 5583 "Signaling Media Decoding Dependency in SDP"= . An example of how this would be used with H.264/SVC is included in RFC 6190=2C= Section 7.3.4: a=3Dgroup:DDP L1 L2=0A= m=3Dvideo 20000 RTP/AVP 96=0A= a=3Drtpmap:96 H264/90000=0A= a=3Dfmtp:96 profile-level-id=3D4de00a=3B packetization-mode=3D0=3Bmst= -mode=3DNI-T=3B=0A= a=3Dmid:L1=0A= m=3Dvideo 20002 RTP/AVP 97=0A= a=3Drtpmap:97 H264-SVC/90000=0A= a=3Dfmtp:97 profile-level-id=3D53001F=3B packetization-mode=3D1=3B=0A= mst-mode=3DNI-TC=3B sprop-operation-point-info=3D<2=2C0=2C1=2C0=2C53= 000c=2C=0A= 3200=2C352=2C288=2C384=2C512>=2C<3=2C1=2C2=2C0=2C53001F=2C6400=2C704= =2C576=2C768=2C1024>=3B=0A= a=3Dmid:L2=0A= a=3Ddepend:97 lay L1:96 Here the a=3Ddepend line is expressing the decoding dependency (layered in = this case).=20 Let us assume that there is also audio=2C as in Jonathan's example: m=3Daudio 10000 RTP/AVP 0 8 97=0A= a=3Dmid:foo=0A= b=3DAS:200=0A= a=3Drtpmap:0 PCMU/8000=0A= a=3Drtpmap:8 PCMA/8000=0A= a=3Drtpmap:97 iLBC/8000 Does the entire SDP offer with BUNDLE and dependency grouping look like th= is (ignoring RTP/RTCP mux for the moment)?=20 v=3D0=0A= o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com=0A= s=3D=0A= c=3DIN IP4 host.atlanta.com=0A= t=3D0 0=0A= a=3Dgroup:BUNDLE foo L1 L2 baz a=3Dgroup:DDP L1 L2=0A= m=3Daudio 10000 RTP/AVP 0 8 98=0A= a=3Dmid:foo=0A= b=3DAS:200=0A= a=3Drtpmap:0 PCMU/8000=0A= a=3Drtpmap:8 PCMA/8000=0A= a=3Drtpmap:98 iLBC/8000=0A= a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host=0A= m=3Dvideo 20000 RTP/AVP 96=0A= a=3Drtpmap:96 H264/90000=0A= a=3Dfmtp:96 profile-level-id=3D4de00a=3B packetization-mode=3D0=3Bms= t-mode=3DNI-T=3B=0A= a=3Dmid:L1=0A= m=3Dvideo 20002 RTP/AVP 97=0A= a=3Drtpmap:97 H264-SVC/90000=0A= a=3Dfmtp:97 profile-level-id=3D53001F=3B packetization-mode=3D1=3B= =0A= mst-mode=3DNI-TC=3B sprop-operation-point-info=3D<2=2C0=2C1=2C0=2C53= 000c=2C=0A= 3200=2C352=2C288=2C384=2C512>=2C<3=2C1=2C2=2C0=2C53001F=2C6400=2C704= =2C576=2C768=2C1024>=3B=0A= a=3Dmid:L2=0A= a=3Ddepend:97 lay L1:96=0A= a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host=0A= m=3Dbundle 10000 RTP/AVP 0 8 96 97 98=0A= a=3Dmid:baz=0A= b=3DAS:1200=0A= a=3Dfull-rtpmap:0 audio/PCMU/8000=0A= a=3Dfull-rtpmap:8 audio/PCMA/8000=0A= a=3Dfull-rtpmap:98 audio/iLBC/8000=0A= a=3Dfull-rtpmap:96 H264/90000=0A= a=3Dfull-rtpmap:97 H264-SVC/90000=0A= a=3Ddepend:97 lay L1:96=0A= a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host=0A= =0A= = --_2bd16725-02e6-4120-9e53-f5ee1c9557b2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Harald said:
>=3B= Bernard=2C since I'm so easily confused by how people transmit layers of <= br>>=3B layered codecs=2C can you illustrate the particular scheme you wa= nt to
>=3B use=2C and can't think of how to represent in Jonathan's s= cheme?

[BA] =3B I am looking at RFC 5583 "Signaling Media Decodi= ng Dependency in SDP". An
example of how this would be used with H.264/S= VC is included in RFC 6190=2C Section 7.3.4:

      a=3Dgroup:DD=
P L1 L2=0A=
      m=3Dvideo 20000 RTP/AVP 96=0A=
      a=3Drtpmap:96 H264/90000=0A=
      a=3Dfmtp:96 profile-level-id=3D4de00a=3B packetization-mode=3D0=3Bmst=
-mode=3DNI-T=3B=0A=
      a=3Dmid:L1=0A=
      m=3Dvideo 20002 RTP/AVP 97=0A=
      a=3Drtpmap:97 H264-SVC/90000=0A=
      a=3Dfmtp:97 profile-level-id=3D53001F=3B packetization-mode=3D1=3B=0A=
       mst-mode=3DNI-TC=3B sprop-operation-point-info=3D<=3B2=2C0=2C1=2C0=
=2C53000c=2C=0A=
      3200=2C352=2C288=2C384=2C512>=3B=2C<=3B3=2C1=2C2=2C0=2C53001F=2C6=
400=2C704=2C576=2C768=2C1024>=3B=3B=0A=
      a=3Dmid:L2=0A=
      a=3Ddepend:97 lay L1:96

Here the a=3Ddepend line is expressi= ng the decoding dependency (layered in this case).

Let us assume th= at there is also audio=2C as in Jonathan's example:

       m=3D=
audio 10000 RTP/AVP 0 8 97=0A=
       a=3Dmid:foo=0A=
       b=3DAS:200=0A=
       a=3Drtpmap:0 PCMU/8000=0A=
       a=3Drtpmap:8 PCMA/8000=0A=
       a=3Drtpmap:97 iLBC/8000

Does the entire SDP offer with BUND= LE and dependency grouping =3B look like this (ignoring RTP/RTCP mux fo= r the moment)? 

       v=3D0=0A=
       o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.com=0A=
       s=3D=0A=
       c=3DIN IP4 host.atlanta.com=0A=
       t=3D0 0=0A=
       a=3Dgroup:BUNDLE foo L1 L2 baz
       a=3Dgroup:DDP L1 L2=0A=
       =3Bm=3Daudio 10000 RTP/AVP 0 8 98=0A=
       a=3Dmid:foo=0A=
       b=3DAS:200=0A=
       a=3Drtpmap:0 PCMU/8000=0A=
       a=3Drtpmap:8 PCMA/8000=0A=
       a=3Drtpmap:98 iLBC/8000=0A=
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host=0A=
       m=3Dvideo 20000 RTP/AVP 96=0A=
       a=3Drtpmap:96 H264/90000=0A=
       a=3Dfmtp:96 profile-level-id=3D4de00a=3B packetization-mode=3D0=3Bms=
t-mode=3DNI-T=3B=0A=
       a=3Dmid:L1=0A=
       m=3Dvideo 20002 RTP/AVP 97=0A=
       a=3Drtpmap:97 H264-SVC/90000=0A=
       a=3Dfmtp:97 profile-level-id=3D53001F=3B packetization-mode=3D1=3B=
=0A=
       mst-mode=3DNI-TC=3B sprop-operation-point-info=3D<=3B2=2C0=2C1=2C0=
=2C53000c=2C=0A=
      3200=2C352=2C288=2C384=2C512>=3B=2C<=3B3=2C1=2C2=2C0=2C53001F=2C6=
400=2C704=2C576=2C768=2C1024>=3B=3B=0A=
       a=3Dmid:L2=0A=
       a=3Ddepend:97 lay L1:96=0A=
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 20002 typ host=0A=
       m=3Dbundle 10000 RTP/AVP 0 8 96 97 98=0A=
       a=3Dmid:baz=0A=
       b=3DAS:1200=0A=
       a=3Dfull-rtpmap:0 audio/PCMU/8000=0A=
       a=3Dfull-rtpmap:8 audio/PCMA/8000=0A=
       a=3Dfull-rtpmap:98 audio/iLBC/8000=0A=
       a=3Dfull-rtpmap:96 H264/90000=0A=
       a=3Dfull-rtpmap:97 H264-SVC/90000=0A=
       a=3Ddepend:97 lay L1:96=0A=
       a=3Dcandidate:1 1 UDP 1694498815 host.atlanta.com 10000 typ host=0A=


 =0A=

= --_2bd16725-02e6-4120-9e53-f5ee1c9557b2_--