@Alexei: This is basically a functionality of the streaming server. Any kind of development should happen inside that. I know that Flash Media server has a reference implementation. See: http://livedocs.adobe.com/flashmediaserver/3.0/hpdocs/help.html?content=00000182.html => NetSream.Play.InsufficientBW is the event that we want.
There was (or maybe there is still an experimental) implementation of this event in Red5. However I am not sure what the current status is. There are a number of NetStream Event/Status messages that are only partially or not implemented at all in Red5. If any implementation of measuring bandwidth bottlenecks happens we should stick to the reference implementation rather then inventing our own mechanism. The other thing is that the bottleneck is typically not the download channel, its the upload channel. So if there are delays in the audio signal (which is by far the most annoying thing) there is nothing you can do from a viewers perspective. The issue is in the upload bandwidth of the broadcaster, not the viewer. You could in fact for instance change the video resolution of the broadcaster's video dynamically to reduce their bandwidth consumption. But the important part is solving the InsufficientBW event in Red5. @Ross: When it comes to HTML5 Video-Conferencing, our issues are not so much on the viewers side, the issues are more around the broadcaster. Capturing cam+mic and then the distribution of the streams. Those are from my point of view currently the biggest challenges when it comes to a complete implementation of OpenMeetings in HTML5. Sebastian 2013/8/22 Maxim Solodovnik <[email protected]> > We have scheduled removing of flash video component after 3.1.0. > I guess we should start discussion regarding replacement technology after > 3.0.0 release > > > On Thu, Aug 22, 2013 at 12:33 PM, Ross Gardler > <[email protected]>wrote: > > > At the risk of creating an unnecessary diversion, have you considered > > using an adaptive streaming protocol. I'm involved with dash.js a > > reference implementation of MPEG-DASH. I'd love to see it used here in > > open meetings. However that is a client, not a server. I'm not sure if > > there are any open source servers, but I'd be happy to look into it for > > you. > > > > The biggest advantage of this (other than improved video experience) > > would be the ability to participate without browser plugins (for > > browsers that support MSE, which is chrome and IE11 at this point). > > > > This is an early stage technology, but it progressing rapidly and > > industry is picking it up (e.g. Nearly 75% of EU broadcasters expect to > > be using it by mid 2014). > > > > Sent from my Windows Phone From: Alexei Fedotov > > Sent: 8/21/2013 10:12 AM > > To: dev > > Subject: recurring topic: adaptive video > > Hello folks, > > > > how difficult (if technically possible) would be the following: > > > > 1) understand that video / sound of some participant experiences delays; > > 2) stop video for that participant; > > > > in other words, switch off the video for those who does not have enough > > channel? > > > > Maybe something like liveDelay can tell that delays exceed some limit > > to start emergency procedures? > > > > -- > > With best regards / с наилучшими пожеланиями, > > Alexei Fedotov / Алексей Федотов, > > http://dataved.ru/ > > +7 916 562 8095 > > > > [1] Start using Apache Openmeetings today, > http://openmeetings.apache.org/ > > [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ > > [3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings > > > > > > -- > WBR > Maxim aka solomax > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
