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

Justin Ruggles justin.ruggles
Mon Sep 6 14:11:38 CEST 2010


Justin Ruggles wrote:

> 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.

New, slightly improved, patch attached.  It selects a frame size for
g726 based on the code size.  This way frames (except the final frame)
will end on a byte boundary and will be approximately 1024 bytes.

-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/20100906/a087e819/attachment.txt>



More information about the ffmpeg-devel mailing list