Re: ScreenSharer issues
hi, 2009/1/30 smoeker > > hola, > > i got jrdesktop to work with openMeetings Screenservlet, so that the > jpgs are shown in the Whiteboard (on serverside i only needed to > implement small functions to unzip the bytearray...) > > -> unfortunately, it seems, as i f the scalability of the whiteboard > seems to be gone within the current release ;-) - i hoped to be able > to grab the clients whiteboard dimensions to scale the image on > serverside for a optimum > of quality for each client... > -> is there a certain reason for making the whiteboard unscalable for > the users? => the whiteboard is scalable => you can just re-size the hole browser window and the whiteboard should use that size. You can apply the screens-images to the whiteboard size automatically. The whiteboard will become also bigger in size as the Property Editor will be removed from its current position and the Chat box will be that way that you can turn it on/off (something similar to the Property Editor) > > > -> by the way, it seems to be a small effort using jrdesktop due to > its auto triggering, but im still not quite satisfied, because the > result in the whiteboard is still a bit shaky ;-) => I think we can improve the Image quality only if we use better compression or if we produce a Stream. > > > before finalizing the efforts of optimizing screensharing, i would > like to grab one of your ideas, sebastian : streaming the desktop > content via red5 to the laszlo clients : > > -> i found some interesting code, so as a free java2swf lib and a free > RTMP - Client - Implementation that could be combined to create a SWF > on clientside, streamed via red5... > -> unfortunately, im no streaming king, so it will take some time, to > read - maybe you could give me some feedback in advance about > technical barriers, that have to be in mind before starting another > try... => you have to search about a possibility to read a RTP Stream and re-broadcast in Red5. Out of the box there are no such possibilities. And its not that easy (I guess). You might have a look at Xuggler Project cause they already integrated FFMPEG or the red5phone. > > > any hints/support/warnings are welcome ;-) > > (by the way, as soon as i beautyfied the jrdesktop code, i will upload > it as alternative, cause i think it already is quite nice ;-)) > > > see ya > > Smoeker > > On 29 Jan., 16:17, Sebastian Wagner wrote: > > hi, > > > > 2009/1/29 smoeker > > > > > > > > > hi, > > > > > as far as i know, the Remote control isnt included in the openSource > > > part, but i will have a closer look, as soon as the basics work ;-) > > > > > conecerning the internationalisation prob : u mean the labels in the > > > webstart client? if so, we could implement an additional > > > webstartargument, posting a csv - string with the already translated > > > labels into the client. > > > alternativley a additonal servletcall would be requiered... > > > > > what would u prefer? > > > > => I think the csv would be sufficient. On the other hand at a later > stage > > .. or also a problem is that you cannot trigger events from the system to > > the web-start client ... for example to stop/start sharing. But for the > > Labels the CSV approach would be absolutely sufficient. > > > > > > > > > > > > > see ya > > > > > Smoeker > > > > > On 28 Jan., 20:53, Sebastian Wagner wrote: > > > > btw: There is also another Issue not solved yet with the > screen-sharer: > > > > Make it international => loading the strings for the text boxes from > > > > language-tables. > > > > > > sebastian > > > > > > 2009/1/28 Sebastian Wagner > > > > > > > that sound very good! I think you can completely replace the old > one > > > with > > > > > it, cause basically if they work the same: > > > > > > > - you can reduce the sample-rate (or "screnn-shots-per-seconds") > > > > > - I think the jrdesktop should use already less bandwidth cause it > uses > > > a > > > > > ZIP-compression > > > > > > > what about the other features of the jrdesktop? Do we have them > too? > > > Like > > > > > *controlling a distance PC*? > > > > > Or is that step two? > > > > > > > sebastian > > > > > > > 2009/1/28 smoeker > > > > > > >> hi, > > > > > > >> i just began to alter the jrdesktop code - it seems to work > basically > > > > >> (for testing purposes i took over the code you used in the > > > > >> screenviewer and placed it at a point in jrdesktop, where data > usually > > > > >> gets sent via RMI...) > > > > > > >> -> altering the screecast_template.vm i was able to test it under > > > > >> realistic conditions > > > > >> -> the transfer itself works fine, a file is transmitted within > the > > > > >> right roomnumber (although there still is work, cause jrdesktop > doesnt > > > > >> use the JPEGEncoder, so the file isnt readable on serverside as > > > > >> jpeg ;-) > > > > > > >> -> as soon as it works, i would implement the viewer optional as > > > > >> alternative for "high bandwidth scenarios", the switch c
Re: ScreenSharer issues
hola, i got jrdesktop to work with openMeetings Screenservlet, so that the jpgs are shown in the Whiteboard (on serverside i only needed to implement small functions to unzip the bytearray...) -> unfortunately, it seems, as i f the scalability of the whiteboard seems to be gone within the current release ;-) - i hoped to be able to grab the clients whiteboard dimensions to scale the image on serverside for a optimum of quality for each client... -> is there a certain reason for making the whiteboard unscalable for the users? -> by the way, it seems to be a small effort using jrdesktop due to its auto triggering, but im still not quite satisfied, because the result in the whiteboard is still a bit shaky ;-) before finalizing the efforts of optimizing screensharing, i would like to grab one of your ideas, sebastian : streaming the desktop content via red5 to the laszlo clients : -> i found some interesting code, so as a free java2swf lib and a free RTMP - Client - Implementation that could be combined to create a SWF on clientside, streamed via red5... -> unfortunately, im no streaming king, so it will take some time, to read - maybe you could give me some feedback in advance about technical barriers, that have to be in mind before starting another try... any hints/support/warnings are welcome ;-) (by the way, as soon as i beautyfied the jrdesktop code, i will upload it as alternative, cause i think it already is quite nice ;-)) see ya Smoeker On 29 Jan., 16:17, Sebastian Wagner wrote: > hi, > > 2009/1/29 smoeker > > > > > hi, > > > as far as i know, the Remote control isnt included in the openSource > > part, but i will have a closer look, as soon as the basics work ;-) > > > conecerning the internationalisation prob : u mean the labels in the > > webstart client? if so, we could implement an additional > > webstartargument, posting a csv - string with the already translated > > labels into the client. > > alternativley a additonal servletcall would be requiered... > > > what would u prefer? > > => I think the csv would be sufficient. On the other hand at a later stage > .. or also a problem is that you cannot trigger events from the system to > the web-start client ... for example to stop/start sharing. But for the > Labels the CSV approach would be absolutely sufficient. > > > > > > > see ya > > > Smoeker > > > On 28 Jan., 20:53, Sebastian Wagner wrote: > > > btw: There is also another Issue not solved yet with the screen-sharer: > > > Make it international => loading the strings for the text boxes from > > > language-tables. > > > > sebastian > > > > 2009/1/28 Sebastian Wagner > > > > > that sound very good! I think you can completely replace the old one > > with > > > > it, cause basically if they work the same: > > > > > - you can reduce the sample-rate (or "screnn-shots-per-seconds") > > > > - I think the jrdesktop should use already less bandwidth cause it uses > > a > > > > ZIP-compression > > > > > what about the other features of the jrdesktop? Do we have them too? > > Like > > > > *controlling a distance PC*? > > > > Or is that step two? > > > > > sebastian > > > > > 2009/1/28 smoeker > > > > >> hi, > > > > >> i just began to alter the jrdesktop code - it seems to work basically > > > >> (for testing purposes i took over the code you used in the > > > >> screenviewer and placed it at a point in jrdesktop, where data usually > > > >> gets sent via RMI...) > > > > >> -> altering the screecast_template.vm i was able to test it under > > > >> realistic conditions > > > >> -> the transfer itself works fine, a file is transmitted within the > > > >> right roomnumber (although there still is work, cause jrdesktop doesnt > > > >> use the JPEGEncoder, so the file isnt readable on serverside as > > > >> jpeg ;-) > > > > >> -> as soon as it works, i would implement the viewer optional as > > > >> alternative for "high bandwidth scenarios", the switch could be within > > > >> the ScreenCast VelocityLoader class, loading another template pointing > > > >> to the jrdesktop_customized_viewer (that doesnt need any other lib, so > > > >> it wouldnt blow up ressources too much ;-)) > > > > >> -> when its working fine, no code on serverside would have to be > > > >> changed... > > > > >> see ya > > > > >> Smoeker > > > > >> On 28 Jan., 16:08, Sebastian Wagner wrote: > > > >> > okay I am fine with that. > > > > >> > Red5 does not support RTP. But there are lots of activities around > > that. > > > >> > There are some approaches but I had no chance to have a deeper look > > yet. > > > > >> > I am fine with your approach. I think first you need to find out > > what > > > >> kind > > > >> > of resource-handler you need on server side to read the > > client-stream > > > >> (RMI > > > >> > or whatever it does). > > > > >> > sebastian > > > > >> > 2009/1/28 smoeker > > > > >> > > hi, > > > > >> > > does red5 support RTP? > > > > >> > > i just found a tool named vnc2swf - this tool seems to be able to >
Re: ScreenSharer issues
hi, 2009/1/29 smoeker > > hi, > > as far as i know, the Remote control isnt included in the openSource > part, but i will have a closer look, as soon as the basics work ;-) > > conecerning the internationalisation prob : u mean the labels in the > webstart client? if so, we could implement an additional > webstartargument, posting a csv - string with the already translated > labels into the client. > alternativley a additonal servletcall would be requiered... > > what would u prefer? > => I think the csv would be sufficient. On the other hand at a later stage .. or also a problem is that you cannot trigger events from the system to the web-start client ... for example to stop/start sharing. But for the Labels the CSV approach would be absolutely sufficient. > > see ya > > Smoeker > > On 28 Jan., 20:53, Sebastian Wagner wrote: > > btw: There is also another Issue not solved yet with the screen-sharer: > > Make it international => loading the strings for the text boxes from > > language-tables. > > > > sebastian > > > > 2009/1/28 Sebastian Wagner > > > > > > > > > > > > > that sound very good! I think you can completely replace the old one > with > > > it, cause basically if they work the same: > > > > > - you can reduce the sample-rate (or "screnn-shots-per-seconds") > > > - I think the jrdesktop should use already less bandwidth cause it uses > a > > > ZIP-compression > > > > > what about the other features of the jrdesktop? Do we have them too? > Like > > > *controlling a distance PC*? > > > Or is that step two? > > > > > sebastian > > > > > 2009/1/28 smoeker > > > > >> hi, > > > > >> i just began to alter the jrdesktop code - it seems to work basically > > >> (for testing purposes i took over the code you used in the > > >> screenviewer and placed it at a point in jrdesktop, where data usually > > >> gets sent via RMI...) > > > > >> -> altering the screecast_template.vm i was able to test it under > > >> realistic conditions > > >> -> the transfer itself works fine, a file is transmitted within the > > >> right roomnumber (although there still is work, cause jrdesktop doesnt > > >> use the JPEGEncoder, so the file isnt readable on serverside as > > >> jpeg ;-) > > > > >> -> as soon as it works, i would implement the viewer optional as > > >> alternative for "high bandwidth scenarios", the switch could be within > > >> the ScreenCast VelocityLoader class, loading another template pointing > > >> to the jrdesktop_customized_viewer (that doesnt need any other lib, so > > >> it wouldnt blow up ressources too much ;-)) > > > > >> -> when its working fine, no code on serverside would have to be > > >> changed... > > > > >> see ya > > > > >> Smoeker > > > > >> On 28 Jan., 16:08, Sebastian Wagner wrote: > > >> > okay I am fine with that. > > > > >> > Red5 does not support RTP. But there are lots of activities around > that. > > >> > There are some approaches but I had no chance to have a deeper look > yet. > > > > >> > I am fine with your approach. I think first you need to find out > what > > >> kind > > >> > of resource-handler you need on server side to read the > client-stream > > >> (RMI > > >> > or whatever it does). > > > > >> > sebastian > > > > >> > 2009/1/28 smoeker > > > > >> > > hi, > > > > >> > > does red5 support RTP? > > > > >> > > i just found a tool named vnc2swf - this tool seems to be able to > > >> > > convert RFB into SWF.. the demos are cool, but it only comes along > > >> > > with python or c++, so it would mean lots of work > > >> > > on clientside (no more webstart solution...) and on serverside > > >> > > (ancapsulating a VNC - Server or having it running as additional > > >> > > dependency...). > > > > >> > > hmmm, > > > > >> > > i think i first will test a small solution (jrdesktop) and > customize > > >> > > it, so it will call the ScreenServlet with a higher interval. > > >> > > Meanwhile i will keep on reading about the possible protocols to > keep > > >> > > the big solution in mind ;-) > > > > >> > > see ya > > > > >> > > Smoeker > > > > >> > > On 28 Jan., 12:02, Sebastian Wagner > wrote: > > >> > > > instead of RFB ... implementation would be nice but I think for > the > > >> > > moment > > >> > > > RTP would be more interesting? > > > > >> > > > I mean if the red5-server could read and re-broadcast RFB... > that > > >> would > > >> > > be > > >> > > > perfect. But as RFB is no multi-media format I am not sure how > this > > >> > > should > > >> > > > work. I think RFB allows multiple encodings inside. But the > question > > >> > > would > > >> > > > be how to parse these things out of RFB. > > > > >> > > > sebastian > > > > >> > > > 2009/1/28 smoeker > > > > >> > > > > ...by the way - some info stuff... > > > > >> > > > > ->http://jrdesktop.sourceforge.net/asalternativeon clientside > > >> > > > > ->http://www.realvnc.com/docs/rfbproto.pdftheRFBProtocol that > > >> > > > > would cause changes also on serverside... > > > > >> > > > > see ya > > > > >> > > > > Smoeker
Re: ScreenSharer issues
hi, as far as i know, the Remote control isnt included in the openSource part, but i will have a closer look, as soon as the basics work ;-) conecerning the internationalisation prob : u mean the labels in the webstart client? if so, we could implement an additional webstartargument, posting a csv - string with the already translated labels into the client. alternativley a additonal servletcall would be requiered... what would u prefer? see ya Smoeker On 28 Jan., 20:53, Sebastian Wagner wrote: > btw: There is also another Issue not solved yet with the screen-sharer: > Make it international => loading the strings for the text boxes from > language-tables. > > sebastian > > 2009/1/28 Sebastian Wagner > > > > > > > that sound very good! I think you can completely replace the old one with > > it, cause basically if they work the same: > > > - you can reduce the sample-rate (or "screnn-shots-per-seconds") > > - I think the jrdesktop should use already less bandwidth cause it uses a > > ZIP-compression > > > what about the other features of the jrdesktop? Do we have them too? Like > > *controlling a distance PC*? > > Or is that step two? > > > sebastian > > > 2009/1/28 smoeker > > >> hi, > > >> i just began to alter the jrdesktop code - it seems to work basically > >> (for testing purposes i took over the code you used in the > >> screenviewer and placed it at a point in jrdesktop, where data usually > >> gets sent via RMI...) > > >> -> altering the screecast_template.vm i was able to test it under > >> realistic conditions > >> -> the transfer itself works fine, a file is transmitted within the > >> right roomnumber (although there still is work, cause jrdesktop doesnt > >> use the JPEGEncoder, so the file isnt readable on serverside as > >> jpeg ;-) > > >> -> as soon as it works, i would implement the viewer optional as > >> alternative for "high bandwidth scenarios", the switch could be within > >> the ScreenCast VelocityLoader class, loading another template pointing > >> to the jrdesktop_customized_viewer (that doesnt need any other lib, so > >> it wouldnt blow up ressources too much ;-)) > > >> -> when its working fine, no code on serverside would have to be > >> changed... > > >> see ya > > >> Smoeker > > >> On 28 Jan., 16:08, Sebastian Wagner wrote: > >> > okay I am fine with that. > > >> > Red5 does not support RTP. But there are lots of activities around that. > >> > There are some approaches but I had no chance to have a deeper look yet. > > >> > I am fine with your approach. I think first you need to find out what > >> kind > >> > of resource-handler you need on server side to read the client-stream > >> (RMI > >> > or whatever it does). > > >> > sebastian > > >> > 2009/1/28 smoeker > > >> > > hi, > > >> > > does red5 support RTP? > > >> > > i just found a tool named vnc2swf - this tool seems to be able to > >> > > convert RFB into SWF.. the demos are cool, but it only comes along > >> > > with python or c++, so it would mean lots of work > >> > > on clientside (no more webstart solution...) and on serverside > >> > > (ancapsulating a VNC - Server or having it running as additional > >> > > dependency...). > > >> > > hmmm, > > >> > > i think i first will test a small solution (jrdesktop) and customize > >> > > it, so it will call the ScreenServlet with a higher interval. > >> > > Meanwhile i will keep on reading about the possible protocols to keep > >> > > the big solution in mind ;-) > > >> > > see ya > > >> > > Smoeker > > >> > > On 28 Jan., 12:02, Sebastian Wagner wrote: > >> > > > instead of RFB ... implementation would be nice but I think for the > >> > > moment > >> > > > RTP would be more interesting? > > >> > > > I mean if the red5-server could read and re-broadcast RFB... that > >> would > >> > > be > >> > > > perfect. But as RFB is no multi-media format I am not sure how this > >> > > should > >> > > > work. I think RFB allows multiple encodings inside. But the question > >> > > would > >> > > > be how to parse these things out of RFB. > > >> > > > sebastian > > >> > > > 2009/1/28 smoeker > > >> > > > > ...by the way - some info stuff... > > >> > > > > ->http://jrdesktop.sourceforge.net/asalternativeon clientside > >> > > > > ->http://www.realvnc.com/docs/rfbproto.pdftheRFBProtocol that > >> > > > > would cause changes also on serverside... > > >> > > > > see ya > > >> > > > > Smoeker > > >> > > > > On 28 Jan., 11:07, smoeker wrote: > >> > > > > > hi sebastian, > > >> > > > > > thnx for your quick reply! > > >> > > > > > i dont think, the streaming via RMI would work ;-) > > >> > > > > > i think, the best quality could be reached by real streaming via > >> > > > > > platform independent RFP, but it would cause massive changes on > >> OM > >> > > > > > serverside, i think. > > >> > > > > > so i would prefer an enhancement of the current solution, so as > >> > > > > > implementing a customized jrdesktop - client as screensharer, > >> that > >> > > > > > sends the jpegs in the
Re: ScreenSharer issues
btw: There is also another Issue not solved yet with the screen-sharer: Make it international => loading the strings for the text boxes from language-tables. sebastian 2009/1/28 Sebastian Wagner > that sound very good! I think you can completely replace the old one with > it, cause basically if they work the same: > > - you can reduce the sample-rate (or "screnn-shots-per-seconds") > - I think the jrdesktop should use already less bandwidth cause it uses a > ZIP-compression > > what about the other features of the jrdesktop? Do we have them too? Like > *controlling a distance PC*? > Or is that step two? > > sebastian > > 2009/1/28 smoeker > > >> hi, >> >> i just began to alter the jrdesktop code - it seems to work basically >> (for testing purposes i took over the code you used in the >> screenviewer and placed it at a point in jrdesktop, where data usually >> gets sent via RMI...) >> >> -> altering the screecast_template.vm i was able to test it under >> realistic conditions >> -> the transfer itself works fine, a file is transmitted within the >> right roomnumber (although there still is work, cause jrdesktop doesnt >> use the JPEGEncoder, so the file isnt readable on serverside as >> jpeg ;-) >> >> -> as soon as it works, i would implement the viewer optional as >> alternative for "high bandwidth scenarios", the switch could be within >> the ScreenCast VelocityLoader class, loading another template pointing >> to the jrdesktop_customized_viewer (that doesnt need any other lib, so >> it wouldnt blow up ressources too much ;-)) >> >> -> when its working fine, no code on serverside would have to be >> changed... >> >> see ya >> >> Smoeker >> >> On 28 Jan., 16:08, Sebastian Wagner wrote: >> > okay I am fine with that. >> > >> > Red5 does not support RTP. But there are lots of activities around that. >> > There are some approaches but I had no chance to have a deeper look yet. >> > >> > I am fine with your approach. I think first you need to find out what >> kind >> > of resource-handler you need on server side to read the client-stream >> (RMI >> > or whatever it does). >> > >> > sebastian >> > >> > 2009/1/28 smoeker >> > >> > >> > >> > >> > >> > >> > >> > > hi, >> > >> > > does red5 support RTP? >> > >> > > i just found a tool named vnc2swf - this tool seems to be able to >> > > convert RFB into SWF.. the demos are cool, but it only comes along >> > > with python or c++, so it would mean lots of work >> > > on clientside (no more webstart solution...) and on serverside >> > > (ancapsulating a VNC - Server or having it running as additional >> > > dependency...). >> > >> > > hmmm, >> > >> > > i think i first will test a small solution (jrdesktop) and customize >> > > it, so it will call the ScreenServlet with a higher interval. >> > > Meanwhile i will keep on reading about the possible protocols to keep >> > > the big solution in mind ;-) >> > >> > > see ya >> > >> > > Smoeker >> > >> > > On 28 Jan., 12:02, Sebastian Wagner wrote: >> > > > instead of RFB ... implementation would be nice but I think for the >> > > moment >> > > > RTP would be more interesting? >> > >> > > > I mean if the red5-server could read and re-broadcast RFB... that >> would >> > > be >> > > > perfect. But as RFB is no multi-media format I am not sure how this >> > > should >> > > > work. I think RFB allows multiple encodings inside. But the question >> > > would >> > > > be how to parse these things out of RFB. >> > >> > > > sebastian >> > >> > > > 2009/1/28 smoeker >> > >> > > > > ...by the way - some info stuff... >> > >> > > > > ->http://jrdesktop.sourceforge.net/asalternative on clientside >> > > > > ->http://www.realvnc.com/docs/rfbproto.pdftheRFB Protocol that >> > > > > would cause changes also on serverside... >> > >> > > > > see ya >> > >> > > > > Smoeker >> > >> > > > > On 28 Jan., 11:07, smoeker wrote: >> > > > > > hi sebastian, >> > >> > > > > > thnx for your quick reply! >> > >> > > > > > i dont think, the streaming via RMI would work ;-) >> > >> > > > > > i think, the best quality could be reached by real streaming via >> > > > > > platform independent RFP, but it would cause massive changes on >> OM >> > > > > > serverside, i think. >> > >> > > > > > so i would prefer an enhancement of the current solution, so as >> > > > > > implementing a customized jrdesktop - client as screensharer, >> that >> > > > > > sends the jpegs in the format, the OM Server needs. >> > > > > > (enhancement could be a bettter quality and a higher >> interval...) >> > >> > > > > > see ya >> > >> > > > > > Smoeker >> > >> > > > > > On 28 Jan., 09:56, Sebastian Wagner >> wrote: >> > >> > > > > > > hi, >> > >> > > > > > > 2009/1/28 smoeker >> > >> > > > > > > > hi there, >> > >> > > > > > > > The implemented ScreenViewer seems to be a quite resource >> saving >> > > > > > > > solution to share ones screen, but unfortunately it seems to >> work >> > > > > > > > quite slow and the ScreenCapture is quite unsharp >> > >> > > > > > > >
Re: ScreenSharer issues
that sound very good! I think you can completely replace the old one with it, cause basically if they work the same: - you can reduce the sample-rate (or "screnn-shots-per-seconds") - I think the jrdesktop should use already less bandwidth cause it uses a ZIP-compression what about the other features of the jrdesktop? Do we have them too? Like *controlling a distance PC*? Or is that step two? sebastian 2009/1/28 smoeker > > hi, > > i just began to alter the jrdesktop code - it seems to work basically > (for testing purposes i took over the code you used in the > screenviewer and placed it at a point in jrdesktop, where data usually > gets sent via RMI...) > > -> altering the screecast_template.vm i was able to test it under > realistic conditions > -> the transfer itself works fine, a file is transmitted within the > right roomnumber (although there still is work, cause jrdesktop doesnt > use the JPEGEncoder, so the file isnt readable on serverside as > jpeg ;-) > > -> as soon as it works, i would implement the viewer optional as > alternative for "high bandwidth scenarios", the switch could be within > the ScreenCast VelocityLoader class, loading another template pointing > to the jrdesktop_customized_viewer (that doesnt need any other lib, so > it wouldnt blow up ressources too much ;-)) > > -> when its working fine, no code on serverside would have to be > changed... > > see ya > > Smoeker > > On 28 Jan., 16:08, Sebastian Wagner wrote: > > okay I am fine with that. > > > > Red5 does not support RTP. But there are lots of activities around that. > > There are some approaches but I had no chance to have a deeper look yet. > > > > I am fine with your approach. I think first you need to find out what > kind > > of resource-handler you need on server side to read the client-stream > (RMI > > or whatever it does). > > > > sebastian > > > > 2009/1/28 smoeker > > > > > > > > > > > > > > > > > hi, > > > > > does red5 support RTP? > > > > > i just found a tool named vnc2swf - this tool seems to be able to > > > convert RFB into SWF.. the demos are cool, but it only comes along > > > with python or c++, so it would mean lots of work > > > on clientside (no more webstart solution...) and on serverside > > > (ancapsulating a VNC - Server or having it running as additional > > > dependency...). > > > > > hmmm, > > > > > i think i first will test a small solution (jrdesktop) and customize > > > it, so it will call the ScreenServlet with a higher interval. > > > Meanwhile i will keep on reading about the possible protocols to keep > > > the big solution in mind ;-) > > > > > see ya > > > > > Smoeker > > > > > On 28 Jan., 12:02, Sebastian Wagner wrote: > > > > instead of RFB ... implementation would be nice but I think for the > > > moment > > > > RTP would be more interesting? > > > > > > I mean if the red5-server could read and re-broadcast RFB... that > would > > > be > > > > perfect. But as RFB is no multi-media format I am not sure how this > > > should > > > > work. I think RFB allows multiple encodings inside. But the question > > > would > > > > be how to parse these things out of RFB. > > > > > > sebastian > > > > > > 2009/1/28 smoeker > > > > > > > ...by the way - some info stuff... > > > > > > > ->http://jrdesktop.sourceforge.net/asalternative on clientside > > > > > ->http://www.realvnc.com/docs/rfbproto.pdftheRFB Protocol that > > > > > would cause changes also on serverside... > > > > > > > see ya > > > > > > > Smoeker > > > > > > > On 28 Jan., 11:07, smoeker wrote: > > > > > > hi sebastian, > > > > > > > > thnx for your quick reply! > > > > > > > > i dont think, the streaming via RMI would work ;-) > > > > > > > > i think, the best quality could be reached by real streaming via > > > > > > platform independent RFP, but it would cause massive changes on > OM > > > > > > serverside, i think. > > > > > > > > so i would prefer an enhancement of the current solution, so as > > > > > > implementing a customized jrdesktop - client as screensharer, > that > > > > > > sends the jpegs in the format, the OM Server needs. > > > > > > (enhancement could be a bettter quality and a higher interval...) > > > > > > > > see ya > > > > > > > > Smoeker > > > > > > > > On 28 Jan., 09:56, Sebastian Wagner > wrote: > > > > > > > > > hi, > > > > > > > > > 2009/1/28 smoeker > > > > > > > > > > hi there, > > > > > > > > > > The implemented ScreenViewer seems to be a quite resource > saving > > > > > > > > solution to share ones screen, but unfortunately it seems to > work > > > > > > > > quite slow and the ScreenCapture is quite unsharp > > > > > > > > > > -> i would like to help optimizing the feature, but before > > > opening an > > > > > > > > issue in the DEV - Zone, i would like to > > > > > > > > hear about experiences about that topic. > > > > > > > > > > -> Regarding the code, i saw, that every 3 seconds a snapshot > is > > > > > taken > > > > > > > > and sent to the ScreenServlet, posting a new slide to t
Re: ScreenSharer issues
hi, i just began to alter the jrdesktop code - it seems to work basically (for testing purposes i took over the code you used in the screenviewer and placed it at a point in jrdesktop, where data usually gets sent via RMI...) -> altering the screecast_template.vm i was able to test it under realistic conditions -> the transfer itself works fine, a file is transmitted within the right roomnumber (although there still is work, cause jrdesktop doesnt use the JPEGEncoder, so the file isnt readable on serverside as jpeg ;-) -> as soon as it works, i would implement the viewer optional as alternative for "high bandwidth scenarios", the switch could be within the ScreenCast VelocityLoader class, loading another template pointing to the jrdesktop_customized_viewer (that doesnt need any other lib, so it wouldnt blow up ressources too much ;-)) -> when its working fine, no code on serverside would have to be changed... see ya Smoeker On 28 Jan., 16:08, Sebastian Wagner wrote: > okay I am fine with that. > > Red5 does not support RTP. But there are lots of activities around that. > There are some approaches but I had no chance to have a deeper look yet. > > I am fine with your approach. I think first you need to find out what kind > of resource-handler you need on server side to read the client-stream (RMI > or whatever it does). > > sebastian > > 2009/1/28 smoeker > > > > > > > > > hi, > > > does red5 support RTP? > > > i just found a tool named vnc2swf - this tool seems to be able to > > convert RFB into SWF.. the demos are cool, but it only comes along > > with python or c++, so it would mean lots of work > > on clientside (no more webstart solution...) and on serverside > > (ancapsulating a VNC - Server or having it running as additional > > dependency...). > > > hmmm, > > > i think i first will test a small solution (jrdesktop) and customize > > it, so it will call the ScreenServlet with a higher interval. > > Meanwhile i will keep on reading about the possible protocols to keep > > the big solution in mind ;-) > > > see ya > > > Smoeker > > > On 28 Jan., 12:02, Sebastian Wagner wrote: > > > instead of RFB ... implementation would be nice but I think for the > > moment > > > RTP would be more interesting? > > > > I mean if the red5-server could read and re-broadcast RFB... that would > > be > > > perfect. But as RFB is no multi-media format I am not sure how this > > should > > > work. I think RFB allows multiple encodings inside. But the question > > would > > > be how to parse these things out of RFB. > > > > sebastian > > > > 2009/1/28 smoeker > > > > > ...by the way - some info stuff... > > > > > ->http://jrdesktop.sourceforge.net/asalternative on clientside > > > > ->http://www.realvnc.com/docs/rfbproto.pdftheRFB Protocol that > > > > would cause changes also on serverside... > > > > > see ya > > > > > Smoeker > > > > > On 28 Jan., 11:07, smoeker wrote: > > > > > hi sebastian, > > > > > > thnx for your quick reply! > > > > > > i dont think, the streaming via RMI would work ;-) > > > > > > i think, the best quality could be reached by real streaming via > > > > > platform independent RFP, but it would cause massive changes on OM > > > > > serverside, i think. > > > > > > so i would prefer an enhancement of the current solution, so as > > > > > implementing a customized jrdesktop - client as screensharer, that > > > > > sends the jpegs in the format, the OM Server needs. > > > > > (enhancement could be a bettter quality and a higher interval...) > > > > > > see ya > > > > > > Smoeker > > > > > > On 28 Jan., 09:56, Sebastian Wagner wrote: > > > > > > > hi, > > > > > > > 2009/1/28 smoeker > > > > > > > > hi there, > > > > > > > > The implemented ScreenViewer seems to be a quite resource saving > > > > > > > solution to share ones screen, but unfortunately it seems to work > > > > > > > quite slow and the ScreenCapture is quite unsharp > > > > > > > > -> i would like to help optimizing the feature, but before > > opening an > > > > > > > issue in the DEV - Zone, i would like to > > > > > > > hear about experiences about that topic. > > > > > > > > -> Regarding the code, i saw, that every 3 seconds a snapshot is > > > > taken > > > > > > > and sent to the ScreenServlet, posting a new slide to the > > whiteboard > > > > - > > > > > > > are there known problems increasing the interval? > > > > > > > => yes more bandwidth is needed. You have to load all screens using > > > > red5 as > > > > > > proxy. As you cannot load anything directly from one Client to > > another. > > > > > > > > -> i am not too familiar with the known Remote Protocols (RDP, > > > > RFP,..) > > > > > > > - maybe there are already native ways to combine it with the > > given > > > > > > > architecture, so it would be possible to "stream" the desktop > > content > > > > > > > into the whiteboard? > > > > > > > => Yes what needs to be done would be to create RTP stream out of > > > > > > screen-images and the Plugin that stream
Re: ScreenSharer issues
okay I am fine with that. Red5 does not support RTP. But there are lots of activities around that. There are some approaches but I had no chance to have a deeper look yet. I am fine with your approach. I think first you need to find out what kind of resource-handler you need on server side to read the client-stream (RMI or whatever it does). sebastian 2009/1/28 smoeker > > hi, > > does red5 support RTP? > > > i just found a tool named vnc2swf - this tool seems to be able to > convert RFB into SWF.. the demos are cool, but it only comes along > with python or c++, so it would mean lots of work > on clientside (no more webstart solution...) and on serverside > (ancapsulating a VNC - Server or having it running as additional > dependency...). > > hmmm, > > i think i first will test a small solution (jrdesktop) and customize > it, so it will call the ScreenServlet with a higher interval. > Meanwhile i will keep on reading about the possible protocols to keep > the big solution in mind ;-) > > see ya > > Smoeker > > On 28 Jan., 12:02, Sebastian Wagner wrote: > > instead of RFB ... implementation would be nice but I think for the > moment > > RTP would be more interesting? > > > > I mean if the red5-server could read and re-broadcast RFB... that would > be > > perfect. But as RFB is no multi-media format I am not sure how this > should > > work. I think RFB allows multiple encodings inside. But the question > would > > be how to parse these things out of RFB. > > > > sebastian > > > > 2009/1/28 smoeker > > > > > > > > > > > > > > > > > ...by the way - some info stuff... > > > > > ->http://jrdesktop.sourceforge.net/as alternative on clientside > > > ->http://www.realvnc.com/docs/rfbproto.pdfthe RFB Protocol that > > > would cause changes also on serverside... > > > > > see ya > > > > > Smoeker > > > > > On 28 Jan., 11:07, smoeker wrote: > > > > hi sebastian, > > > > > > thnx for your quick reply! > > > > > > i dont think, the streaming via RMI would work ;-) > > > > > > i think, the best quality could be reached by real streaming via > > > > platform independent RFP, but it would cause massive changes on OM > > > > serverside, i think. > > > > > > so i would prefer an enhancement of the current solution, so as > > > > implementing a customized jrdesktop - client as screensharer, that > > > > sends the jpegs in the format, the OM Server needs. > > > > (enhancement could be a bettter quality and a higher interval...) > > > > > > see ya > > > > > > Smoeker > > > > > > On 28 Jan., 09:56, Sebastian Wagner wrote: > > > > > > > hi, > > > > > > > 2009/1/28 smoeker > > > > > > > > hi there, > > > > > > > > The implemented ScreenViewer seems to be a quite resource saving > > > > > > solution to share ones screen, but unfortunately it seems to work > > > > > > quite slow and the ScreenCapture is quite unsharp > > > > > > > > -> i would like to help optimizing the feature, but before > opening an > > > > > > issue in the DEV - Zone, i would like to > > > > > > hear about experiences about that topic. > > > > > > > > -> Regarding the code, i saw, that every 3 seconds a snapshot is > > > taken > > > > > > and sent to the ScreenServlet, posting a new slide to the > whiteboard > > > - > > > > > > are there known problems increasing the interval? > > > > > > > => yes more bandwidth is needed. You have to load all screens using > > > red5 as > > > > > proxy. As you cannot load anything directly from one Client to > another. > > > > > > > > -> i am not too familiar with the known Remote Protocols (RDP, > > > RFP,..) > > > > > > - maybe there are already native ways to combine it with the > given > > > > > > architecture, so it would be possible to "stream" the desktop > content > > > > > > into the whiteboard? > > > > > > > => Yes what needs to be done would be to create RTP stream out of > > > > > screen-images and the Plugin that stream into red5 sothat it can > > > > > re-broadcast that > > > > > > > > -> as alternative i just evluated jrdesktop, a small open source > > > > > > alternative using RMI to communicate between two > > > > > > installations(one acting as server, the others as client). It > works > > > > > > very similar to sebastians solution (but without the possibility > of > > > > > > reducing the screen dimension), but seems to be very performant > and > > > > > > providing a high quality.. > > > > > > > => looks interesting. What we could use from that is the > > > ZIP-compression at > > > > > least. But what they use is RMI. That means its also no real > streaming > > > isn't > > > > > it? Or can you send a constant stream over RMI? > > > > > > > > see ya > > > > > > > > Smoeker > > > > > > > -- > > > > > Sebastian > > > > Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp://... > > > > > seba.wag...@gmail.com- Zitierten Text ausblenden - > > > > > > - Zitierten Text anzeigen - > > > > -- > > Sebastian > Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp
Re: ScreenSharer issues
hi, does red5 support RTP? i just found a tool named vnc2swf - this tool seems to be able to convert RFB into SWF.. the demos are cool, but it only comes along with python or c++, so it would mean lots of work on clientside (no more webstart solution...) and on serverside (ancapsulating a VNC - Server or having it running as additional dependency...). hmmm, i think i first will test a small solution (jrdesktop) and customize it, so it will call the ScreenServlet with a higher interval. Meanwhile i will keep on reading about the possible protocols to keep the big solution in mind ;-) see ya Smoeker On 28 Jan., 12:02, Sebastian Wagner wrote: > instead of RFB ... implementation would be nice but I think for the moment > RTP would be more interesting? > > I mean if the red5-server could read and re-broadcast RFB... that would be > perfect. But as RFB is no multi-media format I am not sure how this should > work. I think RFB allows multiple encodings inside. But the question would > be how to parse these things out of RFB. > > sebastian > > 2009/1/28 smoeker > > > > > > > > > ...by the way - some info stuff... > > > ->http://jrdesktop.sourceforge.net/as alternative on clientside > > ->http://www.realvnc.com/docs/rfbproto.pdfthe RFB Protocol that > > would cause changes also on serverside... > > > see ya > > > Smoeker > > > On 28 Jan., 11:07, smoeker wrote: > > > hi sebastian, > > > > thnx for your quick reply! > > > > i dont think, the streaming via RMI would work ;-) > > > > i think, the best quality could be reached by real streaming via > > > platform independent RFP, but it would cause massive changes on OM > > > serverside, i think. > > > > so i would prefer an enhancement of the current solution, so as > > > implementing a customized jrdesktop - client as screensharer, that > > > sends the jpegs in the format, the OM Server needs. > > > (enhancement could be a bettter quality and a higher interval...) > > > > see ya > > > > Smoeker > > > > On 28 Jan., 09:56, Sebastian Wagner wrote: > > > > > hi, > > > > > 2009/1/28 smoeker > > > > > > hi there, > > > > > > The implemented ScreenViewer seems to be a quite resource saving > > > > > solution to share ones screen, but unfortunately it seems to work > > > > > quite slow and the ScreenCapture is quite unsharp > > > > > > -> i would like to help optimizing the feature, but before opening an > > > > > issue in the DEV - Zone, i would like to > > > > > hear about experiences about that topic. > > > > > > -> Regarding the code, i saw, that every 3 seconds a snapshot is > > taken > > > > > and sent to the ScreenServlet, posting a new slide to the whiteboard > > - > > > > > are there known problems increasing the interval? > > > > > => yes more bandwidth is needed. You have to load all screens using > > red5 as > > > > proxy. As you cannot load anything directly from one Client to another. > > > > > > -> i am not too familiar with the known Remote Protocols (RDP, > > RFP,..) > > > > > - maybe there are already native ways to combine it with the given > > > > > architecture, so it would be possible to "stream" the desktop content > > > > > into the whiteboard? > > > > > => Yes what needs to be done would be to create RTP stream out of > > > > screen-images and the Plugin that stream into red5 sothat it can > > > > re-broadcast that > > > > > > -> as alternative i just evluated jrdesktop, a small open source > > > > > alternative using RMI to communicate between two > > > > > installations(one acting as server, the others as client). It works > > > > > very similar to sebastians solution (but without the possibility of > > > > > reducing the screen dimension), but seems to be very performant and > > > > > providing a high quality.. > > > > > => looks interesting. What we could use from that is the > > ZIP-compression at > > > > least. But what they use is RMI. That means its also no real streaming > > isn't > > > > it? Or can you send a constant stream over RMI? > > > > > > see ya > > > > > > Smoeker > > > > > -- > > > > Sebastian > > Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp://... > > > > seba.wag...@gmail.com- Zitierten Text ausblenden - > > > > - Zitierten Text anzeigen - > > -- > Sebastian > Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp://www.laszlo-forum.de > seba.wag...@gmail.com- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OpenMeetings User" group. To post to this group, send email to openmeetings-user@googlegroups.com To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en -~--~~~~--~~--~--~---
Re: ScreenSharer issues
instead of RFB ... implementation would be nice but I think for the moment RTP would be more interesting? I mean if the red5-server could read and re-broadcast RFB... that would be perfect. But as RFB is no multi-media format I am not sure how this should work. I think RFB allows multiple encodings inside. But the question would be how to parse these things out of RFB. sebastian 2009/1/28 smoeker > > ...by the way - some info stuff... > > -> http://jrdesktop.sourceforge.net/ as alternative on clientside > -> http://www.realvnc.com/docs/rfbproto.pdf the RFB Protocol that > would cause changes also on serverside... > > > see ya > > Smoeker > > > > On 28 Jan., 11:07, smoeker wrote: > > hi sebastian, > > > > thnx for your quick reply! > > > > i dont think, the streaming via RMI would work ;-) > > > > i think, the best quality could be reached by real streaming via > > platform independent RFP, but it would cause massive changes on OM > > serverside, i think. > > > > so i would prefer an enhancement of the current solution, so as > > implementing a customized jrdesktop - client as screensharer, that > > sends the jpegs in the format, the OM Server needs. > > (enhancement could be a bettter quality and a higher interval...) > > > > see ya > > > > Smoeker > > > > On 28 Jan., 09:56, Sebastian Wagner wrote: > > > > > > > > > hi, > > > > > 2009/1/28 smoeker > > > > > > hi there, > > > > > > The implemented ScreenViewer seems to be a quite resource saving > > > > solution to share ones screen, but unfortunately it seems to work > > > > quite slow and the ScreenCapture is quite unsharp > > > > > > -> i would like to help optimizing the feature, but before opening an > > > > issue in the DEV - Zone, i would like to > > > > hear about experiences about that topic. > > > > > > -> Regarding the code, i saw, that every 3 seconds a snapshot is > taken > > > > and sent to the ScreenServlet, posting a new slide to the whiteboard > - > > > > are there known problems increasing the interval? > > > > > => yes more bandwidth is needed. You have to load all screens using > red5 as > > > proxy. As you cannot load anything directly from one Client to another. > > > > > > -> i am not too familiar with the known Remote Protocols (RDP, > RFP,..) > > > > - maybe there are already native ways to combine it with the given > > > > architecture, so it would be possible to "stream" the desktop content > > > > into the whiteboard? > > > > > => Yes what needs to be done would be to create RTP stream out of > > > screen-images and the Plugin that stream into red5 sothat it can > > > re-broadcast that > > > > > > -> as alternative i just evluated jrdesktop, a small open source > > > > alternative using RMI to communicate between two > > > > installations(one acting as server, the others as client). It works > > > > very similar to sebastians solution (but without the possibility of > > > > reducing the screen dimension), but seems to be very performant and > > > > providing a high quality.. > > > > > => looks interesting. What we could use from that is the > ZIP-compression at > > > least. But what they use is RMI. That means its also no real streaming > isn't > > > it? Or can you send a constant stream over RMI? > > > > > > see ya > > > > > > Smoeker > > > > > -- > > > Sebastian > Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp://... > > > seba.wag...@gmail.com- Zitierten Text ausblenden - > > > > - Zitierten Text anzeigen - > > > -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.laszlo-forum.de seba.wag...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OpenMeetings User" group. To post to this group, send email to openmeetings-user@googlegroups.com To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en -~--~~~~--~~--~--~---
Re: ScreenSharer issues
...by the way - some info stuff... -> http://jrdesktop.sourceforge.net/ as alternative on clientside -> http://www.realvnc.com/docs/rfbproto.pdf the RFB Protocol that would cause changes also on serverside... see ya Smoeker On 28 Jan., 11:07, smoeker wrote: > hi sebastian, > > thnx for your quick reply! > > i dont think, the streaming via RMI would work ;-) > > i think, the best quality could be reached by real streaming via > platform independent RFP, but it would cause massive changes on OM > serverside, i think. > > so i would prefer an enhancement of the current solution, so as > implementing a customized jrdesktop - client as screensharer, that > sends the jpegs in the format, the OM Server needs. > (enhancement could be a bettter quality and a higher interval...) > > see ya > > Smoeker > > On 28 Jan., 09:56, Sebastian Wagner wrote: > > > > > hi, > > > 2009/1/28 smoeker > > > > hi there, > > > > The implemented ScreenViewer seems to be a quite resource saving > > > solution to share ones screen, but unfortunately it seems to work > > > quite slow and the ScreenCapture is quite unsharp > > > > -> i would like to help optimizing the feature, but before opening an > > > issue in the DEV - Zone, i would like to > > > hear about experiences about that topic. > > > > -> Regarding the code, i saw, that every 3 seconds a snapshot is taken > > > and sent to the ScreenServlet, posting a new slide to the whiteboard - > > > are there known problems increasing the interval? > > > => yes more bandwidth is needed. You have to load all screens using red5 as > > proxy. As you cannot load anything directly from one Client to another. > > > > -> i am not too familiar with the known Remote Protocols (RDP, RFP,..) > > > - maybe there are already native ways to combine it with the given > > > architecture, so it would be possible to "stream" the desktop content > > > into the whiteboard? > > > => Yes what needs to be done would be to create RTP stream out of > > screen-images and the Plugin that stream into red5 sothat it can > > re-broadcast that > > > > -> as alternative i just evluated jrdesktop, a small open source > > > alternative using RMI to communicate between two > > > installations(one acting as server, the others as client). It works > > > very similar to sebastians solution (but without the possibility of > > > reducing the screen dimension), but seems to be very performant and > > > providing a high quality.. > > > => looks interesting. What we could use from that is the ZIP-compression at > > least. But what they use is RMI. That means its also no real streaming isn't > > it? Or can you send a constant stream over RMI? > > > > see ya > > > > Smoeker > > > -- > > Sebastian > > Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp://... > > seba.wag...@gmail.com- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OpenMeetings User" group. To post to this group, send email to openmeetings-user@googlegroups.com To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en -~--~~~~--~~--~--~---
Re: ScreenSharer issues
hi sebastian, thnx for your quick reply! i dont think, the streaming via RMI would work ;-) i think, the best quality could be reached by real streaming via platform independent RFP, but it would cause massive changes on OM serverside, i think. so i would prefer an enhancement of the current solution, so as implementing a customized jrdesktop - client as screensharer, that sends the jpegs in the format, the OM Server needs. (enhancement could be a bettter quality and a higher interval...) see ya Smoeker On 28 Jan., 09:56, Sebastian Wagner wrote: > hi, > > 2009/1/28 smoeker > > > > > hi there, > > > The implemented ScreenViewer seems to be a quite resource saving > > solution to share ones screen, but unfortunately it seems to work > > quite slow and the ScreenCapture is quite unsharp > > > -> i would like to help optimizing the feature, but before opening an > > issue in the DEV - Zone, i would like to > > hear about experiences about that topic. > > > -> Regarding the code, i saw, that every 3 seconds a snapshot is taken > > and sent to the ScreenServlet, posting a new slide to the whiteboard - > > are there known problems increasing the interval? > > => yes more bandwidth is needed. You have to load all screens using red5 as > proxy. As you cannot load anything directly from one Client to another. > > > > > -> i am not too familiar with the known Remote Protocols (RDP, RFP,..) > > - maybe there are already native ways to combine it with the given > > architecture, so it would be possible to "stream" the desktop content > > into the whiteboard? > > => Yes what needs to be done would be to create RTP stream out of > screen-images and the Plugin that stream into red5 sothat it can > re-broadcast that > > > > > -> as alternative i just evluated jrdesktop, a small open source > > alternative using RMI to communicate between two > > installations(one acting as server, the others as client). It works > > very similar to sebastians solution (but without the possibility of > > reducing the screen dimension), but seems to be very performant and > > providing a high quality.. > > => looks interesting. What we could use from that is the ZIP-compression at > least. But what they use is RMI. That means its also no real streaming isn't > it? Or can you send a constant stream over RMI? > > > > > see ya > > > Smoeker > > -- > Sebastian > Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp://www.laszlo-forum.de > seba.wag...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OpenMeetings User" group. To post to this group, send email to openmeetings-user@googlegroups.com To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en -~--~~~~--~~--~--~---
Re: ScreenSharer issues
hi, 2009/1/28 smoeker > > hi there, > > The implemented ScreenViewer seems to be a quite resource saving > solution to share ones screen, but unfortunately it seems to work > quite slow and the ScreenCapture is quite unsharp > > -> i would like to help optimizing the feature, but before opening an > issue in the DEV - Zone, i would like to > hear about experiences about that topic. > > -> Regarding the code, i saw, that every 3 seconds a snapshot is taken > and sent to the ScreenServlet, posting a new slide to the whiteboard - > are there known problems increasing the interval? => yes more bandwidth is needed. You have to load all screens using red5 as proxy. As you cannot load anything directly from one Client to another. > > > -> i am not too familiar with the known Remote Protocols (RDP, RFP,..) > - maybe there are already native ways to combine it with the given > architecture, so it would be possible to "stream" the desktop content > into the whiteboard? => Yes what needs to be done would be to create RTP stream out of screen-images and the Plugin that stream into red5 sothat it can re-broadcast that > > > -> as alternative i just evluated jrdesktop, a small open source > alternative using RMI to communicate between two > installations(one acting as server, the others as client). It works > very similar to sebastians solution (but without the possibility of > reducing the screen dimension), but seems to be very performant and > providing a high quality.. => looks interesting. What we could use from that is the ZIP-compression at least. But what they use is RMI. That means its also no real streaming isn't it? Or can you send a constant stream over RMI? > > > see ya > > Smoeker > > > -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.laszlo-forum.de seba.wag...@gmail.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OpenMeetings User" group. To post to this group, send email to openmeetings-user@googlegroups.com To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en -~--~~~~--~~--~--~---
