[FFmpeg-devel] [PATCH] libspeex Speex encoding
Thu Oct 29 16:14:07 CET 2009
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
instead of ABCDEF000000
ABCDEFEDCBA or ABCDEFFEDCBA
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel