[JDEV] Videoconferencing with jabber / Re:[speex-dev]Videoconferencing with speex and jabber

[Ulrich B. Staudinger]

> > Unless you use client side echo removal (which ofcourse will put some
> > extra burden on the client, what I'm indeed trying to avoid all along, but
> > it's still a compromise). But agreed, this is one of the main advantages
> > of using a direct link based conference. Again, you'll benifit the most
> > (and the disadvantages will be the least obvious) if all clients have
> > somewhat equal specs, while in most cases I doubt this is true for Joe
> > Consumer.
> 
> Of course not all machines will have equal specs, but if they were bought
> within the last 3-5 years they will likely be plenty powerful enough for our
> requirements as far as CPU power goes.

lol, sorry, richard, you have no experience what is needed to actually
encode and decode data, i think ... ;-)

> 
> > >> Ofcourse you still have to mix when you use DirectX ;)
> > >
> > > Playing two (or more) streams simultaneously is not mixing as far as I
> am
> > > concerned, so no you dont necessarly have to even mix.
> >
> > Ofcourse the streams are mixed, just by DirectX/ALSA/whatever instead of
> > you. If your soundcard has some Direct X compatible hardware for this the
> > soundcard can do the mixing. (Which is still true in many cases if you use
> > a server that uses DirectX for mixing too)
> 
> But the point is that you do not have to manually code it and in so doing do
> it in the processor, using such things as directx means it is far more
> optimised and will take advantage of any sound hardware (or processor
> extensions such as SSE) you have to accellerate this. This is in contrast to
> server mixing that will have to be manually done in the processor as it
> needs to be re-encoded and retransmitted.

in fact server encoding can use direct x hardware, too. why shouldn't
it? 

> > Then we both don't know ;) But most implementations probably won't be so
> > advanced, if this is even possible (and you made a good point about
> > re-encoding, which I more seriously doubt you can optimize much)
> 
> Yes the real problem is the re-encoding, not the mixing.

not necessarily a problem. it can be optimized in many ways ... 


> 
> > > Because you will hear yourself echo from the other end, that is I
> thought
> > > what you meant, but overall I doubt syncing is something we really need
> > > to
> > > concentrate on or worry about too much.
> >
> > Out of sync mixing is *the* biggest annoyance about direct-link based
> > conferencing if you ask me. Escp. when participants have severly different
> > connections. I find this unbareable to work with.
> 
> Fine but not all people find it as much of a problem as you do.

and not all people agree with this statement. 

> 
> > > its a
> > > modified version of your model where instead of having a single server
> > > you
> > > could have as many as possible which communicate with each other via
> p2p,
> > > but anyone who is incapable due to platform issues, bandwidth, CPU,
> > > firewall
> > > etc to act as a server itself connects to one of these servers, this
> > > provides the benefit of more evenly load balancing the CPU/bandwidth use
> > > of
> > > the chat over several nodes rather than concentrating on one, provides
> > > instant fall back to another server if one has problems or leaves, and
> > > provides your primary benefit of being able to support dialup users or
> > > simple clients like pocket pc's or people who cant go p2p because of
> > > firewalls.
> >
> > I think my idea as decribed more at the beginning of this email and here
> > are pretty much alike. Are you suggesting a persistant network or these
> > servers (which is p2p I suppose) or a per-conference network? (which I'd
> > rather just call clustering of the servers)
> 
> It would just be a per chat network automatically setup from the chat
> participants.
> 
> > Do you feel such a system should be part of the "base" spec for (audio)
> > conferncing or an extention? And what do you feel should be done for NAT
> > traversel in person to person? In case you suggest a peristant network of
> > these nodes is that what should be used for that?
> 
> I feel this must be part of the base spec, and I dont feel a persistent
> network is needed, as far as NAT traversal goes the servers will need to be
> able to full traverse the NAT or firewall they have, which can be done with
> UPnP (Zeroconf ?), or manual setup by a knowledgable person, but we must try
> to minimize that requirement.

of course it is needed to have a persistant network. and to remind
again: it's needed to have video conferencing, too. 

ulrich