The future

[manthey08]

hey there,

first of all i need to say , mumble is one of the best , secure and leightweigh, audioconferecing tools i ever used.

I was reading the wikipages and i saw this statement:

 

The current overlay texture system is designed for high speed texture transfers in a format that happens to be 60 pixels high. This is no coincidence.

Using H.264 encoding, 80x60 pixels is small enough that we can encode a 15fps video stream with minimal CPU impact.

 

and i am asking why only 80x60 ? beside the bandwith issue are there any technical limitation and could this be circumvented ?

My second questions is about clickable links like mumble://myservername , which opens the mumble client application, will this implemented soon ?

Thanks

[hacst]

Thanks for the praise :D

 

and i am asking why only 80x60 ? beside the bandwith issue are there any technical limitation and could this be circumvented?

The video feature definitely would require some protocol changes alongside some rather big changes to the client. At this point it is really something for the "future" (aka not a point release). We want it but other things are more important. From a technical POV nothing much but bandwidth client- and serverside limit what's possible (well there's legal too but that's not technical ;-) ). Once we get around tackling it we'll evaluate what we can do without making all the hosters hate us :lol: .

 

My second questions is about clickable links like mumble://myservername , which opens the mumble client application, will this implemented soon ?

We already offer Mumble URLs that work like that, see http://mumble.sourceforge.net/Mumble_URL for more information. They should work out of the box when using one of our distributed installers.

[manthey08]

Thanks for your reply

 

We already offer Mumble URLs that work like that, see http://mumble.sourceforge.net/Mumble_URL for more information. They should work out of the box when using one of our distributed installers.

 

Thats awsome, i will dig into this. :geek:

 

without making all the hosters hate us :lol: .

 

Or wait till http://en.wikipedia.org/wiki/Multicast is available, :lol:

But seriously, how did you accomplish this outstanding latency ? I am a musican and i believe its under 10ms , are there any comparison charts between Teamspeak, Ventrilo, Skype and Mumble ?

Cheers

[hacst]

Thanks for your reply

But seriously, how did you accomplish this outstanding latency ? I am a musican and i believe its under 10ms , are there any comparison charts between Teamspeak, Ventrilo, Skype and Mumble ?

 

There are a few videos on youtube doing comparisons. Not aware of any comprehensive testing but I think we are pretty competitive :D

Your 10ms guess is a bit low for a full trip ear-to-ear, we have at least that much algorithmic delay when encoding (we could go lower but the overhead is a killer and most hardware doesn't like it either).

But what we can actually do isn't to shabby either, see http://blog.mumble.info/oh-no-weve-made-a-buzzword/ . Slicer actually measured down to 40ms ear-to-ear including network which is pretty good.

[manthey08]

Thanks for your reply, my last question, i saw you have bonjour implemented, i guess its only used in a .local network ,are there any plans to support wide area bonjour, or is the registration to the main server ( when your murmur server appear in the pulic directory ) accomplished by WAB allready ?

Thanks in advance

[hacst]

Thanks for your reply, my last question, i saw you have bonjour implemented, i guess its only used in a .local network ,are there any plans to support http://www.dns-sd.org/ClientSetup.html wide area bonjour ?

Our Bonjour is local only. There are no plans to support wide area Bonjour, we considered it back then but we already have our public list to achieve pretty much the same with functionality specifically catered to our use.

In hindsight we probably wouldn't even have used Bonjour (I implemented the feature back then and advocated for using Bonjour). We thought using an existing standard over spinning our own (amongst thousands) of broadcast UDP discovery protocols would be a good idea. Turned out to be more hassle than it's worth. Apple and Linux are relatively unproblematic (ok, avahi on Linux is bitching about us using the zeroconf API but who cares...). On Windows however Bonjour is a third party install and the license doesn't allow us to ship it with the installer. We used to integrate the download into the installer but Apple changed the URLs.... Also quite a few users don't like the dependency on an such Apple software (whose functinal scope is much bigger then what we need, bonjour printer discovery anyone?). Oh and their SDK now is behind a registration... . All a bit of a pita and the feature doesn't seem to be used much anyways.

[manthey08]

Thanks for your answer, one thing just came to my mind, what about DDos protection, is there anything build into the protocol stack which prevent such attacks. ? or is there any protection at all ? or you have any idea what would be nescessary to protect servers against DDos ? I am not talking about a botnet, whitch is impossible, i am talking about some folks using the well kown tools. Is http://snort.org/ or http://snorby.org usefull in this case ? ?

greetings