[sip-comm-dev] Provide image streaming devices in neomedia


#1

Hi all,

I am working on a desktop streaming/sharing implementation in sip-communicator.

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 neomedia.codec.EncodingConfiguration.java).

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 ?

To get images from the desktop I will use java.awt.Robot to get desktop images and later optimize...

If you have other ideas to provide image streaming in neomedia, please let me know.

Best regards,

···

--
Sebastien Vincent

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi,

Hi all,

I am working on a desktop streaming/sharing implementation in
sip-communicator.

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.

Great!

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
neomedia.codec.EncodingConfiguration.java).

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 :
<package-prefix>.media.protocol.portaudio.DataSource.

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 :slight_smile:

Cheers
damencho

···

On Thu, Dec 3, 2009 at 5:50 PM, Sebastien Vincent <sebastien.vincent@cppextrem.com> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Seb,

I'm further refactorying the imgstreaming DataSource and ImageStream
in order to extend them from a more general hierarchy which I use for
my QTKit CaptureDevice.

I just noticed in the code that the FormatControl of DataSource
reports the format to be formats[0] while the ImageStream is
initialized with and indeed uses formats[5]. The former is with
Dimension 128x96 and the latter is with Dimension 720x480. Am I right
in my observation and should one and the same Dimension value be
reported? If the code is indeed incorrect, please don't fix it and
just let me know here which Dimension value is to be used because I
have a lot of changes the imgstreaming classes and I'll have to merge.

Thank you,
Lubo

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi,

Damian Minkov a écrit :

Hi,

Hi all,

I am working on a desktop streaming/sharing implementation in
sip-communicator.

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.
    
Great!

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
neomedia.codec.EncodingConfiguration.java).
    
Yes that's right. That is exactly how portaudio is currently working.

OK.

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 :
<package-prefix>.media.protocol.portaudio.DataSource.
  
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 :slight_smile:
  
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.

Regards,

···

On Thu, Dec 3, 2009 at 5:50 PM, Sebastien Vincent > <sebastien.vincent@cppextrem.com> wrote:

--
Sebastien

Cheers
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Lubomir,

Lubomir Marinov a �crit :

Hi Seb,

I'm further refactorying the imgstreaming DataSource and ImageStream
in order to extend them from a more general hierarchy which I use for
my QTKit CaptureDevice.
  
OK good.

I just noticed in the code that the FormatControl of DataSource
reports the format to be formats[0] while the ImageStream is
initialized with and indeed uses formats[5]. The former is with
Dimension 128x96 and the latter is with Dimension 720x480. Am I right
in my observation and should one and the same Dimension value be
reported? If the code is indeed incorrect, please don't fix it and
just let me know here which Dimension value is to be used because I
have a lot of changes the imgstreaming classes and I'll have to merge.

Oh good catch, set the two with the same value, let say the higher 720x480.

···

Thank you,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Seb,

I think r6584 fixes the inconsistent reporting of the Format
Dimension. It got me thinking though and I hope you have the following
planned for future development:

- Why doesn't it preserve the aspect ratio of the screen capture? I
think that text is a major part of the image to be conveyed when
streaming a desktop and fonts easily get hard to read when scaled,
even more so when the aspect ratio is not preserved. If I had to
choose only one, I'd say imgstreaming that scales the desktop into a
rectangle by preserving the aspect ratio and leaving black borders is
better than one that does not preserve the aspect ratio and fills the
whole rectangle.

- Why does it advertise specific Dimensions up to 720x480? For what
it's worth, most modern desktops will more often than not be of
Dimensions larger than that. The present imgstreaming already does
scaling so why cannot it do it to arbitrary sizes? I think that if
there's a Dimension to be advertised, its the actual desktop Dimension
because it provides a screen capture with the best image quality. But
even if we don't think so, we have to acknowledge that there are other
codecs in the chain after the CaptureDevice and they may impose
different Dimensions which will cause JMF to insert an image scaler in
the chain and thus there will be at least two scaling operations.

Regards,
Lubo

···

On Fri, Jan 8, 2010 at 3:24 PM, Sebastien Vincent <seb@sip-communicator.org> wrote:

Hi Lubomir,

Lubomir Marinov a écrit :

Hi Seb,

I'm further refactorying the imgstreaming DataSource and ImageStream
in order to extend them from a more general hierarchy which I use for
my QTKit CaptureDevice.

OK good.

I just noticed in the code that the FormatControl of DataSource
reports the format to be formats[0] while the ImageStream is
initialized with and indeed uses formats[5]. The former is with
Dimension 128x96 and the latter is with Dimension 720x480. Am I right
in my observation and should one and the same Dimension value be
reported? If the code is indeed incorrect, please don't fix it and
just let me know here which Dimension value is to be used because I
have a lot of changes the imgstreaming classes and I'll have to merge.

Oh good catch, set the two with the same value, let say the higher 720x480.

Thank you,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi,

Last week, I finally manage to have something working.

Here are files added:

···

- net.java.sip.communicator.impl.neomedia.imgstreaming.ImageStreamingUtils.java
=> utils methods for image conversion, resize, ...
- net.java.sip.communicator.impl.neomedia.imgstreaming.DesktopInteract.java
=> interface that wrap methods from java.awt.Robot
- net.java.sip.communicator.impl.neomedia.imgstreaming.RobotDesktopInteractImpl.java
=> DesktopInteract implementation that uses java.awt.Robot
- net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.DataSource.java
=> Data source for "imgstreaming" protocol
- net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.ImageStream.java
=> Image stream
- net.java.sip.communicator.impl.neomedia.device.ImageStreamingAuto.java
=> Add image streaming capture device to JMF

File(s) modified:
- net.java.sip.communicator.impl.neomedia.device.JmfDetector.java
=> 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.

For Linux:
- 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.

For Windows:
- 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 ?

Best regards,
--
Sebastien

Sebastien Vincent a écrit :

Hi,

Damian Minkov a écrit :

Hi,

On Thu, Dec 3, 2009 at 5:50 PM, Sebastien Vincent >> <sebastien.vincent@cppextrem.com> wrote:

Hi all,

I am working on a desktop streaming/sharing implementation in
sip-communicator.

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.
    
Great!

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
neomedia.codec.EncodingConfiguration.java).
    
Yes that's right. That is exactly how portaudio is currently working.

OK.

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 :
<package-prefix>.media.protocol.portaudio.DataSource.
  
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 :slight_smile:
  
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.

Regards,
--
Sebastien

Cheers
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi Lubomir,

Lubomir Marinov a �crit :

Hi Seb,

I think r6584 fixes the inconsistent reporting of the Format
Dimension.

Thanks!

It got me thinking though and I hope you have the following
planned for future development:

- Why doesn't it preserve the aspect ratio of the screen capture? I
think that text is a major part of the image to be conveyed when
streaming a desktop and fonts easily get hard to read when scaled,
even more so when the aspect ratio is not preserved. If I had to
choose only one, I'd say imgstreaming that scales the desktop into a
rectangle by preserving the aspect ratio and leaving black borders is
better than one that does not preserve the aspect ratio and fills the
whole rectangle.
  
Yes it miss this feature.

- Why does it advertise specific Dimensions up to 720x480? For what
it's worth, most modern desktops will more often than not be of
Dimensions larger than that. The present imgstreaming already does
scaling so why cannot it do it to arbitrary sizes? I think that if
there's a Dimension to be advertised, its the actual desktop Dimension
because it provides a screen capture with the best image quality. But
even if we don't think so, we have to acknowledge that there are other
codecs in the chain after the CaptureDevice and they may impose
different Dimensions which will cause JMF to insert an image scaler in
the chain and thus there will be at least two scaling operations.

I hardcoded dimensions just to test DataSource/Stream as in the beginning of work my knowledge in JMF stuff was very low.
But I agree it is better to advertise the current desktop size on the fly.

I can take care both things this week I think.

···

--
Seb

Regards,
Lubo

On Fri, Jan 8, 2010 at 3:24 PM, Sebastien Vincent > <seb@sip-communicator.org> wrote:
  

Hi Lubomir,

Lubomir Marinov a �crit :
    

Hi Seb,

I'm further refactorying the imgstreaming DataSource and ImageStream
in order to extend them from a more general hierarchy which I use for
my QTKit CaptureDevice.

OK good.

I just noticed in the code that the FormatControl of DataSource
reports the format to be formats[0] while the ImageStream is
initialized with and indeed uses formats[5]. The former is with
Dimension 128x96 and the latter is with Dimension 720x480. Am I right
in my observation and should one and the same Dimension value be
reported? If the code is indeed incorrect, please don't fix it and
just let me know here which Dimension value is to be used because I
have a lot of changes the imgstreaming classes and I'll have to merge.

Oh good catch, set the two with the same value, let say the higher 720x480.

Thank you,
Lubo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi,

"Desktop streaming" device is now commited.

To use it, run SIP Communicator with --desktop-stream argument. You will find "Desktop streaming" in available video devices combobox and use it instead of your webcam.

Please note that it is just for testing purposes. In a future revision, We will find a better place to handle "desktop streaming" than in video devices combobox.

Feedbacks are welcome.

Regards,

···

--
Seb

Sebastien Vincent a écrit :

Hi,

Last week, I finally manage to have something working.

Here are files added:
- net.java.sip.communicator.impl.neomedia.imgstreaming.ImageStreamingUtils.java

=> utils methods for image conversion, resize, ...
- net.java.sip.communicator.impl.neomedia.imgstreaming.DesktopInteract.java
=> interface that wrap methods from java.awt.Robot
- net.java.sip.communicator.impl.neomedia.imgstreaming.RobotDesktopInteractImpl.java

=> DesktopInteract implementation that uses java.awt.Robot
- net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.DataSource.java

=> Data source for "imgstreaming" protocol
- net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.ImageStream.java

=> Image stream
- net.java.sip.communicator.impl.neomedia.device.ImageStreamingAuto.java
=> Add image streaming capture device to JMF

File(s) modified:
- net.java.sip.communicator.impl.neomedia.device.JmfDetector.java
=> 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.

For Linux:
- 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.

For Windows:
- 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 ?

Best regards,
--
Sebastien

Sebastien Vincent a écrit :

Hi,

Damian Minkov a écrit :

Hi,

On Thu, Dec 3, 2009 at 5:50 PM, Sebastien Vincent >>> <sebastien.vincent@cppextrem.com> wrote:

Hi all,

I am working on a desktop streaming/sharing implementation in
sip-communicator.

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.
    
Great!

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
neomedia.codec.EncodingConfiguration.java).
    
Yes that's right. That is exactly how portaudio is currently working.

OK.

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 :
<package-prefix>.media.protocol.portaudio.DataSource.
  
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 :slight_smile:
  
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.

Regards,
--
Sebastien

Cheers
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hi Seb,

I've been looking at the imgstreaming DataSource and ImageStream because I'm creating a video CaptureDevice using Mac OS X QTKit (because we do not currently have video capture on Snow Leopard) and I'm trying to reuse as much of the existing functionality as possible.

Anyway, I noticed that ImageStream uses a RingBuffer with a size of 5 to queue the screen captures of the captureThread so that they can be read through ImageStream#read(Buffer). Could you please share the reasoning behind its use and the chosen size? I can pretty much figure out that one would want to queue the screen captures in case they are produced faster than they are consumed BUT only in the non-streaming case in which one would want to not drop frames and keep the video smooth and complete. However, I'm not sure about it in our case which is live streaming. I mean if we happen to have multiple screen captures to return from a given call to ImageStream#read(Buffer), why would we want to return any other but the last? Wouldn't we want to always send the most up-to-date frame over the wire? For what it's worth, we'll have multiple screen captures only if the screen captures are produced faster than they are encoded (and sent) and in such a scenario I don't see why we'd want to send out-of-date frames.

Thank you,
Lubo

···

On Dec 16, 2009, at 11:30 AM, Sebastien Vincent wrote:

Hi,

"Desktop streaming" device is now commited.

To use it, run SIP Communicator with --desktop-stream argument. You will find "Desktop streaming" in available video devices combobox and use it instead of your webcam.

Please note that it is just for testing purposes. In a future revision, We will find a better place to handle "desktop streaming" than in video devices combobox.

Feedbacks are welcome.

Regards,
--
Seb

Sebastien Vincent a écrit :

Hi,

Last week, I finally manage to have something working.

Here are files added:
- net.java.sip.communicator.impl.neomedia.imgstreaming.ImageStreamingUtils.java
=> utils methods for image conversion, resize, ...
- net.java.sip.communicator.impl.neomedia.imgstreaming.DesktopInteract.java
=> interface that wrap methods from java.awt.Robot
- net.java.sip.communicator.impl.neomedia.imgstreaming.RobotDesktopInteractImpl.java
=> DesktopInteract implementation that uses java.awt.Robot
- net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.DataSource.java
=> Data source for "imgstreaming" protocol
- net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.ImageStream.java
=> Image stream
- net.java.sip.communicator.impl.neomedia.device.ImageStreamingAuto.java
=> Add image streaming capture device to JMF

File(s) modified:
- net.java.sip.communicator.impl.neomedia.device.JmfDetector.java
=> 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.

For Linux:
- 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.

For Windows:
- 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 ?

Best regards,
--
Sebastien

Sebastien Vincent a écrit :

Hi,

Damian Minkov a écrit :

Hi,

On Thu, Dec 3, 2009 at 5:50 PM, Sebastien Vincent >>>> <sebastien.vincent@cppextrem.com> wrote:

Hi all,

I am working on a desktop streaming/sharing implementation in
sip-communicator.

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.
   
Great!

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
neomedia.codec.EncodingConfiguration.java).
   
Yes that's right. That is exactly how portaudio is currently working.

OK.

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 :
<package-prefix>.media.protocol.portaudio.DataSource.

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 :slight_smile:

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.

Regards,
--
Sebastien

Cheers
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Hi Lubomir,

Yes you're right it was to not loose any frame. I have lookup in the FMJ's civil and I see it uses them so... But I am OK with you, we want the most recent image. So we can remove the use of RingBuffer.

Regards,

···

--
Seb

Lubomir Marinov a écrit :

Hi Seb,

I've been looking at the imgstreaming DataSource and ImageStream because I'm creating a video CaptureDevice using Mac OS X QTKit (because we do not currently have video capture on Snow Leopard) and I'm trying to reuse as much of the existing functionality as possible.

Anyway, I noticed that ImageStream uses a RingBuffer with a size of 5 to queue the screen captures of the captureThread so that they can be read through ImageStream#read(Buffer). Could you please share the reasoning behind its use and the chosen size? I can pretty much figure out that one would want to queue the screen captures in case they are produced faster than they are consumed BUT only in the non-streaming case in which one would want to not drop frames and keep the video smooth and complete. However, I'm not sure about it in our case which is live streaming. I mean if we happen to have multiple screen captures to return from a given call to ImageStream#read(Buffer), why would we want to return any other but the last? Wouldn't we want to always send the most up-to-date frame over the wire? For what it's worth, we'll have multiple screen captures only if the screen captures are produced faster than they are encoded (and sent) and in such a scenario I don't see why we'd want to send out-of-date frames.

Thank you,
Lubo

On Dec 16, 2009, at 11:30 AM, Sebastien Vincent wrote:

Hi,

"Desktop streaming" device is now commited.

To use it, run SIP Communicator with --desktop-stream argument. You will find "Desktop streaming" in available video devices combobox and use it instead of your webcam.

Please note that it is just for testing purposes. In a future revision, We will find a better place to handle "desktop streaming" than in video devices combobox.

Feedbacks are welcome.

Regards,
--
Seb

Sebastien Vincent a écrit :
    

Hi,

Last week, I finally manage to have something working.

Here are files added:
- net.java.sip.communicator.impl.neomedia.imgstreaming.ImageStreamingUtils.java => utils methods for image conversion, resize, ...
- net.java.sip.communicator.impl.neomedia.imgstreaming.DesktopInteract.java
=> interface that wrap methods from java.awt.Robot
- net.java.sip.communicator.impl.neomedia.imgstreaming.RobotDesktopInteractImpl.java => DesktopInteract implementation that uses java.awt.Robot
- net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.DataSource.java => Data source for "imgstreaming" protocol
- net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.ImageStream.java => Image stream
- net.java.sip.communicator.impl.neomedia.device.ImageStreamingAuto.java
=> Add image streaming capture device to JMF

File(s) modified:
- net.java.sip.communicator.impl.neomedia.device.JmfDetector.java
=> 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.

For Linux:
- 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.

For Windows:
- 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 ?

Best regards,
--
Sebastien

Sebastien Vincent a écrit :
      

Hi,

Damian Minkov a écrit :
        

Hi,

On Thu, Dec 3, 2009 at 5:50 PM, Sebastien Vincent >>>>> <sebastien.vincent@cppextrem.com> wrote:

Hi all,

I am working on a desktop streaming/sharing implementation in
sip-communicator.

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.
   

Great!

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
neomedia.codec.EncodingConfiguration.java).
   

Yes that's right. That is exactly how portaudio is currently working.

OK.

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 :
<package-prefix>.media.protocol.portaudio.DataSource.

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 :slight_smile:

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.

Regards,
--
Sebastien

Cheers
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Thank you!

Another minor violation of the PushBufferStream API due to RingBuffer
is that it will block #read(Buffer) and wait for a screen capture to
arrive which it shouldn't because PushBufferStream is non-blocking and
its #read() should return an empty Buffer if it doesn't have a screen
capture.

···

On Thu, Jan 7, 2010 at 1:04 PM, Sebastien Vincent <seb@sip-communicator.org> wrote:

Hi Lubomir,

Yes you're right it was to not loose any frame. I have lookup in the FMJ's
civil and I see it uses them so... But I am OK with you, we want the most
recent image. So we can remove the use of RingBuffer.

Regards,
--
Seb

Lubomir Marinov a écrit :

Hi Seb,

I've been looking at the imgstreaming DataSource and ImageStream because
I'm creating a video CaptureDevice using Mac OS X QTKit (because we do not
currently have video capture on Snow Leopard) and I'm trying to reuse as
much of the existing functionality as possible.
Anyway, I noticed that ImageStream uses a RingBuffer with a size of 5 to
queue the screen captures of the captureThread so that they can be read
through ImageStream#read(Buffer). Could you please share the reasoning
behind its use and the chosen size? I can pretty much figure out that one
would want to queue the screen captures in case they are produced faster
than they are consumed BUT only in the non-streaming case in which one would
want to not drop frames and keep the video smooth and complete. However, I'm
not sure about it in our case which is live streaming. I mean if we happen
to have multiple screen captures to return from a given call to
ImageStream#read(Buffer), why would we want to return any other but the
last? Wouldn't we want to always send the most up-to-date frame over the
wire? For what it's worth, we'll have multiple screen captures only if the
screen captures are produced faster than they are encoded (and sent) and in
such a scenario I don't see why we'd want to send out-of-date frames.

Thank you,
Lubo

On Dec 16, 2009, at 11:30 AM, Sebastien Vincent wrote:

Hi,

"Desktop streaming" device is now commited.

To use it, run SIP Communicator with --desktop-stream argument. You will
find "Desktop streaming" in available video devices combobox and use it
instead of your webcam.

Please note that it is just for testing purposes. In a future revision,
We will find a better place to handle "desktop streaming" than in video
devices combobox.

Feedbacks are welcome.

Regards,
--
Seb

Sebastien Vincent a écrit :

Hi,

Last week, I finally manage to have something working.

Here are files added:
-
net.java.sip.communicator.impl.neomedia.imgstreaming.ImageStreamingUtils.java
=> utils methods for image conversion, resize, ...
-
net.java.sip.communicator.impl.neomedia.imgstreaming.DesktopInteract.java
=> interface that wrap methods from java.awt.Robot
-
net.java.sip.communicator.impl.neomedia.imgstreaming.RobotDesktopInteractImpl.java
=> DesktopInteract implementation that uses java.awt.Robot
-
net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.DataSource.java
=> Data source for "imgstreaming" protocol
-
net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.ImageStream.java
=> Image stream
- net.java.sip.communicator.impl.neomedia.device.ImageStreamingAuto.java
=> Add image streaming capture device to JMF

File(s) modified:
- net.java.sip.communicator.impl.neomedia.device.JmfDetector.java
=> 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.

For Linux:
- 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.

For Windows:
- 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 ?

Best regards,
--
Sebastien

Sebastien Vincent a écrit :

Hi,

Damian Minkov a écrit :

Hi,

On Thu, Dec 3, 2009 at 5:50 PM, Sebastien Vincent >>>>>> <sebastien.vincent@cppextrem.com> wrote:

Hi all,

I am working on a desktop streaming/sharing implementation in
sip-communicator.

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.

Great!

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
neomedia.codec.EncodingConfiguration.java).

Yes that's right. That is exactly how portaudio is currently working.

OK.

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 :
<package-prefix>.media.protocol.portaudio.DataSource.

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 :slight_smile:

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.

Regards,
--
Sebastien

Cheers
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

Changes commited in revision 6577.

Lubomir Marinov a �crit :

···

Thank you!

Another minor violation of the PushBufferStream API due to RingBuffer
is that it will block #read(Buffer) and wait for a screen capture to
arrive which it shouldn't because PushBufferStream is non-blocking and
its #read() should return an empty Buffer if it doesn't have a screen
capture.

On Thu, Jan 7, 2010 at 1:04 PM, Sebastien Vincent > <seb@sip-communicator.org> wrote:
  

Hi Lubomir,

Yes you're right it was to not loose any frame. I have lookup in the FMJ's
civil and I see it uses them so... But I am OK with you, we want the most
recent image. So we can remove the use of RingBuffer.

Regards,
--
Seb

Lubomir Marinov a �crit :
    

Hi Seb,

I've been looking at the imgstreaming DataSource and ImageStream because
I'm creating a video CaptureDevice using Mac OS X QTKit (because we do not
currently have video capture on Snow Leopard) and I'm trying to reuse as
much of the existing functionality as possible.
Anyway, I noticed that ImageStream uses a RingBuffer with a size of 5 to
queue the screen captures of the captureThread so that they can be read
through ImageStream#read(Buffer). Could you please share the reasoning
behind its use and the chosen size? I can pretty much figure out that one
would want to queue the screen captures in case they are produced faster
than they are consumed BUT only in the non-streaming case in which one would
want to not drop frames and keep the video smooth and complete. However, I'm
not sure about it in our case which is live streaming. I mean if we happen
to have multiple screen captures to return from a given call to
ImageStream#read(Buffer), why would we want to return any other but the
last? Wouldn't we want to always send the most up-to-date frame over the
wire? For what it's worth, we'll have multiple screen captures only if the
screen captures are produced faster than they are encoded (and sent) and in
such a scenario I don't see why we'd want to send out-of-date frames.

Thank you,
Lubo

On Dec 16, 2009, at 11:30 AM, Sebastien Vincent wrote:

Hi,

"Desktop streaming" device is now commited.

To use it, run SIP Communicator with --desktop-stream argument. You will
find "Desktop streaming" in available video devices combobox and use it
instead of your webcam.

Please note that it is just for testing purposes. In a future revision,
We will find a better place to handle "desktop streaming" than in video
devices combobox.

Feedbacks are welcome.

Regards,
--
Seb

Sebastien Vincent a �crit :

Hi,

Last week, I finally manage to have something working.

Here are files added:
-
net.java.sip.communicator.impl.neomedia.imgstreaming.ImageStreamingUtils.java
=> utils methods for image conversion, resize, ...
-
net.java.sip.communicator.impl.neomedia.imgstreaming.DesktopInteract.java
=> interface that wrap methods from java.awt.Robot
-
net.java.sip.communicator.impl.neomedia.imgstreaming.RobotDesktopInteractImpl.java
=> DesktopInteract implementation that uses java.awt.Robot
-
net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.DataSource.java
=> Data source for "imgstreaming" protocol
-
net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.imgstreaming.ImageStream.java
=> Image stream
- net.java.sip.communicator.impl.neomedia.device.ImageStreamingAuto.java
=> Add image streaming capture device to JMF

File(s) modified:
- net.java.sip.communicator.impl.neomedia.device.JmfDetector.java
=> 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.

For Linux:
- 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.

For Windows:
- 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 ?

Best regards,
--
Sebastien

Sebastien Vincent a �crit :

Hi,

Damian Minkov a �crit :

Hi,

On Thu, Dec 3, 2009 at 5:50 PM, Sebastien Vincent >>>>>>> <sebastien.vincent@cppextrem.com> wrote:

Hi all,

I am working on a desktop streaming/sharing implementation in
sip-communicator.

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.

Great!

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
neomedia.codec.EncodingConfiguration.java).

Yes that's right. That is exactly how portaudio is currently working.

OK.

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 :
<package-prefix>.media.protocol.portaudio.DataSource.

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 :slight_smile:

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.

Regards,
--
Sebastien

Cheers
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail:
dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net