Dear John,
What Maxim meant was: 1. Screen-sharing and audio are two SEPARATE features (and program modules). They do not effect each other at the code level. 2. Users can use both as well as chat and whiteboard and zoom. But their smooth functioning is dictated by your Internet speed. NORMAL screensharing requires a minimum of 1 Mbps UPLOAD speed per attendee. NORMAL video requires 500Kbps upload per attendee. Do you have UPLOAD speed of at least 1.5 Mbps per attendee. So, if you have 5 attendees, you may need around 4 Mbps upload (=1.5+0.5*5) Thank you. Sincerely, Hemant K. Sabat Coscend Communications Solutions www.Coscend.com <http://www.coscend.com/> ------------------------------------------------------------------ Real-time, Interactive Video Collaboration, Tele-healthcare, Tele-education, Telepresence Services, on the fly… ------------------------------------------------------------------ CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail Messages from Coscend Communications Solutions' posted at: http://www.Coscend.com/Terms_and_Conditions.html From: john felipe urrego mejia [mailto:ingenierofelipeurr...@gmail.com] Sent: Saturday, July 29, 2017 12:18 PM To: Openmeetings user-list <user@openmeetings.apache.org> Subject: Re: Re: Screen Sharing too slow Then when screen sharing how talk with my people?, Chat? El 29 jul. 2017 9:08, "Maxim Solodovnik" <solomax...@gmail.com <mailto:solomax...@gmail.com> > escribió: screen-sharing does not work with audio. It basically captures the screen, encode it and send to server Can you check with smaller area? is it work better? On Sat, Jul 29, 2017 at 2:41 AM, john felipe urrego mejia <ingenierofelipeurr...@gmail.com <mailto:ingenierofelipeurr...@gmail.com> > wrote: 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:solomax...@gmail.com> > An: "Openmeetings user-list" <user@openmeetings.apache.org <mailto: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 <mailto: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 <mailto:findingj...@gmail.com> [findingj...@gmail.com <mailto: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 <mailto:opena...@gmail.com> [opena...@gmail.com <mailto: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 -- WBR Maxim aka solomax --- This email has been checked for viruses by AVG. http://www.avg.com
