Use desktop streaming features with a big screen consumes a lot of memory. Lubomir suggests offline to use a PullBufferDataSource/Stream rather than a PushBufferDataSource/Stream to avoid more big allocations.
Here some statistics about CPU and memory usage on a Debian GNU/Linux x86-64 running latest trunk with only one peer that stream its 1280x800 desktop.
CPU: between 74% and 80%
RAM: ~533 Mo
A prototype of "Pull" desktop streaming device has been implemented, and here the results:
CPU: between 70% and 80%
RAM: ~269 Mo then drops to ~229,6 Mo 2-3 minutes after
To compare with webcam (lti-civil linux):
CPU: between 64% and 72%
RAM: ~310,4 Mo
The major changes are in ImageStream class which not longer spawn a thread (to grab screen), in fact all is done in the read(Buffer buf) method.
We check if buf contains a valid data object (getData()) and if its length is sufficient to contains screen (otherwise we use our own allocated buffer). Normally first time read is called, buf's data has a size of 500, but in the next call data has the right size (I think it reuse our allocated buffer). We try to respect a 10 frames per second (hardcoded for the moment) so we sleep time needed to respect frame rate after capture (approximately the read method is called every 70 - 80 milliseconds on Linux). Note with no sleep java process eat arround 90-92% (in SIP session with H264 encoding).
Other changes includes addition of AbstractPullBufferCaptureDevice and AbstractPullBufferStream classes but I simply copy/paste/adapt from AbstractPushBufferCaptureDevice/Stream, maybe it is not good (copy/paste is evil) but the Pull/Push* interfaces looks very similar. Maybe implement interfaces needed in DataSource and ImageStream like in PortAudio DataSource would be another solution. WDYT
Other thing, I remark local video is missing (error when creating the SourceCloneable).