Re: [MMUSIC] H.264 SVC and BUNDLE

Bernard Aboba <bernard_aboba@hotmail.com> Fri, 31 August 2012 01:30 UTC

Return-Path: <bernard_aboba@hotmail.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 B84A321F8516 for <mmusic@ietfa.amsl.com>; Thu, 30 Aug 2012 18:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.998
X-Spam-Level:
X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 iev4OuFuIBPP for <mmusic@ietfa.amsl.com>; Thu, 30 Aug 2012 18:30:35 -0700 (PDT)
Received: from blu0-omc1-s6.blu0.hotmail.com (blu0-omc1-s6.blu0.hotmail.com [65.55.116.17]) by ietfa.amsl.com (Postfix) with ESMTP id 514AF21F8512 for <mmusic@ietf.org>; Thu, 30 Aug 2012 18:30:34 -0700 (PDT)
Received: from BLU002-W229 ([65.55.116.8]) by blu0-omc1-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Aug 2012 18:30:32 -0700
Message-ID: <BLU002-W229ACEE3EA717C4E272462393A60@phx.gbl>
Content-Type: multipart/alternative; boundary="_05bb94cb-6064-4e3d-9413-2733ebc94c71_"
X-Originating-IP: [72.11.69.66]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 30 Aug 2012 18:30:31 -0700
Importance: Normal
In-Reply-To: <503FDBA1.9000003@alvestrand.no>
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>
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Aug 2012 01:30:32.0295 (UTC) FILETIME=[36432F70:01CD8718]
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: Fri, 31 Aug 2012 01:30:35 -0000

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 Session7.3.2.  Example for Offering a Single SVC Session Using scalable-layer-Id7.3.3.  Example for Offering Multiple Sessions in MST7.3.4.  Example for Offering Multiple Sessions in MST Including Operation with Answerer Using scalable-layer-id7.3.5.  Example for Negotiating an SVC Stream with a Constrained Base Layer in SSTI 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??)