Hi Ed, thanks for your ideas.
About idea no 1: That is an interesting idea, however it won't be possible that you provide a "free to choose" bandwidth for each user. The background is: Every stream that any client consumes has to be created somewhere. So what could be realized is that every stream that is broadcasted from one user via webcam to Red5/OpenMeetings will be re-transcoded into multiple streams (high, middle, low) bandwidth. So there might be some limitations to that: - "high" quality will never be better then the original material. We can't make a picture better then the original. So all re-transcoding will only make the original to lower quality, never to higher. - Re-transcoding has to happen on the server side (and number of streams are limited, we can't provide a stream on the required bandwidth "on-demand" for each user, or only with very big effort) - it will require real-time transcoding on server side which is possible with FFMPEG and some integration into Red5. But we would need a very specialized student that is keen and very motiviated as there is hardly any documentation on that available in the internet. What a project makes a success is if all participant know the potential outcome and the tools and methods that are needed to realize that. I would be happy to put this project on our list but it will be difficult to find somebody with the needed skills. Sebastian 2013/2/12 BBS Technik <dormiti...@gmx.de> > Hi all, > > I think, one of the gratest liminations for satisfactory video > conferencing with om is the limited bandwidth of internet connections of > the clients . > Therefore I would like to suggest the following ideas for a GSoC project : > > 1. The image size of the videos transferred from the om server to the > clients should be adapted to the video window size set in the recipient > client. > Thus the recipient client itself could influence the transferred amount of > data to it. > Then all the participants achieve the best possible result for them. > > 2. A second proposal concerns that the screensharing bandwidth > requirements has an great impact on the overall quality of the video > conference. > Here, in a project the existing function of sreen sharing could be > expanded and enhanced. > For example, the possibility for the transfer on only one application > window, regardless of its size. > Or the possibility of shared browsing with a locally installed browser. > Moreover, certainly an improvement of the used compression method would be > a very good project topic. > > I would be happy if the subject of bandwidth consumption would plays a > role in the selected GSoC project . > > Best regards > > Ed > > > > > -------- Original-Nachricht -------- > > Datum: Tue, 12 Feb 2013 08:44:54 +1300 > > Von: "seba.wag...@gmail.com" <seba.wag...@gmail.com> > > An: dev <d...@openmeetings.apache.org> > > CC: user@openmeetings.apache.org > > Betreff: GSoC project ideas wanted > > > Google Summer of Code is about to start soon! > > Google sponsors every student with 4500USD. Plus 500 for the Apache > > Foundation. > > > > We are searching for ideas what porential students can do. > > Ideas from Non-Developers are welcome too! > > > > We will add the ideas to JIRA then with a special label so students can > > find it. > > > > Sebastian > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
