Subject: [clue] Raw notes from today's design team meeting

From: Marshall Eubanks <[email-masked]>
Date: Tue, 7 Feb 2012 11:04:15 -0500

Tue Feb  7 10:04:08 EST 2012
CLUE Design Team Meeting

Marshall Eubanks
Mary Barnes
Paul K
Brian Baldino
Espen Berger
John Leslie
Jonathan Lennox
Mark Duckworth
Roni Even
Spencer Dawkins

Mary : I thought we would talk about the stuff in the appendix. None
of that has changed ?

<Framework Document brought up>

Appendix A

A.1 - Isn't this Issue 7 (in the tracker) ?

Would it make more sense to remove it from here as it is in the tracker ?

Roni : I think we should leave it here. It is still an issue. I don't
think we should remove any open issues from here.

Mary : We should at least update the tracker to point this out.

If people are going to talk about it, they should refer to the tracker.

Mark : Are you saying that the issue tracker should point to the
document. You don't want to cross-reference the other way ?

Mary, Ron : No

Mary : A.2 - Source is selectable.

Mark : Originally, this was in the main body as an attribute, but it
no longer it is the main body. Should there be such an attribute is
part of the open issue. There is nothing in 6.1

Jonathan : Is it an attribute of the source or the capture ?

Mark : We thought that a media capture should have an attribute like
this, so that the consumer can give input as to what source to select
for example.

Paul : Doesn't make much sense without a mechanism.

Jonathan : Positive capture gets a little vague at this point. What is
the point of sources you can't capture?

Paul : If you can select where the camera pointed ?

Mark : Let's go to A.3, I think it is overriding. Once we figure it
out, then we can decide A.2.

Mary : OK, let's do that then.

Mark : Have the chairs determined that this is in charter ?

Jonathan : And it is related to what's coming up in Dispatch in Paris.

Mary : You mean Magnus's mess. (He called it that.)

Mary : A roster is not needed?

Roni : It doesn't talk about a roster of the participant, which is not
in scope as I understand. It is a list of equipment.  All of the
examples have a very flat model. You can't see what's
behind the MCU.

The capture set describes some captures from your provider, which is
an MCU in multipoint, and you don't know what is behind the MCU. I
think that is what A.3 talks about.

Mark : I think that's correct.

Roni : We are not talking about the actual people in the conference.
We are talking about more information in the case of an MCU.

Mark : So in this context, roster is a list of end point equipment.

Jonathan : It might have people's info. Person's X Desk.

Paul : The equipment is a source of streams. This is a catalog of
potential streams, both raw captures and streams from other equipment.

Jonathan : The roster is every stream. It might well provide both the
original streams and  captures.

Mary : So, I think we agree that a roster would not be a list of people.

Jonathan : If there was a list of people anyway, it would be useful to
have a simple way to correlate it with this roster. At some point we
need to understand how to do that.

Mary : Is there an action here ?

Jonathan : The model for A.3 controls A.2. There are two models here.
One is, you have a set, if an original source is available, you list
all pure captures as well as any massaged captures.

Whereas the other model is thinking more like meta-captures, and you
get to chose which sources go into it.

Sources may come and go quickly in a large conference.

Roni : This can be very complicated. You don't do this in this case in the MCU ?

It may be more relevant in the case where the MCU is mixing and you
want to mix a specific capture to receive it.

Jonathan : We are doing it now.

Roni : This is OK in your system, where everyone will have the same codec.

Mark : Or that is up to the middle box.

Roni : To receive a stream directly from another site.

Marshall : If people get to pick who (which equipment) is in a
composition I think that they will want to have finer scale control of
the composition (conference room XYZ goes in the upper left hand
corner of the hollywood squares, that sort of thing).

Mark (?) : That adds a whole extra layer of complexity to this.

Marshall : But if people have the ability to select who is in a
stream, they will want finer grain control. This is common now, just
not at the machine layer, but the manual configuration layer.

Jonathan : There is also Issue 1.

Mary : A.4 - input requesting many streams.

Marshall : I don't think that "many" is the problem here. There isn't
a problem with size, per se, as long as there is bandwidth and CPU to
handle it. The problem is more in a finer grain control of the
selection.

I see the example as problematic - 3 loudest speakers ? How do I do
gain control ?

Roni : In the previous question - how do you describe this from the
MCU to the endpoint ? You describe it from the point of view of the
MCU, not the ultimate endpoint. In the current model this is not
achievable.

Brian : You don't need a lot of information to do a few PIPs.

Jonathan : The model I am familiar with is I want to see the current
speaker large and the previous speaker small and don't send me the
other ones.

Mark : I don't think that the current system has enough information to do that.

Jonathan : So, you want the ability to say "this capture is the 3rd
most recent speaker."

Espen : You are saying "I want the middle box to select the three most
relevant speakers"

Marshall : Are you saying that the end user should be able to control
the middle box's algorithms ?

Roni : No.

Marshall : In the current framework, is there no information about who
the current speaker (in a switched system) actually is ? If you knew
that, picking the last speaker for a PIP is easy.

Roni : No, it is not conveyed. There has been discussion about this.

Brian : I think that people are talking about different use cases.
Could we lay out the different scenarios here?

Mark : The use case document is fairly high level. Perhaps we need
some more technically oriented use case.

Roni : All this discussion is relevant if we first agree that the end
point can request the policy for switching or whatever from the MCU.

Jonathan : I think that there are aspects of A.4 that are relevant
even discounting the policy question.

Brian : The use case I was thinking of did not have these policy issues.

Espen : I think that more technical description would be useful. What
is the minimum information we need to make a sensible choice. Defining
the use case in more detail would be useful.

Mary : In (?) we took the framework and the use cases and hashed them
out in some detail.

Is there a suitable use case in the use case document ?

It would be useful to have one person to take one use case and flesh
it out using the the framework.

Jonathan : One use case could be implemented several ways.

Mary ; That would be an ideal thing to work through in the face to face.

I hope everyone on this call will be at the face to face next week.

Jonathan : Do we know how long various (?)

Mary : We will adjust the agenda based on materials received.

There is a buffer in the afternoon as well.

OK, thanks. See you next week.

Meeting ended
Tue Feb  7 10:57:24 EST 2012