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

From: Harald Alvestrand <[email-masked]>
Date: Mon, 27 May 2013 22:49:13 +0200

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.

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?

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.

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 May 2013 09:31:00 -0400

Harald,

> 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.

> Query: Is this the problem we're discussing?

It is a (small) piece of the problem.

> but this one works only with a=imageattr because imageattr has a payload

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

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 30 May 2013 17:47:17 +0000

On May 27, 2013, at 2:49 PM, Harald Alvestrand <[email-masked]> wrote:

> Now, the video is the same.

Small nit … as far as I am concerned, if the above is a 3264 based offer, the video could be from two different cameras. You need some other signaling to indicate it is simulcast.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 31 May 2013 10:05:40 +0200

> Small nit … as far as I am concerned, if the above is a 3264 based offer, the video could be from two different cameras. You need some other signaling to indicate it is simulcast.
I did not intend it to say whether it was simulcast or not - I wasn't 
thinking of simulcast when I wrote it, just about "one of the parties 
says he wants two different, incompatible resolutions". "The video is 
the same" was badly formulated; I meant "The video codec is the same".

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 May 2013 08:16:19 +0000

>I don't like the name "demux", as I've said before.

Blame your parents - not us ;)

Regards,

Christer