Nothing about this? Because i have 4 sec of lag in voice when screen sharing Stay alert
2015-03-31 0:57 GMT-05:00 Maxim Solodovnik <solomax...@gmail.com>: > 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[finding >>>> j...@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 >
