Subject: [clue] Kick-off Item 2: Layout, composition, switching discussion

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 27 Oct 2011 08:30:28 -0700

This is following up on the major issues list from the interim meeting in Andover.
Issues for discussion:

1.       Item 5 video composition (discussion kicked off by Stephan) is a part of this.  But more generally, the same sort of issue applies to other media types, not just video.

a.       For example, should a provider that mixes audio be able to indicate to the consumer which audio sources are in the mix?

b.      Proposal - the more general case should be consistent with the outcome of the Item 5 discussion.

2.       Should a provider that mixes or composes other media captures/streams into a new stream be able to indicate some information about the algorithm it uses to choose which other captures/streams to mix?

a.       Proposal - no, CLUE does not need this.

3.       Should a provider that mixes or composes media be able to allow the consumer to make a choice about which other captures/streams are included in the mix?

a.       This should be covered by Major Issue Item 3 source selection - (discussion to be kicked off by Jonathan)

4.       Do we need support in CLUE for allowing a media consumer to request the provider to compose or mix particular media sources into a new media stream, using a particular algorithm?

a.       Proposal - no, CLUE does not need this.

b.      But if something like item 5 idea is accepted, then maybe a provider can offer a few alternatives and a consumer can choose among them

Mark Duckworth

---

From: Roni Even <[email-masked]>
Date: Thu, 27 Oct 2011 23:55:04 +0200

Hi Mark,

I understand that you have two topics

1.       Allowing the consumer to select specific media streams for a mix
(for example, left camera from room 1, middle camera from room 2 and left
camera from room 3) which I think should be possible. This will require
information and protocol that will allow this functionality.

2.       Allowing the provider  to specify the mixture algorithm and for the
consumer to ask for a specific one. I think that we need at least to enable
the provider and consumer to specify or request site switch or segment
switch mode.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Duckworth, Mark
Sent: Thursday, October 27, 2011 5:30 PM
To: [email-masked]
Subject: [clue] Kick-off Item 2: Layout, composition, switching discussion

This is following up on the major issues list from the interim meeting in
Andover.

Issues for discussion:

1.       Item 5 video composition (discussion kicked off by Stephan) is a
part of this.  But more generally, the same sort of issue applies to other
media types, not just video.

a.       For example, should a provider that mixes audio be able to indicate
to the consumer which audio sources are in the mix?

b.      Proposal - the more general case should be consistent with the
outcome of the Item 5 discussio

2.       Should a provider that mixes or composes other media
captures/streams into a new stream be able to indicate some information
about the algorithm it uses to choose which other captures/streams to mix?

3.       Should a provider that mixes or composes media be able to allow the
consumer to make a choice about which other captures/streams are included in
the mix?

a.       This should be covered by Major Issue Item 3 source selection -
(discussion to be kicked off by Jonathan)

4.       Do we need support in CLUE for allowing a media consumer to request
the provider to compose or mix particular media sources into a new media
stream, using a particular algorithm?

b.      But if something like item 5 idea is accepted, then maybe a provider
can offer a few alternatives and a consumer can choose among them

Mark Duckworth

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Oct 2011 18:20:54 -0400

On 10/27/11 5:55 PM, Roni Even wrote:
> 1.Allowing the consumer to select specific media streams for a mix (for
> example, left camera from room 1, middle camera from room 2 and left
> 2.Allowing the provider to specify the mixture algorithm and for the
> consumer to ask for a specific one. I think that we need at least to
> enable the provider and consumer to specify or request site switch or
> segment switch mode.

This all sounds useful. But ISTM there should be a very clear 
distinction between choices that affect only the consumer making the 
choice, and those that affect other consumers, because of physical or 
resource constraints. Typically it won't matter as long as there are 
only two endpoints, but as soon as there are more it may.

	Thanks,
	Paul

> Roni
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Duckworth, Mark
> *Sent:* Thursday, October 27, 2011 5:30 PM
> *To:* [email-masked]
> *Subject:* [clue] Kick-off Item 2: Layout, composition, switching discussion
>
> 1.Item 5 video composition (discussion kicked off by Stephan) is a part
> of this. But more generally, the same sort of issue applies to other
> a.For example, should a provider that mixes audio be able to indicate to
> the consumer which audio sources are in the mix?
>
> b.Proposal – the more general case should be consistent with the outcome
> of the Item 5 discussio
>
> 2.Should a provider that mixes or composes other media captures/streams
> into a new stream be able to indicate some information about the
> algorithm it uses to choose which other captures/streams to mix?
>
> a.Proposal – no, CLUE does not need this.
>
> 3.Should a provider that mixes or composes media be able to allow the
> consumer to make a choice about which other captures/streams are
> included in the mix?
>
> a.This should be covered by Major Issue Item 3 source selection –
> 4.Do we need support in CLUE for allowing a media consumer to request
> a.Proposal – no, CLUE does not need this.
>
> b.But if something like item 5 idea is accepted, then maybe a provider
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Roni Even <[email-masked]>
Date: Fri, 28 Oct 2011 17:45:07 +0200

Paul,
A consumer should be able to request specific streams from the offered set.
The provider (probably an MCU) may send them mixed as one stream or as
separate streams. As for mixing, I think that many MCUs can send a different
mixed stream to each consumer.
Roni

> -----Original Message-----
> Paul Kyzivat
> Sent: Friday, October 28, 2011 12:21 AM
> To: [email-masked]
> Subject: Re: [clue] Kick-off Item 2: Layout, composition, switching
> discussion
> 
> > This is following up on the major issues list from the interim
> meeting
> > in Andover.
> >
> > Issues for discussion:
> >
> > b.Proposal - the more general case should be consistent with the
> outcome
> > of the Item 5 discussio
> >
> > a.Proposal - no, CLUE does not need this.
> >
> > a.This should be covered by Major Issue Item 3 source selection -
> > a.Proposal - no, CLUE does not need this.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 13:24:04 -0400

> mixed stream to each consumer.

I think you are saying there won't be cases where requests by one 
consumer impact what another consumer can get. If so then the 
distinction I was asking about is moot.

But some of these points suggest mechanisms to make requests that aren't 
just selections from an offered set, and that raise the possibility of 
requests that require more than a preplanned resource allocation. My 
point is that *if* this is possible it puts a different spin on the 
entire negotiation process.

	Thanks,
	Paul

---

From: Stephen Botzko <[email-masked]>
Date: Sat, 29 Oct 2011 19:45:12 -0400

In-line
Stephen Botzko

On Fri, Oct 28, 2011 at 1:24 PM, Paul Kyzivat <[email-masked]> wrote:

> I think you are saying there won't be cases where requests by one consumer
> impact what another consumer can get. If so then the distinction I was
> asking about is moot.
>
> requests that require more than a preplanned resource allocation. My point
> is that *if* this is possible it puts a different spin on the entire
> negotiation process.
>

[sb]It would mean that the provider needs to be able to deny the request.
Are you seeing other implications?

>>>> 1.Allowing the consumer to select specific media streams for a mix
>>>>
>>> (for
>>>
>>>> camera from room 3) which I think should be possible. This will
>>>>
>>> require
>>>
>>>> *From:[email-masked] [mailto:[email-masked]] *On
>>>>
>>> Behalf
>>>
>>>> Of *Duckworth, Mark
>>>> *Subject:* [clue] Kick-off Item 2: Layout, composition, switching
>>>>
>>> discussion
>>>
>>>>
>>>> 1.Item 5 video composition (discussion kicked off by Stephan) is a
>>>>
>>> part
>>>
>>>> a.For example, should a provider that mixes audio be able to indicate
>>>>
>>> to
>>>
>>> outcome
>>>> 2.Should a provider that mixes or composes other media
>>>>
>>> captures/streams
>>>
>>>> the provider to compose or mix particular media sources into a new
>>>>
>>> media
>>>
>>>> b.But if something like item 5 idea is accepted, then maybe a
>>>>
>>> provider
>>>
>>>> ______________________________**_________________
>>>> clue mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>
>>>
>>> ______________________________**_________________
>>> clue mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>
>>
>>
>>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Oct 2011 11:35:11 -0400

inline

On 10/29/11 7:45 PM, Stephen Botzko wrote:
> In-line
> Stephen Botzko
>
> On Fri, Oct 28, 2011 at 1:24 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     But some of these points suggest mechanisms to make requests that
>     aren't just selections from an offered set, and that raise the
>     possibility of requests that require more than a preplanned resource
>     allocation. My point is that *if* this is possible it puts a
>     different spin on the entire negotiation process.
>
>
> [sb]It would mean that the provider needs to be able to deny the
> request.  Are you seeing other implications?

If requests are always to be denied when they negatively impact some 
other participant, then that is probably sufficient.

The problem I am considering is if a request might be accepted even 
though it negatively impacts some other participant. In such a case the 
one making the request ought to know the implications.

For instance, at one point there was talk of a camera that could either 
one of two views. Both could be offered as captures, but they are 
mutually exclusive to the entire collection of remote endpoints. In a 
two endpoint call there is no problem allowing the remote endpoint to 
choose. But when there is an MCU and more than two endpoints, the MCU 
could still offer both captures, but a choice among them by one endpoint 
removes the choice from the others.

What I am thinking of is something like floor control: access to scarce 
resources should be explicitly managed.

Perhaps in such a situation the two alternative captures aren't 
represented the same way that normal capture sets are. Rather there is 
some distinct control mechanism that has the effect of altering the 
available capture sets.

	Thanks,
	Paul

>             From: [email-masked] <mailto:[email-masked]>
>             [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of
>             Paul Kyzivat
>             To: [email-masked] <mailto:[email-masked]>
>                 *From:[email-masked]
>                 <mailto:[email-masked]>
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>] *On
>
>             Behalf
>
>                 Of *Duckworth, Mark
>                 *To:* [email-masked] <mailto:[email-masked]>
>                 _________________________________________________
>                 clue mailing list
>                 [email-masked] <mailto:[email-masked]>
>                 https://www.ietf.org/mailman/__listinfo/clue
>                 <https://www.ietf.org/mailman/listinfo/clue>
>
>
>             _________________________________________________
>             clue mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/__listinfo/clue
>             <https://www.ietf.org/mailman/listinfo/clue>
>
>
>
>
>     _________________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/clue
>     <https://www.ietf.org/mailman/listinfo/clue>
>
>