Difference between revisions of "Planned Features"

From Mumble Wiki
Jump to: navigation, search
(TODO for 1.2.X: let's make it 1.X.X ;-))
 
(50 intermediate revisions by 9 users not shown)
Line 1: Line 1:
These are things that are planned added 'some time in the future'. Please try Mumble out before you comment on any of the ideas below.  
+
{{ReleaseTimeline}}
 +
 
 +
These are things that are planned added 'some time in the future'. Please try Mumble out before you comment on any of the ideas below.
  
 
If you want to help out with any of the below, '''great!''' Be aware that the mumble code is changing all the time, so please drop by the forums and let us know if you want to work on something so we avoid duplicate efforts.
 
If you want to help out with any of the below, '''great!''' Be aware that the mumble code is changing all the time, so please drop by the forums and let us know if you want to work on something so we avoid duplicate efforts.
  
Make SURE you are constantly updating to the latest snapshot of Mumble! Find it here: http://mumble.info/snapshot
+
'''Note: This list is not meant to be a point by point representations of tasks to be done for a specific release but is merely a reminder for the developers. New items might be added or existing ones moved and removed anytime during development.'''
  
== TODO for 1.2.X ==
+
{{FeedbackEncourage}}
  
* Improve usability a lot
+
== TODO for 1.X.X ==
 +
* Add session awareness
 +
* Group flags
 
* Put Qt 4.5 translation comments in more places, to show context of translation message.
 
* Put Qt 4.5 translation comments in more places, to show context of translation message.
* Add session awareness (.D0T)
+
* Improve usability a lot (e.g Restructure options menu)
 +
* Overlay configuration preview (maybe + on-desktop overlay)
 +
* Overlay for DirectX 9ex, 11
 +
 
 +
== TODO for statistics ==
 +
* Migrate to PDO
 +
* Add murmur stats
 +
* Add caching
 +
* Look for fancy pie-like stuff like jgraph, open-flash-chart2, etc
  
== TODO for 1.2.0 ==
+
== Future ==
 +
=== Video ===
 +
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.
  
* Show "obscure security" in the client.
+
Using H.264 encoding, 80x60 pixels is small enough that we can encode a 15fps video stream with minimal CPU impact. The bitrate will also be low (lower than existing audio streams), and with a bit of filtering the quality is near perfect. I really mean this; what filtering did for the audio quality in Mumble it also does for video quality.
* Open Server Info, kill server (to disconnect), close server info => Ouch.
 
* <= 10ms audio frames on *nix.
 
* Merge duplicate code from the Source-based plugins
 
* Spread trylock() for plugins out in time; one try per second instead of 10 every 10 seconds.
 
* Ponder SSE2 defaults -- separate binary?
 
* Update the Benchmark test
 
* Channel Add/Edit Dialog (.D0T)
 
* CoreAudio audio in/output for Mac OS X [krejler]
 
* Automatic overlay injection on Mac OS X [krejler]
 
* Pretty ConfigDialog on OSX. [krejler]
 
  
== Done for 1.2.0 ==
+
I'd like to see this happen; I miss seeing my friends when we're gaming. It's one thing to hear enthusiasm, it's quite another to see it.
  
* Do a version exchange client<=>server. Export over Ice.
+
There are two major challenges. The first is a technical one. 80x60 pixels is not much. It is enough to see a face clearly, if the face is the only thing in the picture. However, most people have their cameras placed so that 70% of the picture area is the room they are sitting in. That will not give a good enouh picture. So, we'll need a method to extract what we need from the image.
* Protocol Buffer based network protocol. Start merging everything into the PlayerState, ChannelState etc packets. The server should wipe fields it doesn't know about.
 
* Drop packet type etc from UDP, make it use it's own protocol, and have "TCP mode" be a "UDP tunnel packet" message.
 
* CELT-48k.
 
* Comments
 
* Associative key-based storage DB.
 
* Allow third-party "key/value" stored.
 
* Add a "context" for plugins, being a 32-byte array or somesuch. Players need identical context to get positional audio of each other.
 
* Add a "identity" for plugins, to be transmitted to the server.
 
* Multichannel echo cancellation.
 
* G15 for OSX.
 
* Client-certificate based authentication.
 
* Friends list -- recognize your friends (works across servers).
 
* s/Player/User/
 
* Switch to TCP mode if no ping packets work within the first 20 seconds, and switch back if it gets fixed.
 
* Add additional datafields to the banlist editor
 
* Make address be 2 x quint64 instead of 16 x char, and make it be hashable etc.
 
* Automatic plugin updates.
 
* User unregistration
 
* more formats for event sounds
 
* VoiceTarget message, use those 5 bits of the UDP type to differentiate Speech, AltSpeak and <target at specific user/channel>-speak.
 
* Upload textures from the client.
 
* If selfgen cert, and meta has a proper cert for the same host, use meta's instead.
 
* Give logical names to everything in the UI. Skinners currently use names like "groupBox_2", which is a bit error prone when we change the gui.
 
* QDesktopServices::storageLocation to replace getenv etc?
 
* OnlyAcceptWhispersFromFriends
 
* Multibind support for murmur, and IPv6.
 
* Per-server config storage for whisper targets.
 
* Fix ASIO.
 
* Try adding a 11x binary alongside the 1.2.0.
 
* Presets (import config)
 
* Access Tokens (aka password-protected channels)
 
* Temporary channels
 
* LAN discovery ([http://de.wikipedia.org/wiki/Bonjour_(Apple) Bonjour])
 
* Add buffering for broken WASAPI drivers.
 
* Provide layout presets
 
* Improve forced shutdown behavior
 
* Sorting channels
 
* Suppress state for the client
 
* XInput instead of XEvie.
 
* Crash reporting
 
  
== Current snapshot testing focus ==
+
The second is bandwidth. Yes, the video stream will use less bandwidth that an audio stream, but it will be going the whole time. This means that while audio bandwidth scales linearly with the number of users, video bandwidth scales exponentially. For example, if we assume that each user has 30 kbit/s of audio and 20 kbit/s of video. When one user talks, the others shut up. With 10 users, that's 9*30=270 kbit/s out from the server. Video, which is going the entire time, is 9*20=180kbit/s ''for each user'', giving us a total of 1.8Mbit/s.
 +
For all clans and guilds who host their servers somewhere with free bandwidth, this is not a problem. However, I don't really want to know what a 2mbit/s commercial hosting is going to cost. I doubt it's cheap.
  
== TODO for statistics ==
+
Some suggestions have been brought up by the community:
* Migrate to PDO
+
* Using WebM instead of H.264. When the time comes, we will look into it. VP8/WebM has the advantage of better licensing. H.264 with its free encoder x264 has the advantage of longer history and (thus) performance. We are aware WebM is improving in the performance field as well though.<sup>[https://sourceforge.net/tracker/index.php?func=detail&aid=3563031&group_id=147372&atid=768008 1]</sup>
* Add murmur stats
+
* Instead of continuous transmission, only transmit video when the user talks – as an optional feature.<sup>[https://sourceforge.net/tracker/index.php?func=detail&aid=3563954&group_id=147372&atid=768008 1]</sup>
* Add caching
 
* Look for fancy pie-like stuff like jgraph, etc
 
  
[[Category:Development]]
+
[[Category:Documentation English]][[Category:Development]]

Latest revision as of 22:46, 1 October 2016

Release timeline
1.2.0
Dec. 2009
1.2.1
Jan. 2010
1.2.2
Feb. 2010
1.2.3
Feb. 2011
1.2.4
Jun. 2013
1.2.5
Feb. 2014
1.2.6
May 2014
1.2.7
Jun. 2014
1.2.8
Aug. 2014
1.2.9
Jun. 2015
1.2.10
Jul. 2015
1.2.11
Dec. 2015
1.2.12
Dec. 2015
1.2.13
Jan. 2016
1.2.14
Feb. 2016
1.2.15
Mar. 2016
1.2.16
May. 2016
1.2.17
Sep. 2016
1.2.18
Dec. 2016
1.2.19
Jan. 2017
1.3.0
release candidate
1.4.0
in development
Future


These are things that are planned added 'some time in the future'. Please try Mumble out before you comment on any of the ideas below.

If you want to help out with any of the below, great! Be aware that the mumble code is changing all the time, so please drop by the forums and let us know if you want to work on something so we avoid duplicate efforts.

Note: This list is not meant to be a point by point representations of tasks to be done for a specific release but is merely a reminder for the developers. New items might be added or existing ones moved and removed anytime during development.

Feedback encouraged! - We rely on your testing and feedback to improve Mumble, if you find any bugs in the current stable or in a recent snapshot please report them using our bugtracker. If you think we lack an important feature take a look at the corresponding feature tracker.


TODO for 1.X.X

  • Add session awareness
  • Group flags
  • Put Qt 4.5 translation comments in more places, to show context of translation message.
  • Improve usability a lot (e.g Restructure options menu)
  • Overlay configuration preview (maybe + on-desktop overlay)
  • Overlay for DirectX 9ex, 11

TODO for statistics

  • Migrate to PDO
  • Add murmur stats
  • Add caching
  • Look for fancy pie-like stuff like jgraph, open-flash-chart2, etc

Future

Video

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. The bitrate will also be low (lower than existing audio streams), and with a bit of filtering the quality is near perfect. I really mean this; what filtering did for the audio quality in Mumble it also does for video quality.

I'd like to see this happen; I miss seeing my friends when we're gaming. It's one thing to hear enthusiasm, it's quite another to see it.

There are two major challenges. The first is a technical one. 80x60 pixels is not much. It is enough to see a face clearly, if the face is the only thing in the picture. However, most people have their cameras placed so that 70% of the picture area is the room they are sitting in. That will not give a good enouh picture. So, we'll need a method to extract what we need from the image.

The second is bandwidth. Yes, the video stream will use less bandwidth that an audio stream, but it will be going the whole time. This means that while audio bandwidth scales linearly with the number of users, video bandwidth scales exponentially. For example, if we assume that each user has 30 kbit/s of audio and 20 kbit/s of video. When one user talks, the others shut up. With 10 users, that's 9*30=270 kbit/s out from the server. Video, which is going the entire time, is 9*20=180kbit/s for each user, giving us a total of 1.8Mbit/s. For all clans and guilds who host their servers somewhere with free bandwidth, this is not a problem. However, I don't really want to know what a 2mbit/s commercial hosting is going to cost. I doubt it's cheap.

Some suggestions have been brought up by the community:

  • Using WebM instead of H.264. When the time comes, we will look into it. VP8/WebM has the advantage of better licensing. H.264 with its free encoder x264 has the advantage of longer history and (thus) performance. We are aware WebM is improving in the performance field as well though.1
  • Instead of continuous transmission, only transmit video when the user talks – as an optional feature.1