Subject: [clue] Stephan's comments on Requirements-03

From: Stephan Wenger <[email-masked]>
Date: Mon, 20 Jun 2011 07:48:14 -0700

Hi,
Due to other commitments, I have not followed the mailing list in detail.
Some of my comments may be duplicates; apologies in advance for that.
Overall, this draft is better than the previous ones.  However, there are
still a number of issues that I would like to raise.

Req.1 "preservation order"???  What is this?  Needs to be definedŠ
Req.1c "aspect ratio" -> "picture aspect ratio", to distinguish from pixel
aspect ratio (both terms are common in video compression)
Req.1d "as described in the use cases": I don't like this type of cross
reference, but have not had time to come up with a good solution.

Req.2a "order of audio" -> "spatial order of audio"
Req.2b MUST for the 3.0?  Suggest "SHOULD".  Also suggest "SHOULD 5.1", as
5.1, while not common in today's systems, has appeared on at least one
Telepresence roadmap I'm aware of.
Req.2c Personally, I don't care about binaural support either way; however,
MUST NOT seems wrong here.  I think requirements should be expressed
positively, with the appropriate level of mandation.  So why not "MAY"
support binaural?  Or "SHOULD"?

Req 3a fine with me as written.  However, have you thought about the
implications when considering centralized mixing?  In order to fulfill the
use cases behind the requirements, the mixer needs to be aware of both
capture info and rendering infoŠ  Not an issue for me, but there may be IPR
implications, and I would prefer to see a "SHOULD" level of mandation for
the centralized audio mixing use case (only).
Req. 3b this requirement needs to be rephrased.  We should not put
requirements on the renderer.  "The solution MUST enable individual audio
streams that have no camera position associated with"?  Or something to this
extent?

Req 4.  Convert edt. note into regular text; it contains helpful info.

Req. 5 fine

Req 6 aspect ratio -> picture aspect ratio.  Or do you also want to worry
about pixel aspect ratios?  Now that would be fun for the implementers :-)

Req 7 fine, but since we should not specify rendering, this requirement is a
No-Op, right?

Req 8 fine

Req 9 fine

Req 10 needs IMO to be more general.  "different bit rates"  -> "endpoints
with different connectivity, i.e. in terms of bitrate, packet loss rate, and
other connectivity aspects"

Req 11 fine.  Perhaps add a note indicating that, obviously, dumb endpoints
cannot take advantage of solution features unless an MCU or gateway is in
play which deals with those solution features.

Req 12 fine

Req 13 Is anywhere here advocating switching???  Can we please rid ourselves
from concepts 10+ years out of date?

Req 14  I don't understand this requirement.  Needs elaboration and/or an
example

Req 15 What is "audio activity"?  And, suggest moving this requirement up to
where the other audio requirements are

Req 16, third bullet, language is garbled.  Suggest to spell out those
assorted requirements.

Req 17 fine

Stephan

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 22 Jun 2011 13:21:03 -0700

Hi Stephan,

Thanks for the great comments... for finding the time to go over the doc
carefully-

These are roughly from both Steve and myself.

Allyn

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephan Wenger
Sent: Monday, June 20, 2011 7:48 AM
To: [email-masked]
Subject: [clue] Stephan's comments on Requirements-03

Hi,

Due to other commitments, I have not followed the mailing list in
detail.  Some of my comments may be duplicates; apologies in advance for
that.

Overall, this draft is better than the previous ones.  However, there
are still a number of issues that I would like to raise.

Req.1 "preservation order"???  What is this?  Needs to be defined...

It's a typo - It was meant to be allowing the preservation of order of
images - does that make more sense to you? There follows a simple
example in case it is not clear.

Req.1c "aspect ratio" -> "picture aspect ratio", to distinguish from
pixel aspect ratio (both terms are common in video compression)

1c was removed.

Agree. How is this modest change?

The solution MUST support a means to communicate information allowing
multi-view.

Use case virtual space (multi-view).

ok

Req.2b MUST for the 3.0?  Suggest "SHOULD".  Also suggest "SHOULD 5.1",
as 5.1, while not common in today's systems, has appeared on at least
one Telepresence roadmap I'm aware of.

Let's discuss

Req.2c Personally, I don't care about binaural support either way;
however, MUST NOT seems wrong here.  I think requirements should be
expressed positively, with the appropriate level of mandation.  So why
not "MAY" support binaural?  Or "SHOULD"?

Yes - this whole issue is under discussion.

Req 3a fine with me as written.  However, have you thought about the
implications when considering centralized mixing?  In order to fulfill
the use cases behind the requirements, the mixer needs to be aware of
both capture info and rendering info...  Not an issue for me, but there
may be IPR implications, and I would prefer to see a "SHOULD" level of
mandation for the centralized audio mixing use case (only).

I don't see this, let's discuss

Req. 3b this requirement needs to be rephrased.  We should not put
requirements on the renderer.  "The solution MUST enable individual
audio streams that have no camera position associated with"?  Or
something to this extent?

Yes, I agree with you. Steve suggests we discuss further.

done

Req. 5 fine

We can remove this now that the editor's note in 4 mentions the zero
case, right?

Req 6 aspect ratio -> picture aspect ratio.  Or do you also want to
worry about pixel aspect ratios?  Now that would be fun for the
implementers :-)

Req 7 fine, but since we should not specify rendering, this requirement
is a No-Op, right?

Steve would like to discuss

Req 8 fine

Req 9 fine

Req 10 needs IMO to be more general.  "different bit rates"  ->
"endpoints with different connectivity, i.e. in terms of bitrate, packet
loss rate, and other connectivity aspects"  

Ok. Would prefer a specific list rather than broad phrase open to
interpretation.

Req 11 fine.  Perhaps add a note indicating that, obviously, dumb
endpoints cannot take advantage of solution features unless an MCU or
gateway is in play which deals with those solution features.

Don't really feel it's necessary. But don't feel very strongly.

Req 12 fine

Req 13 Is anywhere here advocating switching???  Can we please rid
ourselves from concepts 10+ years out of date?

Maybe I'm not clear on what you mean, since as you know some current
systems use switching rather than transcoding. But, if you mean this is
an unnecessary requirement, and multipoint is understood, I don't mind
removing the reqmt.

Req 14  I don't understand this requirement.  Needs elaboration and/or
an example

Okay, agree

Req 15 What is "audio activity"?  And, suggest moving this requirement
up to where the other audio requirements are

Okay, will define audio activity. It's more about what video to show
than audio, so suggest leaving where it is.

I think 3 is redundant with 4, so would like to remove

Req 17 fine

Stephan

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 22 Jun 2011 17:01:51 -0400

HI Stephan -

To clarify the 3b comment:  For me statements like "The solution MUST enable
individual audio streams to be rendered in any desired spatial position" do
not put *any* requirements on the renderer.  Req 3b says the solution must *
enable* receivers to do this (e.g., provide any needed information).  But it
does not say that receivers have to do anything.  So I see no reason to
spend time rewording it.

On Req 7:  I think I already posted a comment on requirement 7, suggesting
that this might have been part of a larger requirement on the need to enable
display "at the proper size at the apparent distance".  That is,
telepresence systems today can display people at their true size, and I
think there is a requirement to provide the appropriate scale information
for that.  This larger requirement has possibly gotten lost, if so we should
circle back and re-capture it.

It does look like a no-op as currently drafted - not because it touches on
rendering, but because I cannot think of any way to prevent different size
displays from working, no matter what you do in the protocol.

Regards
Stephen Botzko

On Wed, Jun 22, 2011 at 4:21 PM, Allyn Romanow (allyn) <[email-masked]>wrote:

>  Hi Stephan,****
>
> Thanks for the great comments… for finding the time to go over the doc
> carefully-****
>
> ** **
>
> These are roughly from both Steve and myself.****
>
> ** **
>
> Allyn****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Stephan Wenger
> *Sent:* Monday, June 20, 2011 7:48 AM
> *To:* [email-masked]
> *Subject:* [clue] Stephan's comments on Requirements-03****
>
> ** **
>
> Hi,****
>
>  Some of my comments may be duplicates; apologies in advance for that.****
>
> still a number of issues that I would like to raise.****
>
> ** **
>
> Req.1 "preservation order"???  What is this?  Needs to be defined…****
>
> It’s a typo – It was meant to be allowing the preservation of order of
> images – does that make more sense to you? There follows a simple example in
> case it is not clear.****
>
> ** **
>
> aspect ratio (both terms are common in video compression)****
>
> 1c was removed.****
>
> ** **
>
> reference, but have not had time to come up with a good solution.****
>
> Agree. How is this modest change?****
>
> multi-view.****
> Use case virtual space (multi-view).****
>
> ** **
>
> ** **
>
> Req.2a "order of audio" -> "spatial order of audio"****
>
> ok****
>
> Telepresence roadmap I'm aware of.****
>
> ** **
>
> Let’s discuss****
>
> ** **
>
> support binaural?  Or "SHOULD"?****
>
> Yes – this whole issue is under discussion.****
>
> ** **
>
> capture info and rendering info…  Not an issue for me, but there may be IPR
> the centralized audio mixing use case (only).****
>
> I don’t see this, let’s discuss****
>
> ** **
>
> extent?****
> Yes, I agree with you. Steve suggests we discuss further.****
>
> ** **
>
> Req 4.  Convert edt. note into regular text; it contains helpful info.****
>
> done****
>
> ** **
>
> Req. 5 fine****
>
> We can remove this now that the editor’s note in 4 mentions the zero case,
> right?****
>
> ** **
>
> ****
> ** **
> Req 7 fine, but since we should not specify rendering, this requirement is
> a No-Op, right?****
>
> Steve would like to discuss****
>
> ** **
>
> Req 8 fine****
>
> ** **
>
> Req 9 fine****
>
> ** **
>
> other connectivity aspects"  ****
>
> interpretation.****
> ** **
> play which deals with those solution features.****
>
> Don’t really feel it’s necessary. But don’t feel very strongly.****
>
> ** **
>
> Req 12 fine****
>
> ** **
>
> ourselves from concepts 10+ years out of date?****
>
> Maybe I’m not clear on what you mean, since as you know some current
> systems use switching rather than transcoding. But, if you mean this is an
> unnecessary requirement, and multipoint is understood, I don’t mind removing
> the reqmt.****
>
> ** **
>
> example****
> Okay, agree****
> ** **
> Req 15 What is "audio activity"?  And, suggest moving this requirement up
> to where the other audio requirements are****
>
> Okay, will define audio activity. It’s more about what video to show than
> audio, so suggest leaving where it is.****
>
> ** **
>
> assorted requirements.****
>
> I think 3 is redundant with 4, so would like to remove****
>
> ** **
>
> Req 17 fine****
>
> ** **
>
> Stephan****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
>  ****
>
> ** **
>
> ** **
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 22 Jun 2011 17:09:27 -0400

one added comment, in-line

Stephen Botzko

On Wed, Jun 22, 2011 at 5:01 PM, Stephen Botzko <[email-masked]>wrote:

> HI Stephan -
>
> To clarify the 3b comment:  For me statements like "The solution MUST
> enable individual audio streams to be rendered in any desired spatial
> position" do not put *any* requirements on the renderer.  Req 3b says the
> solution must *enable* receivers to do this (e.g., provide any needed
> information).  But it does not say that receivers have to do anything.  So I
> see no reason to spend time rewording it.
>
> Meant to add that Ericsson's mobile use case includes putting audio streams
from each source in fixed spatial positions, completely independently of
whether there exists an associated video stream.  The idea is that on a
small mobile screen there is no need to align the audio and the video in
space (and this is impossible with earphones and a handheld display
anyway).  But they do see value in spatial audio, in order to make it easier
to distinguish voices, etc.  So the absence of "camera" in this requirement
was quite intentional.

>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Stephan Wenger
>> expressed positively, with the appropriate level of mandation.  So why not
>> "MAY" support binaural?  Or "SHOULD"?****
>>
>> gateway is in play which deals with those solution features.****
>>