[FFmpeg-devel] [PATCH] libspeex Speex encoding
Thu Oct 29 23:16:31 CET 2009
Michael Niedermayer wrote:
> On Wed, Oct 28, 2009 at 07:45:45PM -0400, Justin Ruggles wrote:
>> Michael Niedermayer wrote:
>>> On Tue, Oct 27, 2009 at 05:54:51PM -0400, Justin Ruggles wrote:
>>>> Michael Niedermayer wrote:
>>>>> On Sun, Oct 25, 2009 at 09:04:45AM -0400, Justin Ruggles wrote:
>>>>>> + new_samples_size = avctx->frame_size * avctx->channels *
>>>>>> + (avctx->sample_fmt == SAMPLE_FMT_FLT ?
>>>>>> + sizeof(float) : sizeof(int16_t));
>>>>>> + samples = av_mallocz(new_samples_size);
>>>>>> + if (!samples)
>>>>>> + return AVERROR(ENOMEM);
>>>>>> + memcpy(samples, data, new_samples_size);
>>>>> i think the application is or at least should be required to allocate full
>>>>> frames even for the possibly smaller last
>>>> Where should this be documented? avcodec_encode_audio()?
>>> yes and close to CODEC_CAP_SMALL_LAST_FRAME
>> Should the API require that the rest of the frame be padded with zeros?
>> The encoder cannot modify the data, so if this is not required, the
>> data would have to be copied in the encoder where there remaining
>> samples could be zeroed out... thus making the allocation requirement
> This actually brings up another issue ...
> is zero padding even required / a good idea?
> If these samples are never output then other forms of padding
> might lead to higher quality & lower bitrate of the last frame.
> The simplest thing to try would be simple reflecting the values
> that is:
> instead of ABCDEF000000
> ABCDEFEDCBA or ABCDEFFEDCBA
For 20ms at the end of a stream does it really matter? For Speex
encoding, I went with zero padding because that's what speexenc does.
If the duration of the last packet is set to the smaller size, yes
speexdec will chop off the padded samples. Our libspeex decoder doesn't
do that though (I have a patch but I think it's horribly ugly and it
probably won't work with seeking).
More information about the ffmpeg-devel