Re: [rtcweb] H.264 SVC and BUNDLE

Harald Alvestrand <harald@alvestrand.no> Thu, 30 August 2012 21:31 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5487921F8526 for <rtcweb@ietfa.amsl.com>; Thu, 30 Aug 2012 14:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.299
X-Spam-Level:
X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 p2ZEpkBjbHgN for <rtcweb@ietfa.amsl.com>; Thu, 30 Aug 2012 14:31:17 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 194E421F851B for <rtcweb@ietf.org>; Thu, 30 Aug 2012 14:31:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA14739E170; Thu, 30 Aug 2012 23:31:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj7ddQgrBxvE; Thu, 30 Aug 2012 23:31:13 +0200 (CEST)
Received: from [192.168.11.193] (c-56fbe555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.251.86]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AC94039E125; Thu, 30 Aug 2012 23:31:13 +0200 (CEST)
Message-ID: <503FDBA1.9000003@alvestrand.no>
Date: Thu, 30 Aug 2012 23:31:13 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.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>
In-Reply-To: <BLU002-W2102260755F0099C2AA98E93A70@phx.gbl>
Content-Type: multipart/alternative; boundary="------------020601060207030902090407"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] H.264 SVC and BUNDLE
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2012 21:31:18 -0000

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??)
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)