Re: [codec] #3: 2.2. Conferencing: Support of binaural audio?

["Slava Borilin" <[e-mail]>]

Sure.
	
I see that web-conferencing applications are different - as typical business case (take for Webex as example) is that provider charge only ONE user (host) for the conference, but then you have to mix 10 people (participants) in that conference, consuming "10" resources and getting only 1 money.

System for 1000 paid accounts like webex requires having 10 000 ports in the conferencing server.

Therefore, mixing (or muxing) efficiency of conferencing servers are nowadays MORE important then before.

So webconfrencing requires much better scaling of the conferencing that old "all-per-minute" telco models.
This is important both for audio and video.

For video finally we have 264SVC, and for audio we (again) need layered codec.

с уважением,
Вячеслав Борилин


-----Original Message-----
From: Gregory Maxwell [mailto:[e-mail]] 
Sent: Tuesday, March 23, 2010 9:59 PM
To: Christian Hoene; Slava Borilin; [e-mail]
Subject: RE: [codec] #3: 2.2. Conferencing: Support of binaural audio?

Christian Hoene [[e-mail]] wrote:
> (a) does not have any impact on the requirements but in case of (b) codec requirements are the support of stereo speech transmission and support for efficient mixing.

I agree that (b) requires support for stereo. 

Since you're coming from mono you're going to do the panning/auralization to  virtually position participants at different locations.   Physiologically/acoustically correct positioning is likely going to defeat any mixing short-cuts that a codec provides.     E.g. with CELT (and presumably other codecs)  you can use the independent frame mechanisms  to eliminate or minimize  conferencing server computation when hard switching between sources,  but you can't do this if you're converting a mono stream to positioned stereo.  So I don't think that it requires any more than support for stereo. 

I suppose we could ask that codecs support a mode where a mono stream is sent with a positioning wrapper, instead of using stereo over the link... But for that case, I think that could be provided equally or better by another protocol or wrapper also running on RTP in a codec independent manner.

Of course, minimizing the codec computational burden is helpful for scaling conferencing systems.

Can anyone share some typical conference scaling numbers which they consider interesting?    It's been my view that all comers are fast enough that conferencing on commercial scale isn't much of an issue:  That, yes, it might take some serious processing grunt to handle 10,000 users on a conferencing system, but if you're running at that kind of scale you could afford the required hardware.   I've not see any numbers to suggest that this isn't the case.