Unfortunately bandwidth is not a bottleneck currently :( the main issue is the performance of client machine right now :(
We already have a task to enhance screen sharing protocol https://issues.apache.org/jira/browse/OPENMEETINGS-112 unfortunately it is still not implemented TightVNC protocol more like can not be used due to it is most probably will not be playable by flash :( Additionally any protocol implementation we will use must be Apache License compatible (this is why we unable to grab-and-use anything from the internet, but need to check licenses) On Tue, Mar 31, 2015 at 9:54 AM, OpenAr-IT Soluciones <opena...@gmail.com> wrote: > Hi Maxim, is there a possibility that screen share function can use the > same codec that VNC or TightVNC uses?. In that case the that function could > need less bandwidth. > > > TightVNC decoder: > What is Tight Decoder? > > The RFB protocol as used in VNC and TightVNC defines "encodings" as > algorithms/formats used to encode graphics (pixel data). TightVNC uses its > own highly-efficient method of compressing graphics optimized for low > bandwidth. It's called "*Tight encoding*". Tight encoding includes both > efficient "lossless" compression and optional "lossy" JPEG compression. > > > Reference link: > > http://www.tightvnc.com/decoder.php > > > Thanks in advance. > > > > > On Wed, Mar 25, 2015 at 6:27 AM, Maxim Solodovnik <solomax...@gmail.com> > wrote: > >> Actually there is GSOC project, but there are no students willing to >> participate :( >> >> On Wed, Mar 25, 2015 at 2:31 PM, BBS Technik <dormiti...@gmx.de> wrote: >> >>> Hi, >>> >>> will we see a GSoC project to enhance the sreensharing performance? >>> >>> Best regards >>> >>> Ed >>> >>> >>> >>> Gesendet: Mittwoch, 25. März 2015 um 05:23 Uhr >>> Von: "Maxim Solodovnik" <solomax...@gmail.com> >>> An: "Openmeetings user-list" <user@openmeetings.apache.org> >>> Betreff: Re: Screen Sharing too slow >>> >>> screen video is encoded using screenv1 codec >>> h264 is more CPU consuming, h263 is currently used by default for video >>> >>> medium quality do reduces video picture size, you can zoom it back while >>> viewing >>> >>> On Wed, Mar 25, 2015 at 10:11 AM, OpenAr-IT Soluciones < >>> opena...@gmail.com> wrote: >>> >>> Thanks FJ, >>> That means that it is a bandwidth issue?. The problem with Medium >>> quality is that the screen is smaller. Is it possible to reduce the screen >>> quality without reduce the screen size?, like reducing the definition. >>> >>> Thanks. >>> >>> >>> On Wed, Mar 25, 2015 at 1:05 AM, FJ <findingj...@gmail.com[ >>> findingj...@gmail.com]> wrote: >>> >>> I experienced this too on HI at 10FPS. When I change it to Medium at >>> 10FPS, it seems to be acceptable. >>> I have my OM3.0.4 at a CoLo with a 100Mb connection and two client at a >>> remote location. >>> >>> >>> On Tue, Mar 24, 2015 at 8:53 PM, OpenAr-IT Soluciones < >>> opena...@gmail.com[opena...@gmail.com]> wrote: >>> >>> Hi Maxim/all, >>> >>> I have OM 3.0.4 (stable) installed in a VM with Debian 7 with 2.5 GB >>> Ram, 2 CPUs. I have tested the Screen Share function with 2 users conected >>> to OM, both are conected via Wi-Fi (band N). The problem is that with the >>> configuration of High Resolution and 10 FPS the screen share is very slow, >>> it has a lot of delay. Sometimes the screen freezes and then continue. The >>> video (small size) of the person that is sharing the screen, gets very slow >>> too. I did the same test with your Demo server and I had the same problem, >>> less slow but slow too. What do you think the problem is?When I shared the >>> screen using my VM as OM server, CPU was at 30% and Ram at 20 %. >>> >>> Thanks in advance. >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > -- WBR Maxim aka solomax
