Speex dev - Aug 2004 - [Fwd: Re: [JDEV] Videoconferencing with jabber / Re: Videoconferencing with speex and jabber]

Hi Carsten, 

due to the ongoing discussion on both lists, i simply respond to both
lists. it's hard crossposting, but it's for both roups relevant (i
think). 

<p>+After having thought about control structures, it makes sense to me to
do the extra work and merge this creamed cake into a jabber server
component. Otherwise a control channel to the server component would
have to be opened, or a splitter to divide the incoming audio bytes from
control bytes would have to be added, which won't make things less
complicative.+

Of course it is possible to create a standalone server relay, too. 
But my relation to jabber.org tells me to do it that way... ;-)

ok. 

to speex: *now here comes the more important part, can we build a c++
component which does what avrelay does? is it practicable to de/encode
100 streams with a c/c++ speex de/encoder in realtime?* COMMENTS WELCOME

<p>The other part is, what do you think about a cooperation? All help on
this welcome! 

<p>to jabber: *We would need some protocol enhancements to the jabber
protocol to control muting of conference partners. It makes sense to me
to enhance the current jabber MUC protocol with some audio/video
specific stuff.* COMMENTS WELCOME

<p>Best regards, 
Ulrich

P.s. on the relay, carsten: 
The relay you may download at
http://greenthumb.jabberstudio.org/avrelay.html contains server and
client.

a server has to be started, onto which a client can connect. 
The client has to know the ip of the server. 

the client is started through the command listed on the avrelay.html
page.
the server is started through 'java uls.AVRelay'

The server listens by default on port 10000 (i think), can't remember
what i wrote 6 weeks ago. 

The server encodes in the session.java file.
The client encodes and decodes in TestClient.java. You'll see the
classes when looking through the code. 

<p><p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Hi Ulrich,

<p>you distroyed my evening today ;-). Im only sitting here
and follow the videoconferencing thread ;-)).
> due to the ongoing discussion on both lists, i simply respond to both
> lists. it's hard crossposting, but it's for both roups relevant (i
> think). 
Yes, this was right. There is a great discussion and perhaps we got
some points more yet.
> +After having thought about control structures, it makes sense to me to
> do the extra work and merge this creamed cake into a jabber server
> component. 
I dont have any glue about jabber server components, but it could be
the right way. we have to took in consideration, that we have at least
tree chanels to go for : administration, audio and video.

So, if we make a jabber server component, it should handle all of this.
My idea was to use jabber only to start the connection and to get the
IP of the other client. Afterwards the client's establish a connection
withou the need of jabber. I dont know if a server component is better here.
> Of course it is possible to create a standalone server relay, too. 
> But my relation to jabber.org tells me to do it that way... ;-)
Yes, could be right. But we have to thing about that a stand alone
solution is more flexible and can also be implemented in other
messenger (is this fait to tell this here <d&r>?).
> to speex: *now here comes the more important part, can we build a c++
> component which does what avrelay does? is it practicable to de/encode
> 100 streams with a c/c++ speex de/encoder in realtime?* COMMENTS WELCOME
I dont know what the exact timing is, but we can convert avrelay
to C++. We have to test the performance then. I can't say how much 
better it will go.
> The other part is, what do you think about a cooperation? All help on
> this welcome! 
Yes, i agree. We dont should reinvent the wheel.
So i be with you to convert it to C++. So we can also make sure
that it runs on linux and windows.
> P.s. on the relay, carsten: 
> The relay you may download at
Thanks, i have downloaded it and will review it in the next days.
Today there was no time to look to it ;-)).

Best wishes,

<p>Carsten
PS: I will post this also to the Sony Clie Developer Forum.
     They have a cool PDA with WLan and Webcam.
     That would be realy cool :-))-

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> to speex: *now here comes the more important part, can we build a c++
> component which does what avrelay does? is it practicable to de/encode
> 100 streams with a c/c++ speex de/encoder in realtime?* COMMENTS WELCOME
At low bit-rate (6-8 kbps) and lowest complexity, it's probably possible
to encode 100 streams on a 3 GHz machine (and decoding is cheap), but
that's all you're going to do on that machine. However, I tend to favor
the approach of sending multiple streams instead of doing a
decode-mix-reencode. For instance, if you're encoding at 8 kbps, you can
transmit up to two streams, which would make the maximum bit-rate 16
kbps (max 16 kbps), with no loss of quality. If you decide to go with
mixing, you'll probably have to go with 18.2 kbps because Speex is not
tuned for encoding multiple voices. Even then, the quality will likely
be lower because of the tandeming (reencoding). The only case where
mixing might be good is when working with high bit-rates (e.g. 15 kbps
narrowband or 28 kbps wideband).

        Jean-Marc


-- 
Jean-Marc Valin, M.Sc.A., ing. jr.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Ceci est une partie de message numériquement signée
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20031126/81230dde/signature-0001.pgp

Am Mi, 2003-11-26 um 00.26 schrieb Carsten Breuer:
> Hi Ulrich,
> 
> 
> you distroyed my evening today ;-). Im only sitting here
> and follow the videoconferencing thread ;-)).
:-)
me too. 

thanks, best wishes,
ulrich

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Hi Jean-Marc,

<p>>>to speex: *now here comes the more important part, can we build
a c++
>>component which does what avrelay does? is it practicable to de/encode
>>100 streams with a c/c++ speex de/encoder in realtime?* COMMENTS WELCOME
> At low bit-rate (6-8 kbps) and lowest complexity, it's probably
possible
> to encode 100 streams on a 3 GHz machine (and decoding is cheap), but
> that's all you're going to do on that machine. However, I tend to
favor
> the approach of sending multiple streams instead of doing a
Hmmm.. i had the simple idea to mix the encoded streams with the method
outstream [idx] = (stream1[idx] + stream2[idx]) / 2;

OK, perhaps this is a realy silly solution, but i dont want to increase
the bps in any way. The point is that we build a V I D E O conferencing
software, so the most bandwith must be free for the video part. Of 
course we can use the highter bitstreams in audio only mode.

I have to make some tests with Ulrich Software to get a idea of that.

Best regards,

<p><p>Carsten Breuer

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.