Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: using idzlib to reduce memorystreamsize


This question is answered.


Permlink Replies: 3 - Last Post: Nov 27, 2017 12:31 PM Last Post By: Remy Lebeau (Te...
madammar ellias

Posts: 111
Registered: 8/17/17
using idzlib to reduce memorystreamsize  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 23, 2017 9:44 AM
i am trying to compess/decompress memorystream using idzlip but after compressing the memorystream size did not reduced it getting bigger

the orginial stream size is 320 after first compress it becomes 160, then 330 then 326 and so on

what could be the problem ?

here is the code


procedure TVOCTHREAD.SendBufferD(Buffer: Pointer; Size: LongWord);
var
Stream: TMemoryStream;
Compressor : TCompressionStream;
begin
Stream := TMemoryStream.Create;
try
 
Compressor := TCompressionStream.Create(clMax, Stream, False);
try
Compressor.WriteBuffer(Buffer^, Size);
finally
Compressor.Free;
end;
 
 
TMonitor.Enter(FQueue);
try
FQueue.Enqueue(TVOCQueueItem.Create('MEMBUF', Stream));
Stream := nil;
finally
TMonitor.Leave(FQueue);
end;
except
Stream.Free;
raise;
end;
end;


Edited by: madammar ellias on Nov 23, 2017 9:53 AM

Edited by: madammar ellias on Nov 27, 2017 11:50 AM
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: using idzlib to reduce memorystreamsize [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 27, 2017 10:50 AM   in response to: madammar ellias in response to: madammar ellias
madammar ellias wrote:

i am trying to compess/decompress memorystream using idzlip but after
compressing the memorystream size did not reduced it getting bigger

the orginial stream size is 320 after first compress it becomes 160,
then 330 then 326 and so on

You did not show your decompression code. But in your compression
code, you have a parameter named Size but you are passing another
variable BufferSize to WriteBuffer(). You should be passing Size
instead.

--
Remy Lebeau (TeamB)
madammar ellias

Posts: 111
Registered: 8/17/17
Re: using idzlib to reduce memorystreamsize [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 27, 2017 11:50 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
madammar ellias wrote:

You did not show your decompression code. But in your compression
code, you have a parameter named Size but you are passing another
variable BufferSize to WriteBuffer(). You should be passing Size
instead.

--
Remy Lebeau (TeamB)


my bad ,i did not create a decompression yet but i was confused about the size the original size is 320 the first time onwork tracking size 160 then start to increase to 325 , 350, this sendbuffer requested in another thread to send audio chunks, i was wondering why compression is done first time only an i thought if the buffersize maybe get bigger andstart tracking it but its remains 320, only compression increase the size i did not figure why the compression already freed before the next sendbuffer requested

Edited by: madammar ellias on Nov 27, 2017 11:53 AM
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: using idzlib to reduce memorystreamsize [Edit] [Edit]
Correct
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 27, 2017 12:31 PM   in response to: madammar ellias in response to: madammar ellias
madammar ellias wrote:

my bad ,i did not create a decompression yet but i was confused about
the size the original size is 320 the first time onwork tracking size
160 then start to increase to 325 , 350

That is normal. Zlib/GZip does not guarantee compressed data will be
smaller than the original, especially when compressing small amounts of
data. ZLib/GZip might mot be able to compress your input data at all
(not enough redundant data to remove), but it still has to add
header/trailer metadata to describe the compression that is used. That
could easily account for the extra size you are seeing.

You really shouldn't be compressing small buffers at all. If anything,
you should consider transcoding the input audio into a more condensed
audio format, rather than compressing the data you are transmitting.

--
Remy Lebeau (TeamB)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02