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

Justin Ruggles justin.ruggles
Fri Sep 24 00:43:16 CEST 2010


Michael Niedermayer wrote:

> On Wed, Sep 15, 2010 at 05:46:23PM -0400, Justin Ruggles wrote:
>> Michael Niedermayer wrote:
>>
>>> On Sun, Sep 12, 2010 at 04:10:14PM -0400, Justin Ruggles wrote:
>>>> Michael Niedermayer wrote:
>>>>
>>>>> On Sat, Sep 11, 2010 at 06:26:55PM -0400, Justin Ruggles wrote:
>>>>>> Justin Ruggles wrote:
>>>>>>
>>>>>>> Michael Niedermayer wrote:
>>>>>>>
>>>>>>>> On Sat, Sep 11, 2010 at 11:30:07AM -0400, Justin Ruggles wrote:
>>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Sep 08, 2010 at 06:49:36PM -0400, Justin Ruggles wrote:
>>>>>>>>>>> Justin Ruggles wrote:
>>>>>>>>>>>
>>>>>>>>>>>> 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.
> 
> i dont know about g726 but mpeg4/h264 pad the bitstream so that one can find
> exactly where it ends by looking at the bits at the end
> the trick works along the line of appending 1 and then padding with 0 till a
> byte boundary, this can be undone by just looking backward for the 1 bit
> 
> [...]

The G.726 specification says nothing about framing or padding.  From the
decoder's perspective, as long as there are enough bits to make up the
next code, they are considered a valid part of the signal.  The encoder
is not allowed to write a 0 code for 40/32/24kbps modes (0 is valid for
16kbps mode), but due to possible line noise/corruption the decoder is
required to treat it as a valid value and dequantize it to the same
value as an all 1's code.

The only framing info I could find for G.726 was the RTP packetization
as defined in RFC 3551. Quote:
"Packing MUST end with a completely packed final octet.  The number of
codewords packed will therefore be a multiple of 8, 2, 8, and 4 for
G726-40, G726-32, G726-24, and G726-16, respectively."

We have now avoided padding between frame boundaries in the encoder by
setting frame_size to a value that will end on a byte boundary.  But I
really don't see any options to avoid padding at the end of the stream
and having a decoder treat that padding as actual samples.

-Justin



More information about the ffmpeg-devel mailing list