Last week, I finally manage to have something working.
Here are files added:
=> utils methods for image conversion, resize, ...
=> interface that wrap methods from java.awt.Robot
=> DesktopInteract implementation that uses java.awt.Robot
=> Data source for "imgstreaming" protocol
=> Image stream
=> Add image streaming capture device to JMF
=> call new ImageStreamingAuto()
Technically for the moment it uses java.awt.Robot to capture screen every 500 ms. For desktop streaming, refresh result is (I think) quite acceptable.
I tested on Linux Debian 64-bit and Windows 7 64-bit. This week I will have a Macbook (normally) so I could test also with it.
- Media configuration panel with preview the CPU is arround 24-30% (knowing that my webcam with preview => CPU arround 18%).
- When we move a window, during the "screenshot", the desktop "freeze" a little bit which is embarassing.
- Media configuration panel with preview the CPU is arround 5%;
- Moving window, CPU is arround 20%.
I have also see how OpenJDK take screen capture in Unix, it uses XGetImage which is very slow and the reasons of the "freeze" is because XGrabServer/XUnGrabServer. I have already begin writting code that uses XShmGetImage (which is more faster) and fallback to XGetImage when SHM is not available.
I will commit it this week (when my commit rights will be granted) but disabled by default (to not propose image/desktop streaming in media configuration panel). I plan to add a command line argument to enable it (--desktop-streaming or something like that). WDYT ?
Sebastien Vincent a écrit :
Damian Minkov a écrit :
On Thu, Dec 3, 2009 at 5:50 PM, Sebastien Vincent >>> <email@example.com> wrote:
I am working on a desktop streaming/sharing implementation in
I think about adding a "special" capture device into neomedia for that to
provide images from the desktop (or a single static image) to preview
(configuration panel) or for a SIP call.
After reading stuff arround neomedia and JMF, JMF's Manager.createDataSource
returns non-null value if it found a class that can handle the
MediaLocator's protocol (i.e. portaudio, civil, ...) in
<package-prefix>.media.protocol.<protocol_we_want_to_handle> right ? (the
package-prefix are added in the JMF's PackageManager, for example
package-prefix for fmj and portaudio are added in
Yes that's right. That is exactly how portaudio is currently working.
So to provide such a device in SC, we should have a package named
....impl.neomedia.jmfext.media.protocol.desktopstreaming (or imgstreaming,
...) and an implementation of DataSource (mandatory named DataSource.java)
and Stream in it. Am I correct ?
Yes. Yes you can take a look and at PortaudioAuto class as there are
defined multiple CaptureDevices that corresponds to the different
devices reported by the portaudio. And all of them have the same
protocol part in their MediaLocators(portaudio://) and so they all
come to the same Datasource, which is located in the java package
containing the protocol name :
OK. We could have locators for desktop streaming (imgstreaming://desktop) and single image (imgstreaming://image).
To get images from the desktop I will use java.awt.Robot to get desktop
images and later optimize...
As I think the Robot is little slower you can try starting with it but
the optimization will be the big part
OK. I will study in details how Java VNC/Rdesktop clients do it (jrdesktop and robo use java.awt.Robot).
At last resort we could also propose to go native and implement X11, Win32 and Carbon/Cocoa desktop capture if Robot performance does not satisfy us.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com