Subject: [clue] Minutes: Design Team Meeting - Jan. 31, 2012

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Feb 2012 17:30:43 -0500

Clueful,

Below, please find the minutes from the design team meeting held on
Jan 31th, 2012.   The minutes will be posted to the wiki.  Thanks to
John Leslie for taking notes.

Regards,
Paul

============================================

CLUE WG Design Team Call   January 31, 2012
Chairs: Mary Barnes, Paul Kyzivat

* Attendees:

Mary Barnes
Paul Kyzivat
Allyn Romanow
Andy Pepperell
Brian Baldino
John Leslie
Jonathan Lennox
Mark Duckworth
Rob Hansen
Roni Even
Stephan Wenger

* Summary:

Folks agree the general approach of conveying VAD info in audio streams, 
but there are a lot of details to be worked out.

* Summary of action items:

- The approach needs to be aligned with the coordinate system.

- How to efficiently implement the conveyance of speaker location 
information

_____________________
Notes by John Leslie:

John Leslie, Paul Kyzivat, Roni Even, Stephan Wenger, Rob Hansen, Mark 
Duckworth, Brian Baldino, Allyn Romanow, Andy Pepperell, Mary @ 1004

Mary: talk about A5... Voice Activity Detection, should it me mandatory?
Andy: if mandatory, stops need for everything to be decoded
Brian: for switched case, we want some way to avoid need to calculate 
this... segment-switching...
Mark: agree general approach sounds good... details left to be worked 
out, question for Andy, list of active linear positions
Andy: talking about linear position rather than XYZ, three video 
streams, single pre-mixed audio. Levels mandatory
Roni: position of microphone, people? not sure
Mark: video captures would have an area of capture attribute, if two 
captures not of same area, audio stream could have coordinate associated 
with one of those video captures, receiver could tell which video 
capture would be associated with audio
Roni: this information is not changing the relation
Mark: VAD information is dynamic: could be different for each packet. 
There is an area of capture which is not dynamic. XYZ position with 
audio is an additional parameter, sender has more control over what 
portion of the scene is active
Rob: how is this different
Andy: you might have only a single audio and single video, you can 
influence the active region... more fine-grained
Roni: mandatory means every ?? needs to support it
Andy: one way is to say consumer always tells supplier which 
algorithm... issue of consistent VAD information. Making it mandatory 
ensures able to handle. Flip side is that conference may be talking to 
non-clue devices
Roni: just say, coming from...
Andy: also identifies loudest of many calls
Roni: with one audio, one video, no way to say who's speaking... we need 
the spatial...
Brian: for endpoints with only one video, but audio with directional 
capability, do we get directional information
Roni: there is a way to provide (from mixer?), but linear position not there
??: any clue-compliant system should be sending those levels; separate 
question from whether there needs to be a way of associating audio with 
video captures
Andy: VAD out needs to be consistens; whether it's mandatory, 
coordinates should be optional... decouple # audio streams from # video 
streams
??: currently, you send level in dB... additional bit which says ??
??: energy level is the wrong measure... not sure we need to show where 
the audio is coming from... that's hard; do we need actual spatial
Andy?: video streams may be different shapes... sub-scenes...
??: concerned that determining audio position is difficult
Andy: selection of microphones... press a button...
Roni: use case? ... be consistent with the naming. not an exact position
Brian: could be specific location of a speaker
Allyn: have we been recording this conference?
Mary: starting recording now (1031)
Roni: summarize, good idea to have that, not sure what "mandatory part" is
Mark: if we're talking about sending location with every packet, is that 
overhead excessive
Roni: thought we were talking about (non-coordinate) position
Brian: think we can come up with a shorter way of describing the area
Andy: send only where change; e.g. energy level all the time, position 
in different header
Rob: (inaudible)
Mary: I was kicked off the hotel network
Allyn: discussing ways to achieve this, not clear which way most efficient
Mary: we'll open an issue in tracker -- how to efficiently implement
Rob: might be good to split the VAD stuff
Roni: this is not part of the protocol, didn't hear ??
Rob?: how tightly coupled? ideally in same coordinate system
Allyn: would it be good to flesh out the details in the framework document
Roni: think Ron's point, talked of how to coordinate among media 
streams, don't know how or when we'll discuss it
Allyn: develop solution further in the framework document -- just needs 
to be somewhere.
Mary: framework is defining the overall functionality
Roni: if we say something needs to be supported, which protocol remains open
Mary: guys need to figure out where to fold this in
Mark: that's OK
Mary: are we done with this topic
Allyn: should we bring up topic of composition
Mary: does somebody have something to clarify discussion
Stephan: ...
Mary: I think we're done for today
1044 adjourn

______________________
Notes by Paul Kyzivat:

Attendees:
Mary Barnes
Paul Kyzivat
Allyn Romanow
Andy Pepperell
Brian Baldino
John Leslie
Jonathan Lennox
Mark Duckworth
Rob Hansen
Roni Even
Stephan Wenger

John Leslie will take notes.

Subject is section A.5 of framework: VAD - voice activity detection.

Andy:

Mark: agree general approach is ok, details to work out.

Andy/Mark: this needs to be updated to include spacial coordinate that 
can be related to the streams.

Roni: does this mean you want to have the position of the microphone, or 
the people, or what?

Mark: e.g. if there are multiple video streams and only one audio 
stream, then the audio stream could have info about speaker location 
that can be correlated to a video stream. This could be different for 
each audio packet.

Andy: level associated with the capture set should always be sent. 
Coordinates should be optional.

Andy and Jonathan discussed value and issues with coordinates.

Mark asks how much data is needed in each packet to carry coordinates.

Roni: didn't think we were sending coordinates - just some sort of 
position info.

Brian: we should be able to find something more compact than coordinates.

Andy: could send energy level all the time, and send location info only 
when it changes.

Mary: we should open an issue about how to efficiently implement this. 
There is question about how much of this needs to be in the framework.

Rob said something, but couldn't understand what it was. (Bad audio from 
Rob.)