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 <seba.wag...@gmail.com> wrote: > hi, > > 2009/1/29 smoeker <o.beche...@medint.de> > > > > > 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 <seba.wag...@gmail.com> 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 <seba.wag...@gmail.com> > > > > > 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 <o.beche...@medint.de> > > > > >> 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 <seba.wag...@gmail.com> 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 <o.beche...@medint.de> > > > > >> > > 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 <seba.wag...@gmail.com> > > 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 <o.beche...@medint.de> > > > > >> > > > > ...by the way - some info stuff... > > > > >> > > > > ->http://jrdesktop.sourceforge.net/asalternativeonclientside > > > >> > > > > ->http://www.realvnc.com/docs/rfbproto.pdftheRFBProtocolthat > > > >> > > > > would cause changes also on serverside... > > > > >> > > > > see ya > > > > >> > > > > Smoeker > > > > >> > > > > On 28 Jan., 11:07, smoeker <o.beche...@medint.de> 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 <seba.wag...@gmail.com> > > > >> wrote: > > > > >> > > > > > > hi, > > > > >> > > > > > > 2009/1/28 smoeker <o.beche...@medint.de> > > > > >> > > > > > > > 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 - > > > > >> > -- > > > >> > Sebastian > > > Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp:// > > > >>www.laszlo-forum.de > > > >> > seba.wag...@gmail.com- Zitierten Text ausblenden - > > > > >> > - Zitierten Text anzeigen - > > > > > -- > > > > Sebastian Wagner > > > >http://www.webbase-design.de > > > >http://openmeetings.googlecode.com > > ... > > Erfahren Sie mehr ยป- 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 -~----------~----~----~----~------~----~------~--~---
