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

[Paul Kyzivat <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>