[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