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

Justin Ruggles justin.ruggles
Sun Sep 5 22:39:12 CEST 2010


Baptiste Coudurier wrote:

> On 9/5/10 10:04 AM, Michael Niedermayer wrote:
>> On Sun, Sep 05, 2010 at 12:56:37PM -0400, Justin Ruggles wrote:
>>> Hi,
>>>
>>> The ADPCM encoders all set AVCodecContext.frame_size so the really old
>>> special-case handling in libavformat/utils.c:get_audio_frame_size() is
>>> never used and is not needed.
>>>
>>> This is the first step in my attempt to get rid of all special-case
>>> frame_size handling for PCM encoders.
>>>
>>> -Justin
>>>   utils.c |    5 +----
>>>   1 file changed, 1 insertion(+), 4 deletions(-)
>>> ba9f8587ad6312838e3dcf155a29a5c37466b878  adpcm_frame_size.patch
>>> Index: libavformat/utils.c
>>> ===================================================================
>>> --- libavformat/utils.c	(revision 24870)
>>> +++ libavformat/utils.c	(working copy)
>>> @@ -734,10 +734,7 @@
>>>                   return -1;
>>>               frame_size = (size<<  3) / (bits_per_sample * enc->channels);
>>>           } else {
>>> -            /* used for example by ADPCM codecs */
>>> -            if (enc->bit_rate == 0)
>>> -                return -1;
>>> -            frame_size = ((int64_t)size * 8 * enc->sample_rate) / enc->bit_rate;
>>> +            return -1;
>> this should be assert(0) if it really never occurs, that way we will notice if
>> it does occur (if asserts are enabled at least)
>>
>> and i assume you made sure that this case is never reached on any of the fate
>> tests?
> 
> IIRC it is still used for decoding adpcm in wav.

Ah I see.  It could be needed to estimate packet pts/duration for
demuxing ADPCM in WAV in some cases.

For encoding it is only used for g726, and that is only an estimated
frame size.  But the general frame size handling of g726 encoding is
messed up anyway.  It doesn't follow the API for either PCM or non-PCM.
 Attached patch makes it more like the other ADPCM codecs.  The codec
test reference changes because a different combination of frame sizes
leads to slightly different results, even though all the input is
exactly the same in values and number of samples.

-Justin

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: g726_frame_size.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100905/d0a3077a/attachment.asc>



More information about the ffmpeg-devel mailing list