[FFmpeg-devel] [PATCH] remove out-dated ADPCM frame_size handling in libavformat

[Justin Ruggles]

Michael Niedermayer wrote:

> On Mon, Sep 06, 2010 at 08:11:38AM -0400, Justin Ruggles wrote:
> [...]
>> Index: tests/ref/acodec/g726
>> ===================================================================
>> --- tests/ref/acodec/g726	(revision 25042)
>> +++ tests/ref/acodec/g726	(working copy)
>> @@ -1,4 +1,4 @@
>> -5d8cce28f83dd33c3c7eaf43a5db5294 *./tests/data/acodec/g726.wav
>> -24082 ./tests/data/acodec/g726.wav
>> -4f1ba1af75dee64625a1c852e6cd01d3 *./tests/data/g726.acodec.out.wav
>> -stddev: 8504.69 PSNR: 17.74 MAXDIFF:31645 bytes:    96104/  1058400
>> +fd090ddf05cc3401cc75c4a5ace1d05a *./tests/data/acodec/g726.wav
>> +24052 ./tests/data/acodec/g726.wav
>> +74abea06027375111eeac1b2f8c7d3af *./tests/data/g726.acodec.out.wav
>> +stddev: 8554.55 PSNR: 17.69 MAXDIFF:29353 bytes:    95984/  1058400
> 
> the number of samples encoded seems to be changing and not equal to
> the input

When the frame size in the encoder makes frames end on a byte boundary
without any padding, the output is always identical.  Since codes are
between 2 and 5 bits long, how would the decoder distinguish between
padding to a byte boundary and another valid code?  I'll double-check,
but it seems that the decoder currently treats padding as additional
samples.

-Justin