[FFmpeg-devel] [PATCH+RFC] AVFrame for audio
Thu Sep 30 12:20:22 CEST 2010
Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
> On date Wednesday 2010-09-29 21:20:04 -0400, Justin Ruggles encoded:
>> 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. 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
> I'd prefer samples_nb. The _nb prefix at the end allows alignment
I had to laugh at "prefix at the end"...
> tricks like:
> 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
>> - 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.
mans at mansr.com
More information about the ffmpeg-devel