Thank you for taking the initiative to notify the SIP Communicator
developer community about your progress! I agree the project you've
been part of this Google Summer of Code deserves the attention because
it opens SIP Communicator to a whole new use case with the desktop
streaming feature it enables.
As I was your backup mentor for three days, I hope you will not mind
me sharing my opinion about the current state of this project.
Sooner or later performance becomes important to software development
and in the case of video, on-the-fly encoding, streaming I think it
does sooner rather than later. Because streaming the desktop is rather
a means than an end, I believe its usability is strongly affected by
the frequency of the update of the desktop image and the performance
impact on the serving machine. In line with the performance
requirement, you were given the task to modify the desktop DataSource
to push desktop images as frequently as possible given that the
procedure capturing the desktop images is relatively slow.
Technically, this meant that you had to make the desktop DataSource
(1) push via the Robot thread as soon as the Robot had acquired the
desktop image and (2) provide each desktop image only once. As I see
your code now, I don't think it has accomplished this task: it still
uses a separate thread to push at a hardcoded interval of time
regardless of the speed at which the Robot produces data, the desktop
image data may still be pushed multiple times, the Robot thread even
sleeps before each desktop-capturing iteration though it executes the
two slowest methods (capturing the desktop and translating the image
to the data format suitable for the DataSource). I believe we still
need this task carried out. Otherwise, we get a hardcoded framerate
which isn't really accurate because the Robot performs differently not
only on different operating systems but also on different hardware
platforms, we may encode and send one and the same desktop image
multiple times and we have a suboptimal capturing of the desktop.
We also have the requirement for code submitted for integration in our
code base to be formatted according to the code conventions published
at sip-communicator.org. This convention covers the import statements
which has to import all classes in a package and not specific classes,
the placement of the curly braces, the formatting of the Javadoc
comments as our convention extends the coding guidelines given by Sun,
etc. I remember the formatting to be one of the tasks Damian Minkov
had explicitly required from you.
As I mentioned in one of my letters to you, I think that the quality
of the streamed desktop is heavily impacted by the lack of
preservation of the aspect ratio. I'll let your mentor and Emil speak
whether it is really required for the success of this project but I
personally find it pretty important for the perception of true desktop
During my tests of your implementation, I couldn't help but notice
that it was heavy not only on the CPU but also on the memory. Quickly
looking at your code, I got the impression that the Robot thread for
example keeps a reference to the desktop Image which it only needs it
temporary to translate it to byte. I may as well be wrong here so
take my observation with a large grain of salt. But should it be true,
I'm asking whether the development of this project as we see it today
includes work on improving the memory performance.
Please take the above comments as my point of view, especially where
I'm not repeating tasks explicitly given by your mentor(s). I
personally think that the desktop streaming feature is very
encouraging but it still needs development to reach the maturity
expected of it at the end of Google Summer of Code.
On Fri, Aug 14, 2009 at 5:43 PM, camille kurtz<email@example.com> wrote:
Hi all SIP-communicator developpers,
Just some news concerning the GSOC 09 project : Replace a Webcam by a
The branch link is :
The aim of this project was to add the possibility for SIP-commincator users
to replace a Webcam by an image from
the Media Configuration Panel.
With the help of my tutors, we have add this possibility. It's now possible
to replace a webcam by a "fake device".
This fake device could be :
->An avatar choosed randomly from all the avatars available.
->A file (jpeg, png, tiff)
->The desktop streaming
The user can choose a resolution for the images that he wants to stream.
Concerning the codecs for transmission, the fake device is compatible with
H263 and H264.
Note : -With H263 only small resolutions could work (352 * 288).
-With H264 and big resolutions there are some problems with old
computers with frame rate.
Thank you everybody and have a nice day!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com