[Ffmpeg-devel] Increasing Audio Buffer Size

[Cyril Zorin]

On 5/9/06, Michael Niedermayer <michaelni at gmx.at> wrote:
>
> Hi
>
> On Tue, May 09, 2006 at 06:38:51AM -0700, Mike Melanson wrote:
> > Michael Niedermayer wrote:
> > >and tomorrow yet another format will need 500k, no this is not ok, fix
> the
> >
> > That is how the process has worked so far...
>
> yes, and iam unhappy about it
>
>
> >
> > >code, so that get/release_buffer() is used by the audio codecs to alloc
> > >the buffer, and no a codec internal buffer which chops it below 192k is
> > >not ok either, actually thats a even worse hack
> >
> > So, modify the internal FFmpeg API? Will do. This also affects how
> > external programs view FFmpeg, right?
>
> that depends, it can be done in a way which peserves compatibility but
> IMHO it does nothing good, it will just cause people to keep using the
> old API and cause everyone to get headache due to buffer overflows and
> such ...


Yeah; don't want people to use the old way if this way is implemented.

heres my thought on how it could be done (comments welcome...)
>
> -int avcodec_decode_audio(AVCodecContext *avctx, int16_t *samples,
> +int avcodec_decode_audio(AVCodecContext *avctx, AVFrame *avframe,
>
> optionally the above can be done in a way which doesnt break compatibility
> be adding a new function and keeping the old ...
>
>
> the audio decoders decode():
>     calls avctx.release_buffer(avctx, avframe) if a previous buffer isnt
>     needed anymore
>
>     calls avctx.get_buffer(avctx, avframe)
>
>     audio sample i of channel c is stored in
>     avframe.data[c][ i*avframe.linesize[c] ] cast to the format (always
>     int16_t currently)


Would it be correct to say that currently (samples) is an array of
interlaced channel data? If many audio decoders already output interlaced
channel audio data, then they'd have to be modified to support the proposed
avframe.data[channel][sample_index] storage. In that case, who interlaces
the audio data later on?

I think it'd be better to take the analogous approach that video decoding
takes, insofar that at a certain point an "Audio Frame" is just a free-area
of crap that the decoder can fill in, without organizing it by "channel" or
whatever.

Also, if it were up to me, I'd leave the AVFrame struct well alone and make
an "AFrame" or otherwise something for "audio frame". I wouldn't want to
clutter AVFrame any more.

Cyril.


    avframe.linesize[c] will only depend upon avctx.sample_format
>     so a decoder doesnt need to care about it if it supports just
>     one sample_format (which will generally be the case)
>
>
> get_buffer(avctx, avframe)
>     should allocate (or reuse) a buffer depending upon
>     avctx.channels
>     avctx.sample_format
>     the number of samples needed (probably need to add a field to
>     AVCodecContext unless we want to missuse width or height ...)
>
>
> release_buffer() will free the buffer
>
> [...]
> --
> Michael
>
> In the past you could go to a library and read, borrow or copy any book
> Today you'd get arrested for mere telling someone where the library is
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>