🚀 go-pugleaf

"Robert G. Hoover" <not.a.real.address@anywhere.sorry> wrote in message
news:46b0f5c4$1@newsgroups.borland.com...

> I've got a timing/performance need... I'm trying to capture
> the screen as BMP, compress to JPG, then send over a
> TCustomWinSocket. I'm afraid it just takes too long... :(

You are sending the entire image in full each time.  If you are trying to
implement some kind of real-time video capture of the screen, then you
should be sending deltas instead.  Capture the full image once, send it,
then send only what has changed since the last transmission.  The receiver
can then overlay the deltas on top of each other when they are received.  If
very little changes, then there will be very few transmissions, and you can
probably do away with the JPG conversion altogether (which isn't a good way
to compress BMP anyway since JPG is a lossy format).

> // send image data to client
> SocketOut->SendBuf(WriteStream->Memory, WriteStream->Size);

You are not sending the stream size to the client, so it won't know how many
bytes it needs to read for each image.

> // reset stream for next use
> WriteStream->Clear();

If you are sending images of the same dimensions each time, then you don't
really need to Clear() the stream each time, since the image data is likely
to be the same size the next time around.  Using Clear() will waste time
allocating and freeing the memory over and over.  You could simply reset the
Position back to 0, leaving the memory intact.  The next time you save an
image to the stream, it will overwrite the contents that are already
present.  Since you would start the Position at 0, you could use the
Position to know how many bytes were actually saved, rather than relying on
the Size property.  This way, smaller images can reuse the same stream
memory, and larger images will grow the memory when needed.


Gambit

Hi Robert

I don't know if this is any help at all, but most of the times
GIF is a better format for screen captures it produces smaller files.
Program surfaces usually don't more thatn 256 colors.

There is a gif component at Tory that looks good
TGIFImage v.2.2  Freeware with source:
http://www.torry.net/quicksearchd.php?String="TGIFImage&Title=Yes

Kind regards
Asger

In article <46b0f5c4$1@newsgroups.borland.com>, 
not.a.real.address@anywhere.sorry says...
> Hi All,
> 
> I've got a timing/performance need... I'm trying to capture the screen as BMP,
> compress to JPG, then send over a TCustomWinSocket. I'm afraid it just takes too
> long... :(  Here's what I've got going on...
> 
> ...
> 
> 
> // capture entire screen and copy data to TBitmap
> BitBlt(ImageBMP->Canvas->Handle,
>        0, 0, ImageBMP->Width, ImageBMP->Height,
>        hCaptureDC, 0, 0, SRCCOPY);
> 
> // convert to JPG
> ImageJPG->Assign(ImageBMP);
> 
> // convert to memory stream for sending over socket
> ImageJPG->SaveToStream(WriteStream);
> 
> // disable Nagle algorithm to speed up transmissions???
> TWinSocket_SetSockOpt(SocketOut, IPPROTO_TCP, TCP_NODELAY, 1);
> 
> // send image data to client
> SocketOut->SendBuf(WriteStream->Memory, WriteStream->Size);
> 
> // reset stream for next use
> WriteStream->Clear();
> 
> 
> ...
> 
> 
> So, is there any way to speed up any or all of these operations? It takes (as
> near as I can measure) ~1.5 seconds to send over the data. Any and all advice is
> much appreciated...
> 
> Many thanks!
> 
> Rob
> 

A couple of years ago it was possible to send only some frame (about 4-6) 
per second over a regular dsl connection using mpeg video at 352x288 with 
audio.
Nowdays the bandwidth of of our connection is wider but yet a sequence of 
jpegs at full screen is too much data to send.
Maybe you can try to use some mpeg4 encoder like xvid to compress your data.


"Robert G. Hoover" <not.a.real.address@anywhere.sorry> ha scritto nel 
messaggio news:46b0f5c4$1@newsgroups.borland.com...
> Hi All,
>
> I've got a timing/performance need... I'm trying to capture the screen as 
> BMP,
> compress to JPG, then send over a TCustomWinSocket. I'm afraid it just 
> takes too
> long... :(  Here's what I've got going on...
>
> So, is there any way to speed up any or all of these operations? It takes 
> (as
> near as I can measure) ~1.5 seconds to send over the data. Any and all 
> advice is
> much appreciated...
>
> Many thanks!
>
> Rob 

Robert,

JPEG compression does a great job of exploiting spatial redundancy: 
Neighboring pixels in space tend to be similar in value.  However, as 
others have mentioned, to be efficient, you need to also exploit the 
temporal redundancy in the data:  Neighboring pixels in time also tend 
to be similar in value (even more so than across space).  Your best bet 
would be to use a video compression algorithm for this, one which 
ideally uses motion-compensated prediction to track objects (and moving 
objects) across time.

I know Malcolm Smith does video transmission with BCB--it might be worth 
dropping him a line to see if he has any advice regarding turnkey 
solutions (his contact info is available at http://www.mjfreelancing.com).

Best of luck,
--
Damon Chandler (TeamB)
C++Builder Developer's Journal
http://bcbjournal.com
http://bcbjournal.org


Robert G. Hoover wrote:
> I've got a timing/performance need... I'm trying to capture the screen as BMP,
> compress to JPG, then send over a TCustomWinSocket. I'm afraid it just takes too
> long... :(  Here's what I've got going on...