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

[Justin Ruggles]

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've confirmed that this is the cause of the difference.  The parameters
>>>>> used by the regression test give a 4-bit code size.  When the frame size
>>>>> is odd, that leads to 1 extra sample being decoded by the decoder
>>>>> because of padding.  In the current version, because of resampling from
>>>>> 44100 Hz to 8000 Hz, the frame size actually varies from frame-to-frame.
>>>>>
>>>>> Current:
>>>>> source samples             = 264600
>>>>> resampled samples          =  47991
>>>>> number of odd-sized frames =     61
>>>>> decoded samples            =  48052
>>>>> decoded data bytes         =  96104
>>>>>
>>>>> Patched:
>>>>> source samples             = 264600
>>>>> resampled samples          =  47991
>>>>> number of odd-sized frames =      1 (the last frame)
>>>>> decoded samples            =  47992
>>>>> decoded data bytes         =  95984
>>>>>
>>>>> So choosing a frame size that forces the encoder to only use padding for
>>>>> the last frame (which this patch does) seems to be the appropriate thing
>>>>> to do.
>>>> the patch is ok then
>>>> the regression test still is completely broken though because it does not
>>>> seem to compare files of equal sampling rate if my guess is correctly
>>> Would it be better to resample back to 2-channel 44100 Hz during
>>> decoding
>> imho yes
> 
> ok. that is a simple fix.
> 
> But it's not so simple for pcm_s24daud because FFmpeg can upmix from 2
> to 6 channels for encoding, but it can't downmix from 6 to 2 channels
> for decoding.  Should that decoding test be disabled?

Or we can fix both tests by creating multiple reference files like in
the attached patch.  My shell scripting skills are minimal, so there
might be a simpler way to do the same thing...

-Justin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: acodec_multiple_refs.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100911/07f14aa1/attachment.asc>