Re: [MMUSIC] Proposal for what bundle should say about demux

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 23 May 2013 22:18 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 6588E21F9837 for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 15:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.295
X-Spam-Level:
X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 99urmzo0jpFN for <mmusic@ietfa.amsl.com>; Thu, 23 May 2013 15:18:37 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id A3C9221F984B for <mmusic@ietf.org>; Thu, 23 May 2013 14:34:17 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta10.westchester.pa.mail.comcast.net with comcast id fSo11l0060QuhwU5AZaHrk; Thu, 23 May 2013 21:34:17 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id fZaG1l00i3ZTu2S3NZaGvb; Thu, 23 May 2013 21:34:17 +0000
Message-ID: <519E8B58.9030604@alum.mit.edu>
Date: Thu, 23 May 2013 17:34:16 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com> <519E6265.4090102@alum.mit.edu> <CABkgnnVNHcDAtDZ8DR1gHfFyeRe9fUcjZ0jS3S=oEQxC+6qBjg@mail.gmail.com>
In-Reply-To: <CABkgnnVNHcDAtDZ8DR1gHfFyeRe9fUcjZ0jS3S=oEQxC+6qBjg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369344857; bh=BKIIqzjnmPOnVpdVqPH/QgiLbVjASz/bzM//QzHFDnI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Q07yDhAO4CX81/13Bi5WLo0Ov9ErB/T4HuECNwwJBofEklvMu35mXFwByIX+6L5EM t0EcG4Bz5vij13kUMjnEnRyoxJexjun0k0tQAxDGtftYkdX9adKgUzzrJqkaFe+nfd vmID8q8IyUzTjdzC0mAdqCZ6+z1iMiZQW1JSDM2BWUlHt+hwCfCdR9bH76B16dqBlE V92xcnuiL6VGHcAmUJ//zqNEjh9cCldhAy1q++/eHIwsnUO5P0wZxO3I6C0jZ0ERrC 9idZJDWc7LxfYt1rae7GrKVD4geZTrPPLMUSlMJ70Dto1Elso7KFTWpoGzFE9MJ6h/ HN2Bd4AudZXxw==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Proposal for what bundle should say about demux
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: Thu, 23 May 2013 22:18:52 -0000

On 5/23/13 4:57 PM, Martin Thomson wrote:
> On 23 May 2013 11:39, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>> Generally, once one packet has been bound to a processing pipeline then the
>> SSRC from that can be remembered, and used to shortcut the mapping for
>> future packets that have the same SSRC.
>
> This is actually the key.  The pipeline should be attached to the
> SSRC.  How that attachment is initially formed is what I think that
> Cullen is talking about.
>

Well, I said *generally*, not *always*.

For instance, we have a clue case where we can have two clue switched 
captures, one representing the video for loudest speaker, and one for 
the 2nd loudest speaker. A single SSRC can move from one of those 
captures to the other. Its the capture (identified by an rtp header 
extension) that selects the processing pipeline.

Or, you can view it as layered. Where the ssrc maps to an early stage of 
the pipeline (selected by ssrc) that does the codec processing, and then 
a different stage of the pipeline (selected by capture id from the 
header extension) that switches the decoded output to a particular 
rendering device.

	Thanks,
	Paul