[FFmpeg-devel] [PATCH+RFC] AVFrame for audio
Michael Niedermayer
michaelni
Wed Oct 6 02:59:32 CEST 2010
On Tue, Oct 05, 2010 at 04:55:12PM -0400, Justin Ruggles wrote:
> Michael Niedermayer wrote:
>
> > On Wed, Sep 29, 2010 at 09:20:04PM -0400, Justin Ruggles wrote:
> >> 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
> >> - 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...
> >>
> >> - a new AVFrame field **audio_data
> >
> > it would be possible to seperate the planes by linesize[0] bytes
> > iam not saying i prefer it just that it is possible
>
> Do you mean using something analogous to av_image_fill_pointers() but
> for audio?
i meant data[0] + channel*linesize[0] instead of audio_data
but as said i dont know if this is a good idea
>
> > [...]
> >> @@ -235,7 +239,7 @@
> >> return -1;
> >> }
> >>
> >> - if(av_image_check_size(w, h, 0, s))
> >> + if (is_video && av_image_check_size(w, h, 0, s))
> >> return -1;
> >
> > audio parameters should be checked similar to image here
>
> Ok, I'll add that. Do you think there should be a public function
> similar to av_image_check_size()?
non public is easier as we dont need to bikeshed the API
>
> >
> > [...]
> >> @@ -644,29 +677,49 @@
> >> }
> >> #endif
> >>
> >> +#if LIBAVCODEC_VERSION_MAJOR < 53
> >> int attribute_align_arg avcodec_decode_audio3(AVCodecContext *avctx, int16_t *samples,
> >> int *frame_size_ptr,
> >> AVPacket *avpkt)
> >> {
> >> + AVFrame frame;
> >> + int ret, got_frame = 0;
> >> +
> >> + avcodec_get_frame_defaults(&frame);
> >> +
> >> + ret = avcodec_decode_audio4(avctx, &frame, &got_frame, avpkt);
> >> +
> >> + if (ret >= 0 && got_frame) {
> >> + *frame_size_ptr = frame.nb_samples * avctx->channels *
> >> + (av_get_bits_per_sample_format(avctx->sample_fmt) / 8);
> >> +
> >> + /* ensure data will fit in the output buffer */
> >> + if (*frame_size_ptr > AVCODEC_MAX_AUDIO_FRAME_SIZE) {
> >> + av_log(avctx, AV_LOG_WARNING, "avcodec_decode_audio3 samples "
> >> + "truncated to AVCODEC_MAX_AUDIO_FRAME_SIZE\n");
> >> + *frame_size_ptr = AVCODEC_MAX_AUDIO_FRAME_SIZE;
> >> + }
> >> +
> >
> >> + memcpy(samples, frame.data[0], *frame_size_ptr);
> >
> > the default get_buffer() should return the appropriate
> > buffer for this case.
>
> I'm sorry, I don't understand your comment.
i mean (non functional psseudocode below to explain the idea)
avcodec_decode_audio3(){
avctx->foobar= samples;
ret = avcodec_decode_audio4(avctx, &frame, &got_frame, avpkt);
...
assert(samples == frame.data[0]);
-----
default_get_buffer(){
if(avctx->foobar)
return avctx->foobar;
(and yes this cannot work for all theoretical decoders)
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101006/3aa9ed86/attachment.pgp>
More information about the ffmpeg-devel
mailing list