Reduce IAudioSamples memory footprint

[GoogleCodeExporter]

Currently when you allocate IAudioSamples using a .make() method, Xuggler
always allocates enough space for 1 second of 48kz 32 bit audio, or 192K
per object.

That means if you're working with something like 576 samples of 16-bit mono
audio, in reality you're carting around 192k instead of the expected  1152
bytes you really wanted.

We have to allocate 192k because FFmpeg requires that buffer size or
greater when you decode from a packet into a set of samples -- but we don't
need it when encoding (or mixing).

So, we're going to change this, which is a major change and will have some
backwards compatability impacts.  More to come.

Original issue reported on code.google.com by art.cla...@gmail.com on 30 Jul 2009 at 11:14

[GoogleCodeExporter]

Implemented in r855.

Now when you create a set of IAudioSamples, the numSamples argument is used to
determine the buffer to later allocate when needed.  If you pass that object to
IAudioSamples.decodeAudio(), and IAudioSamples.getMaxBufferSize() is < 192000, 
then
we will reallocate the underlying IBuffer in the IAudioSampels object to gie it 
at
least 192000.  All other methods (e.g. IStreamCoder.encodeAudio,
IAudioResampler.resample) will not resize the buffers, and will fail if you 
don't
pass in the right size.

In general this should work without backwards compatibility changes (although 
that
means we're adding a few bytes (less than 128) at the end of every samples 
buffer to
cover potential assembly 64-bit instruction overreads and potential audio 
resampler
leadin requirements).

Original comment by art.cla...@gmail.com on 30 Jul 2009 at 11:27

[GoogleCodeExporter]

Again in r855

Original comment by art.cla...@gmail.com on 30 Jul 2009 at 11:28

• Changed state: Completed