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
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
...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 o.beche...@medint.de wrote:
hi
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
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
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
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
