[FFmpeg-devel] [PATCH+RFC] AVFrame for audio

Justin Ruggles justin.ruggles
Sun Jul 11 18:11:51 CEST 2010


Michael Niedermayer wrote:

> On Sun, Jul 11, 2010 at 11:33:25PM +1000, Peter Ross wrote:
>> On Sun, Jul 11, 2010 at 11:12:56AM +0100, M?ns Rullg?rd wrote:
>>> Peter Ross <pross at xvid.org> writes:
>>>
>>>> Hi,
>>>>
>>>> To prototype use of audio in AVFrame, I have modified the PCM encoder/decoder
>>>> and addded new public lavc functions.
>>>> [...] 
>>>> +/**
>>>> + * Encode an audio frame from samples into buf.
>>>> + *
>>>> + * @param avctx the codec context
>>>> + * @param[out] buf the output buffer
>>>> + * @param[in] buf_size the output buffer size
>>>> + * @param[in] frame the input buffer containing the samples
>>>> + * @return On error a negative value is returned, on success zero or the number
>>>> + * of bytes used to encode the data read from the input buffer.
>>>> + */
>>>> +int avcodec_encode_audio2(AVCodecContext *avctx, uint8_t *buf, int buf_size,
>>>> +                          const AVFrame *frame);
>>> At some point, we should do something about the output buffer
>>> allocation too.  Currently, a ridiculous size is allocated in ffmpeg.c
>>> just to be on the safe side.
>> Agree, and should be easy enough to do. Ditto for video, right?
> 
> that was discussed previously, in short summary yes but noone did it
> Also with encoding into an AVPacket reallocation should be quite easy
> as the pointer is easy changeable

+1 for me on this.  Sometimes even the ridiculous size is not enough,
e.g. FLAC encoding.  The ability to reallocate dynamically if larger
frames are created would make things much simpler.

I like the overall concept for these changes.  I think it would also get
rid of the frame_size=1 for PCM requirement.

-Justin




More information about the ffmpeg-devel mailing list