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

[Måns Rullgård]

Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:

> On date Wednesday 2010-09-29 21:20:04 -0400, Justin Ruggles encoded:
>> Hi,
>> 
>> Peter Ross wrote:
>> 
>> > On Thu, Sep 02, 2010 at 07:11:37PM -0400, Justin Ruggles wrote:
>> >> Hi,
>> >>
>> >> Peter Ross wrote:
>> >>
>> >>> To prototype use of audio in AVFrame, I have modified the PCM encoder/decoder
>> >>> and addded new public lavc functions.
>> >>>
>> >>> Existing SAMPLE_FMTs are mapping onto (AVFrame*)->data[0]. The obvious
>> >>> next step is to support planar audio, and splitting FF_COMMON_FRAME into
>> >>> common, audio- and video-specific parts.
>> >>>
>> >>> avctx->reget_audio_buffer() is implemened using a simple realloc. It
>> >>> probably makes sense to reuse the video InternalBuffer stuff, but i'm not
>> >>> sure.
>> >> Any progress on this?  I really like the idea.
>> > 
>> > Unfortunately not. If you or anyone else wants to run with this patch, please do.
>> 
>> Here is a new patch+rfc to only change the audio decoding to behave like
>> video decoding.
>> 
>> - adds nb_sample to AVFrame
>
> <nitpick>
> I'd prefer samples_nb. The _nb prefix at the end allows alignment

I had to laugh at "prefix at the end"...

> tricks like:
> samples
> samples_nb
>
> Also I read it like:
> samples_nb -> samples number
> which sounds better than
> nb_samples -> number (of) samples

The former sounds rather backwards to me, the latter being perfectly
normal English.

>> - adapts get/reget_buffer to support video or audio media types
>> - example implementation for pcm decoder
>> 
>> Once this part is reviewed and agreed upon, I'll work on the user-side
>> usage of avcodec_decode_audio4() and the tedious work of changing all
>> the audio decoders to the new API.
>> 
>> Planar audio would definitely be nice to add later, but I'm not sure how
>> to go about it. maybe something like...

We should definitely support planar formats.

>> - a new AVFrame field **audio_data
>> - allocate channel pointers and data for each channel in get_buffer()
>> - add planer sample formats and support in conversion function/filter
>>     - might allow moving float_to_int16_interleave() to avfilter?

Interleave is a trivial operation that should be available without the
complexity of avfilter.  No harm in having a filter wrap it for
convenience where avfilters are already used, of course.

-- 
M?ns Rullg?rd
mans at mansr.com