Re: [clue] Requirement on centralized media mixing

[<[e-mail]>]

Hi,

I agree that these requirements are meaningful for CLUE, and correspond to valid use cases of telepresence experience.

> For video, once you have negotiated the usage of centralized rendering, you could negotiate whether the rendered
> stream is "most active speaker", and different types of layout options. I do realize, however, that we might not be
> talking about "rendering type" in the same meaning as for audio in that case. It might be more related to "rendering
> control", and if we want that it should probably be covered in a separate requirement.

What do you think of the wording "rendering policy"?


Stephane. 

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Christer Holmberg
Envoyé : mercredi 15 juin 2011 15:29
À : Stephen Botzko
Cc : [e-mail]
Objet : Re: [clue] Requirement on centralized media mixing


Hi Stephen,

>>>>>If some other WG (for instance MMUSIC) defined a mechanism for 
>>>>>general use of binaural audio for SIP/RTP, then I would fully support requirements that such a facility should be enabled in CLUE.
>>>>>
>>>>>But I do not think that CLUE is the right place to invent 
>>>>>negotiation of binaural audio.  Telepresence system users generally do not use headsets.
>>>>
>>>>No, but users communicating with a telepresence system using other types of devices may.
>>>
>>>Yes they might. But CLUE is not the place to create completely new facilities that are not intended for telepresence systems.
>>
>>Being able to connect to telepresence system with non-TP devices is 
>>within the scope of the work, and we think it would create great added value if we have a mechanism which allows offering an optimized "near-telepresence experience" also to such devices.
>
>Yes, connecting telepresence systems to legacy devices is within scope.  And identifying relationships between streams is within scope. 
>
>Binaural audio is not in either category. It is a specific mode of 
>audio which for some reason has not been standardized. Telepresence systems do not use it, and there is no SDP defined for legacy devices to use either  And It is not a stream relationship like left, right.
>
>I am not saying that binaural audio has no value; I think it does. But 
>I don't think it is in scope. There is trouble ahead if every shiny new 
>media idea becomes CLUE work because some hypothetical future non-telepresence device might want to use it to talk to a telepresence system through a middle box.

We are not talking about any "hypothetical future non-telepresence device". We are talking about the most widely spread communication device in the world, and we are talking about providing means for optimizing the user experience for such a device. As we see it this is perfectly inline with the CLUE charter.

>>>It is about having a generic mechanism for negotiation of centralized media mixing usage, if the system supports it.
>>
>>I don't understand what  "negotiate the type of media rendering" means.  Maybe you can describe more precisely what is meant?
>
>It's about two things:
>
>First, to be able to find out whether the system supports centralized rendering in the first place. Note that such functionality is optional.
>
>Second, to be able to request centralized rendering, and the type of rendering.
>
>What is the type of rendering? If this is a general facility not limited to binaural audio, then I'd like some other "types" to be identified. 

For audio, you could have "mono", and different types of "stereo" (e.g plain, paning, binaural).

Note that we are not suggesting that, within the CLUE work, start to define every possible type, or even specific types. We propose a generic mechanism.

For video, once you have negotiated the usage of centralized rendering, you could negotiate whether the rendered stream is "most active speaker", and different types of layout options. I do realize, however, that we might not be talking about "rendering type" in the same meaning as for audio in that case. It might be more related to "rendering control", and if we want that it should probably be covered in a separate requirement.

>And I think we will need a definition. As it stands, I have no idea how to tell if a proposed solution meets this requirement or not.

As discussed the interim meeting, the task was to come up with suitable wording. I've tried to do that, but of course I am willing to do modifications in order to clarify the text.

Regards,

Christer

	 


________________________________

	From: Stephen Botzko [mailto:[e-mail]] 
	Sent: 15. kesäkuuta 2011 13:48
	To: Christer Holmberg
	Cc: [e-mail]
	Subject: Re: [clue] Requirement on centralized media mixing
	
	


	On Wed, Jun 15, 2011 at 6:08 AM, Christer Holmberg <[e-mail]> wrote:
	


		Hi Stephen,
		

		>>>If some other WG (for instance MMUSIC) defined a mechanism for
		>>>general use of binaural audio for SIP/RTP, then I would fully support requirements that such a facility should be enabled in CLUE.
		>>>
		>>>But I do not think that CLUE is the right place to invent negotiation
		>>>of binaural audio.  Telepresence system users generally do not use headsets.
		>>
		>>No, but users communicating with a telepresence system using other types of devices may.
		>
		>Yes they might. But CLUE is not the place to create completely new facilities that are not intended for telepresence systems.
		
		
		Being able to connect to telepresence system with non-TP devices is within the scope of the work, and we think it would create great added value if we have a mechanism which allows offering an optimized "near-telepresence experience" also to such devices.
		

	Yes, connecting telepresence systems to legacy devices is within scope.  And identifying relationships between streams is within scope. 
	
	Binaural audio is not in either category.  It is a specific mode of audio which for some reason has not been standardized.  Telepresence systems do not use it, and there is no SDP defined for legacy devices to use either  And It is not a stream relationship like left, right.  
	
	I am not saying that binaural audio has no value; I think it does.   But I don't think it is in scope. There is trouble ahead if every shiny new media idea becomes CLUE work because some hypothetical future non-telepresence device might want to use it to talk to a telepresence system through a middle box.
	


		>>It is about having a generic mechanism for negotiation of centralized media mixing usage, if the system supports it.
		>
		>I don't understand what  "negotiate the type of media rendering" means.  Maybe you can describe more precisely what is meant?
		
		
		It's about two things:
		
		First, to be able to find out whether the system supports centralized rendering in the first place. Note that such functionality is optional.
		
		Second, to be able to request centralized rendering, and the type of rendering.
		

	What is the type of rendering?  If this is a general facility not limited to binaural audio, then I'd like some other "types" to be identified. And I think we will need  a definition.  As it stands, I have no idea how to tell if a proposed solution meets this requirement or not.
	
	


		(Solution wise, we might be talking about some SDP attributes in order to do this)
		
		Note that this proposal does not have any impact on the definitions, or on the telepresence "room model".
		

		Regards,
		
		Christer
		
		
		
		
		
		               On Tue, Jun 14, 2011 at 10:22 AM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
		
		               Hi,
		
		               During the last interim meeting (May 12th) we discussed a requirement proposal
		               stating that an endpoint must be able to request central audio rendering
		               of different predefined formats, including 3D binaural rendering.
		               (Link to proposal: http://www.ietf.org/mail-archive/web/clue/current/msg00179.html)
		
		               The proposal was well received, with the reservation that it should not be mandatory
		
		               for the solution to implement centralized 3D binaural rendering, i.e.an<http://i.e.an> endpoint should
		
		               be able to request 3D binaural rendering, but had no guaranty that such rendering was
		               supported by the system.
		
		               It was decided to look how such requirement could look like.
		
		               When I look the -03 version of the req draft, Requirement 2c states:
		
		                  "The solution MUST NOT preclude the use of binaural audio."
		
		               I think that requirement is unclear, and it doesn't really give any guidance to our work.
		
		               Due to that, and also due to the fact that rather than talking about specific rendering types,
		               I would like to propose more general requirement text on the negotiation of the media mixing type,
		               and the usage of centralized media mixing in the first place.
		
		               The mechanism would be extendable, so new types can be added in future.
		
		               So, the proposed requirements are:
		
		               REQ-x:    It MUST be possible to negotiate the usage of centralized media mixing. System support of centralized media mixing is optional.
		
		               REQ-y:    When centralized media mixing is used, it MUST be possible to negotiate the type of media rendering provided for each media stream received by a client.
		
		               Regards,
		
		               Christer


_______________________________________________
clue mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/clue