Re: [MMUSIC] The pick-a-config debate - perhaps an useful example

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 28 May 2013 13:31 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 D373321F8976 for <mmusic@ietfa.amsl.com>; Tue, 28 May 2013 06:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.388
X-Spam-Level:
X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, 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 k8ZMG2DysTKl for <mmusic@ietfa.amsl.com>; Tue, 28 May 2013 06:31:02 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 0656521F8956 for <mmusic@ietf.org>; Tue, 28 May 2013 06:31:01 -0700 (PDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta01.westchester.pa.mail.comcast.net with comcast id hPEf1l0021uE5Es51RX1mG; Tue, 28 May 2013 13:31:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id hRX11l00F3ZTu2S3cRX10B; Tue, 28 May 2013 13:31:01 +0000
Message-ID: <51A4B194.6010800@alum.mit.edu>
Date: Tue, 28 May 2013 09:31:00 -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: mmusic@ietf.org
References: <51A3C6C9.6050606@alvestrand.no>
In-Reply-To: <51A3C6C9.6050606@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369747861; bh=kpfaKFMqVNr23w+p593vK8J1TonEAzq+Wck9vdEu9FM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GJYWxfFQ65LK9J+Jtn2IW0gYgJaYIHAw1jMr2v00VPLzFhTbDBvRZ8YTAHXVaL8oE ixbvde/P32RUK3cYDPQlTE6viinqUKX+lTdvLE81yRb4Cx8i3CL5UIZIT/oUWTsB9W LH/sMpEjsnO4ixikndagcwuoGX2mTa5Echjq+XDfmgiYdI5fbSWrY1UlfMveipVfPU 0uQvGadjXDQMTMYsAawwqkNmVHrqJjqBNug7W+cUcYfEjB7spy8IFVbh54+Kk2UPu5 +5+QrQGYozJz1pWAnHLF7oC1llROxUIJDNCR49FwORrfzMXdzD4qIoXMxmn1DQm6zO PGhH3GPVkgxBg==
Subject: Re: [MMUSIC] The pick-a-config debate - perhaps an useful example
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: Tue, 28 May 2013 13:31:06 -0000

Harald,

On 5/27/13 4:49 PM, Harald Alvestrand wrote:
> I don't like the name "demux", as I've said before.
> Neither do I like the term "select an m-line", because I don't think
> that's the only possible solution to the problem we're facing.

IMO "select an m-line" is not the whole problem, but it is part of the 
chosen solution. If we are going to use SDP, and in particular we are 
going to use the bundling of m-lines as a way to describe more complex 
usage of an RTP session, then it must be possible to associate packets 
with m-lines. (Or, as Colin prefers, to associate sources to m-lines 
based on what is received in the packets associated with a source.)

Once that is done, it provides more data that can be used to solve 
whatever problem you want to solve - to associate sources with 
MediaStreamTracks or CLUE capture encodings, or whatever.

> I think the problem we're facing can be illustrated like this: What
> resolution is permitted in the following config? (apologies in advance
> for syntactic brokenness)
>
> a=group:BUNDLE foo bar
>
> m=video
> a=mid:foo
> a=imageattr:* [x=160,y=100]
> a=rtpmap:96:vp8
>
> m=video
> a=mid:bar
> a=imageattr:* [x=640,y=480]
> a=rtpmap:96:vp8
>
> Now, the video is the same. The payload type is the same. But the sender
> of this SDP has stated an opinion about the image size that is in the
> form of M-line-related attributes.
>
> Query: Is this the problem we're discussing?

It is a (small) piece of the problem.

> Some solutions that have been suggested:
>
> My interpretation of Plan A: Create two payload types that both mean "vp8".
>
> m=video
> a=imageattr:* [x=160,y=100]
> a=rtpmap:96:vp8
>
> m=video
> a=imageattr:* [x=640,y=480]
> a=rtpmap:97:vp8
>
> My interpretation of a pure Plan B: Do SSRC-related signalling.
>
> m=video
> a=ssrc:4378 imageattr:* [x=160,y=100]
> a=rtpmap:96:vp8
> a=ssrc:9736 imageattr:* [x=640,y=480]
>
> (we don't need a second m-line here)
>
> For this particular attribute, there's also a plan with features of both:
>
> m=video
> a=imageattr:96 [x=160,y=100]
> a=rtpmap:96:vp8
> a=imageattr:97 [x=640,y=480]
> a=rtpmap:97:vp8
>
> but this one works only with a=imageattr because imageattr has a payload
> type.

As I am framing it (after some education by Colin), this can be 
accomplished by:

- get a first packet with a particular SSRC
- because it is new, set up a new "source" data structure for it
- use info in the packet (e.g., SSRC and/or PT) to associate the source
   to a particular m-line in the bundle
- use the imageattr(s) associated with that m-line to obtain the
   image size for this source

	Thanks,
	Paul

> A fourth solution is to decode the first frame, figure out how big it
> is, and see if we have a config it fits into. That sounds bizarre.
>
> A fifth solution is to declare a complete ban on conflicting attributes
> in bundled M-lines. Just Don't Do It.
> That reduces the expressive power of M-lines to what I was thinking
> about when I wrote the first bundle proposal: It's a way to describe a
> single RTP session, and what you can't say about a single RTP session,
> you can't say about a bundle describing a single RTP session either.
>
> But that might not be what people want.
>
>
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>