Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt

From: [email-masked]
Date: Tue, 16 Jul 2013 09:29:34 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF.

	Title           : Requirements for Telepresence Multi-Streams
	Author(s)       : Allyn Romanow
                          Stephen Botzko
                          Mary Barnes
	Filename        : draft-ietf-clue-telepresence-requirements-04.txt
	Pages           : 14
	Date            : 2013-07-15

Abstract:
   This memo discusses the requirements for a specification that enables
   telepresence interoperability, by describing the relationship between
   multiple RTP streams.  In addition, the problem statement and
   definitions are also covered herein.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mary Barnes <[email-masked]>
Date: Tue, 16 Jul 2013 15:07:58 -0500

There really were no changes other than to refresh this draft.  I was going
to extend the security section with more detail, but I really can't add
much more detail without referencing things that are defined in the
framework.  So, I think the next step is for me to work with Mark on the
security for the framework.

There are some open issues identified in the appendix of this document
 that we need to figure out whether they are issues that need resolution
for this document.   I will open issues in the tracker and we can discuss
each one and perhaps make some decisions before Berlin.

We also need to consider whether the current framework meets these
requirements.  If some requirements are not met, we need to decide whether
it's because they'll be met by the solution documents or won't be met at
all. In which case, we need to decide whether we actually need them for the
solution.

Regards,
Mary.

On Tue, Jul 16, 2013 at 11:29 AM, <[email-masked]> wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 18 Jul 2013 13:01:00 +1000

Hello Mary,

I did a review of the requirements and Appendix to see if they are met. 
My comments are below. Sorry for the length of the email but I figured 
it would be easier for people to read my comment [CNG] along with the 
requirement.

REQMT-1:The solution MUST support a description of the spatial

arrangement of source video images sent in video streams

which enables a satisfactory reproduction at the receiver

of the original scene.This applies to each site in a

point to point or a multipoint meeting and refers to the

spatial ordering within a site, not to the ordering of

images between sites.

[CNG] Supported – via Capture Area attribute.

Use case point to point symmetric, and all other use cases.

REQMT-1a:The solution MUST support a means of allowing

the preservation of the order of images in the

captured scene.For example, if John is to

Susan's right in the image capture, John is

also to Susan's right in the rendered image.

[CNG] Supported – via Capture Area attribute.

REQMT-1b:The solution MUST support a means of allowing

the preservation of order of images in the

scene in two dimensions - horizontal and

vertical.

[CNG] Supported – via Capture Area attribute.

REQMT-1c:The solution MUST support a means to identify

the point of capture of individual video

captures in three dimensions.

[CNG] Supported – via Point of capture attribute.

REQMT-1d:The solution MUST support a means to identify

the extent of individual video captures in

three dimensions.

[CNG] Partial – Capture area attribute allows the specification of a 
plane of capture in 3 dimensions. However depth of the capture (needed 
for a 3D area) is not supported.

REQMT-2:The solution MUST support a description of the spatial

arrangement of captured source audio sent in audio streams

which enables a satisfactory reproduction at the receiver

in a spatially correct manner.This applies to each site

in a point to point or a multipoint meeting and refers to

the spatial ordering within a site, not the ordering of

channels between sites.

[CNG] Supported – Via Capture Area attribute.

Use case point to point symmetric, and all use cases,

especially heterogeneous.

REQMT-2a:The solution MUST support a means of preserving

the spatial order of audio in the captured

scene.For example, if John sounds as if he is

at Susan's right in the captured audio, John

voice is also placed at Susan's right in the

rendered image.

[CNG] Supported – Via Capture Area attribute.

REQMT-2b:The solution MUST support a means to identify

the number and spatial arrangement of audio

channels including monaural, stereophonic

(2.0), and 3.0 (left, center, right) audio

channels.

[CNG] Partial – the Audio Channel Format attribute currently only 
supports “mono” and “stereo”. It doesn’t support the 3.0 format.

REQMT-2c:The solution MUST NOT preclude the use of

binaural audio.[Edt. This is an outstanding

issue.Text will be changed when the issue is

resolved.]

[CNG] Partial? – Binaural isn’t mentioned in the framework so isn’t 
precluded as such. There is no indication in CLUE recording a binaural 
capture.

REQMT-2d:The solution MUST support a means to identify

the point of capture of individual audio

captures in three dimensions.

[CNG] Supported – via Point of capture attribute.

REQMT-2e:The solution MUST support a means to identify

the extent of individual audio captures in

three dimensions.

[CNG] Partial – The Capture area attribute is based on capturing a plane 
in Cartesian space. There is no depth parameter. Whether the plane 
concept holds for audio like it does video needs further thought.

REQMT-3:The solution MUST support a mechanism to enable a

satisfactory spatial matching between audio and video

streams coming from the same endpoints.

[CNG] Supported - The given that an Advertiser places captures in a 
particular scene it is possible to indicate audio and video streams are 
from the same endpoint.

Use case is point to point symmetric, and all use cases.

REQMT-3a:The solution MUST enable individual audio

streams to be associated with one or more video

image captures, and individual video image

captures to be associated with one or more

audio captures, for the purpose of rendering

proper position.

[CNG] Supported (Partial?) – It is possible to deduce that audio and 
video relate to the same capture area in a scene by analysing the 
Capture Area parameters. It is possible to relate individual audio 
captures to video captures if the Advertisement is constructed in a 
limited way. However its not possible to deduce the relationships 
between individual captures by utilising the Scene, CSE and capture 
concepts. CSE only relate to one media type. So it’s not possible to 
link audio CSEs to video CSEs.

REQMT-3b:The solution MUST enable individual audio

streams to be rendered in any desired spatial

position.

[CNG] Supported? – I think its assumed that a Consumer can do whatever 
it likes with respect to rendering decisions. Ultimately that’s local 
policy.

Edt: Rendering is an open issue. Text will

be changed when it is resolved.]

REQMT-4:The solution MUST enable interoperability between

endpoints that have a different number of similar devices.

For example, one endpoint may have 1 screen, 1 speaker, 1

camera, 1 mic, and another endpoint may have 3 screens, 2

speakers, 3 cameras and 2 mics.Or, in a multi-point

conference, one endpoint may have one screen, another may

have 2 screens and a third may have 3 screens.This

includes endpoints where the number of devices of a given

type is zero.

Use case is asymmetric point to point and multipoint.

[CNG] Supported – CLUE enables different capture capabilities to be 
signalled. It makes no assumption as to the rendering.

REQMT-5:The solution MUST support means of enabling

interoperability between telepresence endpoints where

cameras are of different picture aspect ratios.

[CNG] Supported – CLUE doesn’t describe “aspect ratio” but allows 
different capture areas to be defined. This is a means of describing 
aspect ratio.

REQMT-6:The solution MUST provide scaling information which

enables rendering of a video image at the actual size of

the captured scene.

[CNG] Supported - Capture Area, Capture Point, Point of Line of Capture 
and Scene Scale allow this.

REQMT-7:The solution MUST support means of enabling

interoperability between telepresence endpoints where

displays are of different resolutions.

[CNG] Supported? – CLUE allow encoding parameters to be associated with 
captures which could state the resolution of the captured image. However 
there is no way to indicate “display” resolution. Perhaps the 
requirement needs to be reworded?

REQMT-8:The solution MUST support methods for handling different

bit rates in the same conference.

[CNG] Supported – CLUE allow encoding parameters to be associated with 
captures which could state the bit rate.

REQMT-9:The solution MUST support means of enabling

interoperability between endpoints that send and receive

different numbers of media streams.

Use case heterogeneous and multipoint.

[CNG] Supported – CLUE allows different numbers of captures to be sent.

REQMT-10:The solution MUST make it possible for endpoints without

support for telepresence extensions to participate in a

telepresence session with those that do.

[CNG] Supported – The support of a CLUE channel will be negotiated 
between endpoints. From the current signalling draft it seems a basic 
set of media can be established without CLUE. Endpoints that don’t 
support CLUE obviously won’t be able to determine spatial information etc…

REQMT-11:The solution MUST support a mechanism for determining

whether or not an endpoint or MCU is capable of

telepresence extensions.

[CNG] Supported? – The negotiation of a CLUE channel via SDP is one 
method in the signalling draft. Another indication at the SIP level may 
be beneficial such as a feature tag. This is yet to be documented.

REQMT-12:The solution MUST support a means to enable more than two

sites to participate in a teleconference.

Use case multipoint.

[CNG] Partial – This is on the agenda and there’s basic support i.e. via 
the composed attribute and “scene-switch-policy” CSE attribute. However 
no method is yet defined to keep the source information.

REQMT-13:The solution MUST support both transcoding and switching

approaches to providing multipoint conferences.

[CNG] Supported – CLUE supports these two methods. However further work 
is needed on the details.

REQMT-14:The solution MUST support mechanisms to make possible for

either or both site switching or segment switching.[Edt:

This needs rewording.Deferred until layout discussion is

resolved.]

[CNG] Partial – The “scene-switch-policy” CSE attribute supports this to 
some level but further work is needed in this area.

REQMT-15:The solution MUST support mechanisms for presentations in

such a way that:

*Presentations can have different sources

*Presentations can be seen by all

*There can be variation in placement, number and size of

Presentations

[CNG] Partial – CLUE allows an endpoint whether the capture is related 
to a presentation or not through the use of the presentation attribute. 
The spatial attributes (i.e. capture area) allows the place and size to 
be indicated. The number can be inferred from the number of captures. 
CLUE doesn’t have any policy on who can see the presentations. The CLUE 
Advertisement mechanism may include presentation captures to all people 
within the conference. Perhaps the 2^nd bullet can be removed or 
clarified that its not related to policy?

REQMT-16:The solution MUST include extensibility mechanisms.

[CNG] Supported? – whilst not explicitly documented I think there’s 
general agreement this is needed.

REQMT-17:The solution must support a mechanism for allowing

information about media captures to change during a

conference.

[CNG] Supported? – Keeping the CLUE signalling channel open would allow 
for this and people seem in agreement this should be possible. Further 
detailed work is needed in the signalling draft to describe this. i.e. 
incremental vs full updates. Interaction with bearer signalling (i.e. 
SDP O/A) etc.

REQMT-18:The solution MUST provide a mechanism for the secure

exchange of information about the media captures.

[CNG] Partial? – It is assumed that CLUE will operate over a DTLS/SCTP 
however there’s no documentation regarding CLUE security.

Appendix A. open issues

OPEN-1Binaural Audio [REQMT-2C] The need to support of binaural

audio is unresolved, and the "MUST NOT preclude" language in

this requirement is problematic.The authors believe this

requirement needs to be either changed or withdrawn,

depending on how the issue is resolved.

[CNG] Not supported - This is still unresolved.

OPEN-2Reference to Rendering [REQMT-3b] This is the only

requirement which refers to rendering.It may also be empty,

since receivers can rendering audio captures as they wish.

This is deferred until broader discussion on rendering

requirements is concluded.

[CNG] I think we should frame the requirements with regards to captures 
as that’s the way the framework is written. Perhaps some text to say 
that rendering is based on the receivers local policy.

OPEN-3Conference modes [REQMT-14] This wording of this requirement

is problematic in part because the conference modes (site

switching and segment switching) are not defined.It at

least needs rewording.This is deferred until broader

discussion on layout is concluded.

[CNG] Yes this is still open.

OPEN-4Need to capture requirement that attributes can change at any

time during the call.

[CNG] Yes although it seems REQMT-17 covers this.

OPEN-5Need to add requirement for three dimensions in the right

place

[CNG] Requirements 1d and 2e do capture an aspect of 3D.

OPEN-6Multi-view, is there a requirement needed?

[CNG] Even if there’s no requirement we appear to support it because we 
allow both the capture area and capture point to be sent for captures. 
An Advertiser could describe multiple capture points capturing the same 
area of capture.

Regards, Christian

On 17/07/2013 6:07 AM, Mary Barnes wrote:
> There really were no changes other than to refresh this draft. I was 
> going to extend the security section with more detail, but I really 
> can't add much more detail without referencing things that are defined 
> in the framework. So, I think the next step is for me to work with 
> Mark on the security for the framework.
>
> that we need to figure out whether they are issues that need 
> resolution for this document. I will open issues in the tracker and we 
> can discuss each one and perhaps make some decisions before Berlin.
>
> requirements. If some requirements are not met, we need to decide 
> whether it's because they'll be met by the solution documents or won't 
> be met at all. In which case, we need to decide whether we actually 
> need them for the solution.
>
> Regards,
> Mary.
>
>
> On Tue, Jul 16, 2013 at 11:29 AM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     [email-masked] <mailto:[email-masked]>
>     Internet-Draft
>     <https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>
>     directories: http://www.ietf.org/shadow.html
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: John Leslie <[email-masked]>
Date: Thu, 18 Jul 2013 07:16:02 -0400

Christian Groves <[email-masked]> wrote:
>...
> [CNG] Supported ? Via Capture Area attribute...

   Um... audio isn't two-dimensinal...

> voice is also placed at Susan's right in the

   This REQMT could use some work...

> the extent of individual audio captures in

   (I don't know what that means.)

> [CNG] Partial ? The Capture area attribute is based on capturing a plane 

   It doesn't.

   A microphone can be modeled by a capture point and direction, plus
a sensitivity pattern; but no actual sensitivity pattern resembles a
camera's pattern. Furthermore, no X/Y information survives, but distance
from audio source to the microphone becomes significant (about one
millisecond per foot).

> [CNG] Supported? ? I think its assumed that a Consumer can do whatever 
> it likes with respect to rendering decisions. Ultimately that?s local 
> policy.

   I agree it's local policy.

> [CNG] Not supported - This is still unresolved.

   Binaural audio works fairly well when the listener's head is
stationary. Alas, it won't be.

--
John Leslie <[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jul 2013 10:42:22 -0400

Christian,

You raise a point that has bothered me for some time:

We describe the spatial attributes of a capture by point of capture and 
area of capture (a quadrilateral). Implicitly this describes an 
unbounded pyramid. In reality, it is bounded by the geometry of the room 
and the stuff in it, but we don't have that info. This pyramid may be 
meaningful in some sense for video, though we lack other information 
such as depth of field. But as John replied, I guess it means very 
little for audio.

The fundamental question is: does this provide sufficient information 
for the consumer to properly adapt the received media to his available 
equipment? I don't know the answer to that, but I suspect that it will 
allow some approximation, but probably not enough to do the best 
possible job. Is there more that we ought to be providing to help with 
that job? Or does doing more provide diminishing returns?

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Jul 2013 11:17:05 +1000

Hello John,

Please see my comments below.

Regards, Christian
>     Um... audio isn't two-dimensinal...
[CNG] That's why the "?" is next to "Supported" :-). I agree there's the 
2D issues which I pick up on below.
> from audio source to the microphone becomes significant (about one
[CNG] Could you perhaps propose some attributes (and descriptive text) 
based on direction and sensitivity pattern that you mentioned above? It 
would be good to have something more to discuss.

> stationary. Alas, it won't be.
[CNG] I think the use case that was thought about was participating in a 
telepresence conference via a smart phone whilst wearing headphones. I 
think it was Christer that had that concern.

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Jul 2013 11:23:57 +1000

Hello Paul,

There was a bounding attribute "the scene area" which was removed. As I 
mentioned at the time the idea was to give an indication of how the 
capture areas were located in the room.

With regards to audio I think we need to revisit that with respect to 
the spatial attributes.

Regards, Christian

On 19/07/2013 12:42 AM, Paul Kyzivat wrote:
> We describe the spatial attributes of a capture by point of capture 
> and area of capture (a quadrilateral). Implicitly this describes an 
> unbounded pyramid. In reality, it is bounded by the geometry of the 
> room and the stuff in it, but we don't have that info. This pyramid 
> may be meaningful in some sense for video, though we lack other 
> information such as depth of field. But as John replied, I guess it 
> means very little for audio.
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 23 Jul 2013 13:09:17 -0500

Thanks very much for your detailed review and comments with regards to
whether the REQ is currently supported in the solution.  I have a few
comments below.

Thanks,
Mary
As editor for the Requirements do

On Wed, Jul 17, 2013 at 10:01 PM, Christian Groves <
[email-masked]> wrote:

> Hello Mary,
>
> I did a review of the requirements and Appendix to see if they are met. My
> comments are below. Sorry for the length of the email but I figured it
> would be easier for people to read my comment [CNG] along with the
> requirement.
>
> [CNG] Partial – Capture area attribute allows the specification of a plane
> of capture in 3 dimensions. However depth of the capture (needed for a 3D
> area) is not supported.
>
[MB] Per my comments on open issue 5 from the requirements document (and
Ticket # 41  in the tracker), I was proposing we not require 3D in the
solution at this time.  [/MB]

> [CNG] Partial – the Audio Channel Format attribute currently only supports
> “mono” and “stereo”. It doesn’t support the 3.0 format

[MB] So, my question to the group is do we need to support this in the
current work is is this something that could be extended later. I looked
fairly quickly but I also could not find a use case for 3.0[/MB]

> precluded as such. There is no indication in CLUE recording a binaural

[MB] Yeah, per my comments on Issue 1 (ticket #37) , I propose that we just
delete this requirement. [/MB]

> in Cartesian space. There is no depth parameter. Whether the plane concept
> holds for audio like it does video needs further thought.
>
> [CNG] Supported (Partial?) – It is possible to deduce that audio and video
> relate to the same capture area in a scene by analysing the Capture Area
> parameters. It is possible to relate individual audio captures to video
> captures if the Advertisement is constructed in a limited way. However its
> not possible to deduce the relationships between individual captures by
> utilising the Scene, CSE and capture concepts. CSE only relate to one media
> type. So it’s not possible to link audio CSEs to video CSEs.
>
> [CNG] Supported? – I think its assumed that a Consumer can do whatever it
> likes with respect to rendering decisions. Ultimately that’s local policy.
>
> different capture areas to be defined. This is a means of describing aspect
> ratio.
>
> there is no way to indicate “display” resolution. Perhaps the requirement
> needs to be reworded?
>

[MB] Do you have any suggestions for rewording?  [/MB]

> [CNG] Supported – The support of a CLUE channel will be negotiated between
> endpoints. From the current signalling draft it seems a basic set of media
> can be established without CLUE. Endpoints that don’t support CLUE
> obviously won’t be able to determine spatial information etc…
>
> [CNG] Supported? – The negotiation of a CLUE channel via SDP is one method
> in the signalling draft. Another indication at the SIP level may be
> beneficial such as a feature tag. This is yet to be documented.
>
> the composed attribute and “scene-switch-policy” CSE attribute. However no
> method is yet defined to keep the source information.
>
> [CNG] Supported – CLUE supports these two methods. However further work is
> needed on the details.
>
> [CNG] Partial – CLUE allows an endpoint whether the capture is related to
> a presentation or not through the use of the presentation attribute. The
> spatial attributes (i.e. capture area) allows the place and size to be
> indicated. The number can be inferred from the number of captures. CLUE
> doesn’t have any policy on who can see the presentations. The CLUE
> within the conference. Perhaps the 2^nd bullet can be removed or clarified
> that its not related to policy?
>
[MB] I'm of a mindset to just remove that 2nd bullet. [/MB]

> incremental vs full updates. Interaction with bearer signalling (i.e. SDP
> O/A) etc.
>
[MB] There is an open action item (Ticket #33) for me to work with Mark
with regards to an overview of the security solution required for CLUE.
[/MB]

> [CNG] Not supported - This is still unresolved.
[MB] See my suggestion here:
http://www.ietf.org/mail-archive/web/clue/current/msg02753.html
[/MB]

> [CNG] I think we should frame the requirements with regards to captures as
> that’s the way the framework is written. Perhaps some text to say that
> rendering is based on the receivers local policy.
>

[MB] See my suggestion here:
http://www.ietf.org/mail-archive/web/clue/current/msg02751.html
[/MB]

> [CNG] Yes this is still open.
[MB]  I know the issue is open in the solution. But, I think the
requirements stands, but just needs rewording.  See my suggestion here:
http://www.ietf.org/mail-archive/web/clue/current/msg02750.html
[/MB]

> [CNG] Yes although it seems REQMT-17 covers this.
[MB] That is my thought as well:
http://www.ietf.org/mail-archive/web/clue/current/msg02749.html
[/MB]

> [CNG] Requirements 1d and 2e do capture an aspect of 3D.
[MB] Here's my thoughts on this one:
 http://www.ietf.org/mail-archive/web/clue/current/msg02755.html
 I think it's good that we have some requirements that capture some aspects
and the FW/solution will support those requirements, I'm just not sure it's
a priority to support 3D in the current set of deliverables. [/MB]

> allow both the capture area and capture point to be sent for captures. An
> Advertiser could describe multiple capture points capturing the same area
> of capture.
>
[MB]  I didn't know what multi-view meant:
http://www.ietf.org/mail-archive/web/clue/current/msg02754.html
 However, isn't that functionality supporting other requirements?  So, my
question is do we really need an explicit requirement and if so we need to
be clear what we mean by multi-view (in more general terms. [/MB]

>> going to extend the security section with more detail, but I really can't
>> add much more detail without referencing things that are defined in the
>> that we need to figure out whether they are issues that need resolution for
>> this document. I will open issues in the tracker and we can discuss each
>> one and perhaps make some decisions before Berlin.
>>
>> On Tue, Jul 16, 2013 at 11:29 AM, <[email-masked] <mailto:
>> internet-drafts@ietf.**org <[email-masked]>>> wrote:
>>
>>
>>     Filename : draft-ietf-clue-telepresence-**requirements-04.txt
>>     Pages : 14
>>     Date : 2013-07-15
>>
>>     Abstract:
>>     https://datatracker.ietf.org/**doc/draft-ietf-clue-**
>> telepresence-requirements<https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements>
>>
>>     http://tools.ietf.org/html/**draft-ietf-clue-telepresence-**
>> requirements-04<http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-04>
>>
>>     http://www.ietf.org/rfcdiff?**url2=draft-ietf-clue-**
>> telepresence-requirements-04<http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-04>
>>
>>
>>     ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts/>
>>
>>     ______________________________**_________________
>>     https://www.ietf.org/mailman/**listinfo/i-d-announce<https://www.ietf.org/mailman/listinfo/i-d-announce>
>>     Internet-Draft
>>     <https://www.ietf.org/mailman/**listinfo/i-d-announce%**
>> 0AInternet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>
>> >
>>
>>     directories: http://www.ietf.org/shadow.**html<http://www.ietf.org/shadow.html>
>>     or ftp://ftp.ietf.org/ietf/**1shadow-sites.txt<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>>
>>
>>
>>
>> ______________________________**_________________
>> 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: Mary Barnes <[email-masked]>
Date: Tue, 23 Jul 2013 13:12:08 -0500

I have just one comment below. [MB].

Thanks,
Mary
- as editor of Requirements document

On Thu, Jul 18, 2013 at 8:17 PM, Christian Groves <
[email-masked]> wrote:

>> Christian Groves <[email-masked]**> wrote:
>>

[MB] My suggestion was that since we don't have a use case, I think we
should just remove this requirement.  [/MB]

---

From: John Leslie <[email-masked]>
Date: Tue, 23 Jul 2013 14:40:52 -0400

>> This REQMT could use some work...

   Perhaps I should elaborate:
"spatial order of audio" in largely devoid of meaning. "John voice is
"also placed at Susan's right in the rendered image" is even more
devoid of meaning.

   Perecived position of a voice in rendered audio is not a single-
dimensioned thing. Furthermore, perceived coupling between two images
rendered on different screens is looser than you may think.

   No doubt what was intended was that John's voice should seem to
eminate from the position of John's image as rendered on the screen(s).

   I do not recommend that as a "requirement" either...

> would be good to have something more to discuss.

   I have negative desire to propose any requirement(s) here.

   Nonetheless, perhaps I should elaborate a bit.

   A microphone has a point of capture in three dimensions. This is
worth preserving. The audio it captures has no useful (X,Y) dimensions.
There is a sensitivity pattern; but in most cases it can be ignored.
What can't be ignored is the fall-off in sensitivity with distance and
the increase in latency for a signal to reach it through the air.

   Bottom-line: the point of capture is the only always-significant
feature. The latency becomes significant if you try to pinpoint the
source of the audio captured; but we probably won't do that. (We might,
however, try to blend two microphones, in which case the difference
in latency would _sometimes_ be worth considering.) The reduced audio
level from sources farther away will usually deserve to be ignored.
The desire to keep audio loud enough but not unpleasant is quite
independent of the actual audio level.

>> I agree it's local policy.

   Furthermore, this requires essentially zero support in the protocol.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Jul 2013 17:52:34 -0400

> capture areas were located in the room.

Yeah. But it wasn't sufficient to say much useful for the question I am 
asking below. So it probably made sense to remove it.

More below.

>> You raise a point that has bothered me for some time:

Note: this point wasn't raised to Christian. It is really addressed to 
all the telepresence experts.

>> that job? Or does doing more provide diminishing returns?

I don't have any specific requirement of offer to address it.
I just ask everybody with knowledge of a real telepresence 
implementation: Will you be able to do a satisfactory job of this from 
an arbitrary received advertisement? (Without making further assumptions 
about constraints on the advertiser.)

If the answer is NO, then we should ask what we would need to fix that.
I don't think this calls for any change in requirements, because what I 
am asking is what is called for in requirements #1,2.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 24 Jul 2013 10:21:02 +1000

Hello John,

..snip..

> independent of the actual audio level.
[CNG] So what you're basically proposing is that the "Area of Capture" 
attribute and "Point on capture axis" is changed to be valid only for 
video capture. Audio captures would only have the "Capture point" and 
"Audio Channel" parameters?

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Wed, 24 Jul 2013 12:18:12 +1000

Hello Mary,

Please see my replies below.

Regards, Christian

On 24/07/2013 4:09 AM, Mary Barnes wrote:
>     [CNG] Partial – Capture area attribute allows the specification of
>     a plane of capture in 3 dimensions. However depth of the capture
>     (needed for a 3D area) is not supported.
>
> [MB] Per my comments on open issue 5 from the requirements document 
> (and Ticket # 41  in the tracker), I was proposing we not require 3D 
> in the solution at this time.  [/MB]

[CNG] 3D is also a requirement in the ITU-T Q5/16 work, although like 
CLUE there has been little technical contribution on it. I've sent an 
email to the Q5 list to stimulate input.

>     supports “mono” and “stereo”. It doesn’t support the 3.0 format
>
>
> current work is is this something that could be extended later. I 
> looked fairly quickly but I also could not find a use case for 3.0[/MB]
[CNG] Maybe rather than an enumeration (e.g. mono, stereo) we just make 
this an integer. So rather "Audio Channel Format" we have a "Number of 
audio channels capture" parameter. 1 would indicate single channel (e.g. 
mono), 2 would indicate two channels (e.g. stereo), 5 would indicate 
five channels (e.g. 5.1). At least this is a future proof way so we 
don't have to open up this parameter in the future?

>     [CNG] Partial? – Binaural isn’t mentioned in the framework so
>     isn’t precluded as such. There is no indication in CLUE recording
>     a binaural capture.
>
>
> [MB] Yeah, per my comments on Issue 1 (ticket #37) , I propose that we 
> just delete this requirement. [/MB]

[CNG] I believe this is Christer's requirement. I don't have a strong 
preference either way.

>     [CNG] Supported? – CLUE allow encoding parameters to be associated
>     with captures which could state the resolution of the captured
>     image. However there is no way to indicate “display” resolution.
>     Perhaps the requirement needs to be reworded?
>
>

[CNG] The solution MUST support a means for an endpoint to indicate it's 
supported video capture and encoding parameters. A receiving endpoint 
may use this information to determine which which video it requires.

>     [CNG] Partial – CLUE allows an endpoint whether the capture is
>     related to a presentation or not through the use of the
>     presentation attribute. The spatial attributes (i.e. capture area)
>     allows the place and size to be indicated. The number can be
>     inferred from the number of captures. CLUE doesn’t have any policy
>     on who can see the presentations. The CLUE Advertisement mechanism
>     may include presentation captures to all people within the
>     conference. Perhaps the 2^nd bullet can be removed or clarified

[CNG] I'm ok with removing it.
..snip

---

From: Mary Barnes <[email-masked]>
Date: Wed, 24 Jul 2013 19:02:32 -0500

Hi Christian,

Additional responses below [MB2].

Thanks,
Mary.

On Tue, Jul 23, 2013 at 9:18 PM, Christian Groves <
[email-masked]> wrote:

> [CNG] 3D is also a requirement in the ITU-T Q5/16 work, although like CLUE
> there has been little technical contribution on it. I've sent an email to
> the Q5 list to stimulate input.

[MB2] Per my separate email on this issue, I think the issue is closed as
there were requirements added specific to 3D:
http://www.ietf.org/mail-archive/web/clue/current/msg02763.html
I think the proposal/changes made to address the issue are sufficient.
[MB2]

> mono), 2 would indicate two channels (e.g. stereo), 5 would indicate five
> channels (e.g. 5.1). At least this is a future proof way so we don't have
> to open up this parameter in the future?

[MB2] I think I agree with you.  If I understand your proposal, the
solution needs to support a number of audio channels.  So, we would be okay
with this requirement standing since the solution would provide the "means
to identify", although the functionality may not necessarily support.  Is
that correct? [/MB2]

> supported video capture and encoding parameters. A receiving endpoint may
> use this information to determine which which video it requires.
>
[MB2] I like that. [/MB2]

---

From: Christian Groves <[email-masked]>
Date: Thu, 25 Jul 2013 10:17:44 +1000

Hello Mary,

Please see below.

Regards, Christian

>         [MB] So, my question to the group is do we need to support
>         this in the current work is is this something that could be
>         extended later. I looked fairly quickly but I also could not
>         find a use case for 3.0[/MB]
>
>     [CNG] Maybe rather than an enumeration (e.g. mono, stereo) we just
>     make this an integer. So rather "Audio Channel Format" we have a
>     "Number of audio channels capture" parameter. 1 would indicate
>     single channel (e.g. mono), 2 would indicate two channels (e.g.
>     stereo), 5 would indicate five channels (e.g. 5.1). At least this
>     is a future proof way so we don't have to open up this parameter
>     in the future?
>
> solution needs to support a number of audio channels.  So, we would be 
> okay with this requirement standing since the solution would provide 
> the "means to identify", although the functionality may not 
> necessarily support.  Is that correct? [/MB2]
[CNG] Yes although I'm not sure what the significance of "since the 
solution would provide the "means to identify", although the 
functionality may not necessarily support" is? Like all the 
attributes/values a endpoint isn't required to support them.

---

From: John Leslie <[email-masked]>
Date: Thu, 25 Jul 2013 16:04:44 -0400

Christian Groves <[email-masked]> wrote:
> To: John Leslie <[email-masked]>
>>

   I don't know if I want to go so far as "proposing," but

- "Area of Capture" makes no sense to me for audio.

- "Point on capture axis" makes no sense to me unless there is also a
  "sensitivity pattern".

   I don't expect folks to use sensitivity patters within the next year
or two.

   The current case is using an aimed shotgun to capture an individual
with a question from the audience. For that use, I expect folks to mix
it into a surround-sound presentation without specifying how they
derived it.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 16:16:14 -0400

I am commenting from the perspective of somebody who knows nothing 
special about audio...

> - "Area of Capture" makes no sense to me for audio.

That has troubled me for some time. Glad to hear it isn't just me.

> - "Point on capture axis" makes no sense to me unless there is also a

I guess there are omnidirectional mics where axis of capture makes no 
sense. But in my naive view I would think that most mics have some 
directional sensitivity and that knowing the axis would be "better than 
nothing".

> it into a surround-sound presentation without specifying how they

ISTM that we need to provide *something* that will help the consumer to 
decide which audio captures to choose if it can't choose them all, and 
how to assign them to the speakers it has. I don't know what that 
something is.

The one advantage of area of capture for audio is that if you pick a 
particular video capture then you might want to look for an audio 
capture that covers that area. Axis of capture might also be used as a 
hint in the same way. But I realize that is naive.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Jul 2013 20:28:08 +0000

Hi,

I had a discussion about this with some of my colleagues just before summer, and there might be a need for area of capture also for audio.

I'll get back to this when people come back from their summer vacation.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [[email-masked]]
To: [email-masked] [[email-masked]]
Subject: Re: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-04.txt

        Thanks,
        Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 25 Jul 2013 13:46:29 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Thursday, July 25, 2013 4:16 PM
> To: [email-masked]

[Duckworth, Mark] Me too.

..snip..

> The one advantage of area of capture for audio is that if you pick a particular
> video capture then you might want to look for an audio capture that covers
> that area. Axis of capture might also be used as a hint in the same way. But I
> realize that is naive.

[Duckworth, Mark] Yes, that was part of the original motivation for using area of capture for any media capture, not just video.  Also we expected this information to be useful for rendering, so the renderer could use this area information to mix received audio encodings into its loudspeakers in a spatially meaningful way.  The simple use case for this is for TIP-like multi-channel audio, where there is a left, center, and right channel that are separately available and separately switchable.  It seems to me area of capture and/or axis of capture is still useful for this limited purpose.

Mark

---

From: John Leslie <[email-masked]>
Date: Thu, 25 Jul 2013 18:35:20 -0400

> I am commenting from the perspective of somebody who knows nothing 

   Fundamentally, audio is pressure-changes in the air itself. These
propagate (at the speed of sound) in every direction and reflect off
most surfaces.

> sense.

   Not so. There is a "generic omnidirectional" sensitivity pattern
which has a definite axis of capture; but it is _not_ equal in every
direction.

> But in my naive view I would think that most mics have some directional
> sensitivity and that knowing the axis would be "better than nothing".

   Indeed, all microphones have directional sensitivity. "Generic
cardioad" is a more pronounced pattern than "generic omnidirectional;"
but they both are optimized for best fidelity on the axis of capture.

>> I don't expect folks to use sensitivity patterns within the next year
>> or two.

   Using "generic omni" and "generic cardioid" would be a good thing:
I merely don't expect it. The difference is nowhere nearly as great as
folks think it is.

> how to assign them to the speakers it has. I don't know what that 

   There _should_ be a "room mix" to gather "everything in the room".
This may be monaural, stereo, or surround; and adapting from one of
these to another is straightforward.

> capture that covers that area.

   Alas, there is no standard way to specify "area" covered by a
microphone. Unless we can define one, any such parameter would be
less than useful.

> Axis of capture might also be used as a hint in the same way. But I
> realize that is naive.

   It, at least, has a meaning. In point of fact, nearest point-of-
capture is your best bet -- even if the mike in question is cardioid
and you're >90 degrees off-axis.

   If you really care about this, I strongly recommend keeping
"point on axis of capture" and adding "sensitivity pattern" -- at
least "generic omni" and "generic cardioid".

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 18:48:58 -0400

To cut to the chase...

I think John should make a proposal for what we ought to have in the fw 
& data model for this, that will be "enough" without going overboard. I 
don't sense that anybody else here is competent to make this call.

	Thanks,
	Paul (as co-chair)

---

From: John Leslie <[email-masked]>
Date: Thu, 25 Jul 2013 18:50:51 -0400

Duckworth, Mark <[email-masked]> wrote:
> 
> ... that was part of the original motivation for using area of
> capture for any media capture, not just video. Also we expected this
> information to be useful for rendering, so the renderer could use
> this area information to mix received audio encodings into its
> loudspeakers in a spatially meaningful way.

   _Somebody's_ hands are waving here...

   When mixing audio, you aim for a limited number of sources; and
aim for a constant apparent room acoustic. The video can jump around
quite a bit; but the audio needs to "feel" constant. In a dialogue,
the two actors are "placed" in positions and _stay_there_ as far as
the audio is concerned. Either or both actors may be shown by any
number of cameras (some moving) without dis-orienting the audience;
but if the audio tries to "follow" the cameras (whatever that might
mean) the audience gets confused.

> The simple use case for this is for TIP-like multi-channel audio,
> where there is a left, center, and right channel that are separately
> available and separately switchable.

   I advise _great_ care in "switching". Done too frequently, the
audience won't be able to follow it.

> It seems to me area of capture and/or axis of capture is still
> useful for this limited purpose.

   Axis of capture can be useful, but excessive switching will still
confuse the audience. Professionals try to depend on a mike as close
as possible to the speaker; then _mix_ that into the multi-channel
audio in a way to keep the apparent location constant.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Jul 2013 20:23:11 -0400

John,

If we are doing site switching based on voice activity, then surely we 
must switch the audio to match, right?

I guess what you are saying might pertain if we are switching among 
cameras in a single room.

	Thanks,
	Paul

---

From: John Leslie <[email-masked]>
Date: Mon, 29 Jul 2013 00:51:38 -0400

> don't sense that anybody else here is competent to make this call.

   Well, you asked... "Be careful what you ask for..."

   I see three different kinds of audio

- microphones;
- microphone sets; and
- mixes.

   A microphone is simply a transducer, with gain "fixed" for the
duration of its use. Its characteristics include

- capture point;
- point on axis of capture; and
- sensitivity pattern.

   The first two are where it's placed and where it's "pointing".
The third is a sensitivity graph. For starters we should have three
pre-defined graphs:

- generic omni;
- generic cardioid; and
- unknown.

   There will eventually be others, e.g. "shotgun", and we should allow
for accurate graphs for specific microphones; but I don't propose any
more at this time.

   A microphone set is a collection of transducers in a fixed arrangement.
The common case right now is "XY stereo" which is two transducers at
90-degrees to each other. Each transducer has its own characteristics
and its own audio stream; but it will be set up as a single unit with:

- capture point;
- point on axis of capture; and
- list of individual transducers with offsets.

   A "mix" is a managed combination of sound sources (which can no longer
be individually identified). The gain of each can be varied at any time,
without warning or even notice of change. Mixes should be given human-
readable names, and should also have a machine-readable tag. Initially,
that tag should cover:

- room mix; and
- presentation mix.

   More will follow eventually, but I see no reason to discuss those now.

   The output of a mix will be one or more audio streams, specifically
we should expect:

- mono;
- stereo; and
- surround.

====

   Discussion, IMHO, should be on the list.

   I will not be in Berlin; but I will be following today's session
via MeetEcho. I can type fast enough to answer questions in jabber,
should you have any...

---

From: Paul Coverdale <[email-masked]>
Date: Mon, 29 Jul 2013 08:53:06 +0200

It's a while I was formally involved in the electro-acoustics world, but
this proposal makes sense to me.

...Paul

>John Leslie
>Sent: Monday, July 29, 2013 6:52 AM
>To: Paul Kyzivat
>Cc: [email-masked]
>Subject: [clue] Data Model for audio
>
>> I think John should make a proposal for what we ought to have in the
>> fw & data model for this, that will be "enough" without going
>> overboard. I don't sense that anybody else here is competent to make
>this call.
>
>The third is a sensitivity graph. For starters we should have three pre-
>defined graphs:
>
>- generic omni;
>- generic cardioid; and
>- unknown.
>
>The common case right now is "XY stereo" which is two transducers at 90-
>degrees to each other. Each transducer has its own characteristics and
>its own audio stream; but it will be set up as a single unit with:
>
>- capture point;
>   A "mix" is a managed combination of sound sources (which can no
>longer be individually identified). The gain of each can be varied at
>any time, without warning or even notice of change. Mixes should be
>given human- readable names, and should also have a machine-readable
>tag. Initially, that tag should cover:
>
>- room mix; and
>- presentation mix.
>
>   I will not be in Berlin; but I will be following today's session via
>MeetEcho. I can type fast enough to answer questions in jabber, should
>you have any...
>
>--

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 29 Jul 2013 09:19:51 +0200

+1 from my side. We had this kind of stuff in the data model (based on one of the first e-mails on this subject from John) before and unfortunately we were forced to remove it in order to get aligned with the framework. I will propose today to put such information both in the former (framework) and in the latter (data model) documents.

Simon

>> MeetEcho. I can type fast enough to answer questions in jabber, should

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Mon, 29 Jul 2013 08:03:48 +0000

Together with the framework and data model suggestion we should also do detailed use cases to have common understanding of what we want to achieve with an extended audio model within CLUE. Without clear use cases it is hard to discuss the extensions  and how they can be applied to real-life use cases.

It is not clear to me how much of the capture information I need to play out audio, so I need examples to be able to review the suggestions.

Regards

-Espen

From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Pietro Romano
Sent: 29. juli 2013 09:20
To: Paul Coverdale
Cc: [email-masked]
Subject: Re: [clue] Data Model for audio

Simon

...Paul

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
John Leslie
Sent: Monday, July 29, 2013 6:52 AM
To: Paul Kyzivat
Cc: [email-masked]<mailto:[email-masked]>
Subject: [clue] Data Model for audio

Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

- microphones;
- microphone sets; and
- mixes.

- capture point;

- generic omni;
- generic cardioid; and
- unknown.

 A microphone set is a collection of transducers in a fixed
arrangement.
The common case right now is "XY stereo" which is two transducers at 90-
degrees to each other. Each transducer has its own characteristics and
its own audio stream; but it will be set up as a single unit with:

- capture point;

- room mix; and
- presentation mix.

 More will follow eventually, but I see no reason to discuss those
now.

- mono;
- stereo; and
- surround.

====

--
John Leslie <[email-masked]<mailto:[email-masked]>>
_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue

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

                                                                         _\\|//_
                                                              ( O-O )
                                           e-mail: [email-masked]<mailto:[email-masked]>

---

From: Paul Coverdale <[email-masked]>
Date: Mon, 29 Jul 2013 10:39:22 +0200

I don’t understand why we need to get into detailed use cases for “extended
audio”. The proposal seems pretty fundamental to me.  How many microphones
does a provider have, where are they located and what is their directivity
pattern (if any).

...Paul

From: Espen Berger (espeberg) [mailto:[email-masked]] 
Sent: Monday, July 29, 2013 10:04 AM
To: Simon Pietro Romano; Paul Coverdale
Cc: [email-masked]
Subject: RE: [clue] Data Model for audio

Together with the framework and data model suggestion we should also do
detailed use cases to have common understanding of what we want to achieve
with an extended audio model within CLUE. Without clear use cases it is hard
to discuss the extensions  and how they can be applied to real-life use
cases. 

It is not clear to me how much of the capture information I need to play out
audio, so I need examples to be able to review the suggestions.  

Regards

-Espen 

+1 from my side. We had this kind of stuff in the data model (based on one
of the first e-mails on this subject from John) before and unfortunately we
were forced to remove it in order to get aligned with the framework. I will
propose today to put such information both in the former (framework) and in
the latter (data model) documents.

Simon

...Paul

-----Original Message-----

John Leslie

To: Paul Kyzivat

Cc: [email-masked]

this call.

- microphones;

- microphone sets; and

- mixes.

- capture point;

- sensitivity pattern.

defined graphs:

- generic omni;

- generic cardioid; and

- unknown.

more at this time.

arrangement.

- capture point;

- room mix; and

- presentation mix.

now.

we should expect:

- mono;

- stereo; and

- surround.

====

you have any...

--

clue mailing list

[email-masked]

 
_\\|//_

                                                              ( O-O )

                                                        Simon Pietro Romano

                                                Universita' di Napoli
Federico II

                       <<Molti mi dicono che lo scoraggiamento Ë l'alibi
degli 

                       idioti. Ci rifletto un istante; e mi scoraggio>>.
Magritte.

                                                           oooO

                                                                \ (
(   )

                                                              \_)          )
/

                                                                       (_/

---

From: John Leslie <[email-masked]>
Date: Mon, 29 Jul 2013 05:41:08 -0400

Espen Berger (espeberg) <[email-masked]> wrote:
> 
> Together with the framework and data model suggestion we should also
> do detailed use cases to have common understanding of what we want to
> achieve with an extended audio model within CLUE.

   I'm not unwilling to do this, although I can't tackle it today and
may not be able to do so anytime this week.

> Without clear use cases it is hard to discuss the extensions and how
> they can be applied to real-life use cases.

   What I proposed is describing what microphones and mixes _are_. I
don't see how use-cases have anything to do with that.

> It is not clear to me how much of the capture information I need to
> play out audio, so I need examples to be able to review the suggestions.

   You don't need _any_ of this information to play an audio stream.
OTOH, it's easy to imagine potential uses where this information would
inform the process of making an _effective_ audio environment.

   We should not (IMHO) prevent such an outcome based upon how many of
us want to do this right away.

   (I will be mostly off-Net until Tuesday morning.)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Jul 2013 22:32:41 +0200

>     Well, you asked... "Be careful what you ask for..."

I don't understand the details, but I get the gist.
It sounds "plausible" to me. Here are some dumb questions:

IIUC, when describing audio for a scene, it might make sense to have one 
CSE that contains one or more microphones and/or microphone sets, and 
one or more additional CSEs that contain mixes. Is that right?

If a microphone set consists of several audio streams, then doesn't that 
mean it must be multiple captures? But if it has a single description, 
currently the only place we have to put that is on a CSE. That in turn 
means that if a CSE contains a microphone set, then all the captures in 
it must be part of the same microphone set. So then we couldn't have a 
CSE that had multiple microphone sets, or one set and some individual 
microphones or mixes. Maybe that's ok - I'm not sure. If not, then we 
may need some other aggregate mechanism to describe a microphone set.

	Thanks,
	Paul

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Tue, 30 Jul 2013 16:27:00 +0000

Hi John 

A do understand that describing the audio environment is useful. My request is to add some examples and guiding on how the information should be used to be useful to a media receiver. 

As an example a receiver of a single audio stream does not need to know if the original audio pickup is done by a single microphone or by mixing two microphones together.  It is common to have two (or more) microphone in the same room to have proper microphone pickup in large rooms and send a mixed audio stream from the room.   In other cases you use multiple microphones to do spatial audio, so it depends on the room setup. 

Is the audio model meant to describe physical or logical aspect of the audio setup? Or better, make it flexible to allow the media provider to choose what to describe. 

I look forward to see a concrete proposal for an audio model.  

Regards 

-Espen 

-----Original Message-----
From: John Leslie [mailto:[email-masked]] 
Sent: 29. juli 2013 11:41
To: Espen Berger (espeberg)
Cc: [email-masked]
Subject: Re: [clue] Data Model for audio

> achieve with an extended audio model within CLUE.

   I'm not unwilling to do this, although I can't tackle it today and may not be able to do so anytime this week.

> they can be applied to real-life use cases.

   What I proposed is describing what microphones and mixes _are_. I don't see how use-cases have anything to do with that.

   You don't need _any_ of this information to play an audio stream.
OTOH, it's easy to imagine potential uses where this information would inform the process of making an _effective_ audio environment.

   We should not (IMHO) prevent such an outcome based upon how many of us want to do this right away.