[FFmpeg-devel] [PATCH] Add get_audio_buffer_ref to lavfi audio framework

Michael Niedermayer michaelni
Mon Sep 27 12:33:20 CEST 2010


On Sun, Sep 26, 2010 at 09:01:23PM -0700, S.N. Hemanth Meenakshisundaram wrote:
>  On 09/25/2010 08:19 PM, Michael Niedermayer wrote:
> > On Wed, Sep 22, 2010 at 11:01:23AM -0700, S.N. Hemanth Meenakshisundaram wrote:
> >>  Fixed a bug found during testing of af_afifo filter.
> >
> >>  avfilter.c |   20 ++++++++++++++++++++
> >>  avfilter.h |   34 ++++++++++++++++++++++++++++++++++
> >>  defaults.c |   42 ++++++++++++++++++++++++++++--------------
> >>  3 files changed, 82 insertions(+), 14 deletions(-)
> >> dc7a6178731a77f31f69bfc2518541c429fbb59d  0001-Add-get_audio_buffer_ref-to-lavfi-audio-framework.patch
> > i do not understand why such convoluted buffer handling would be needed
> >
> >
> > [...]
> >
> 
> The problem is that the current AVFilterBufferRef creation functions for
> both audio and video allocate their own buffer, then set up pointers to
> each channel's/plane's data & step sizes within this buffer.
> 
> So a memcpy at the start of lavfi is unavoidable.
> 
> get_audio_buffer_ref uses an existing buffer and builds a
> AVFilterBufferRef struct around it. Sets up pointers within the given
> buffer to each channel's data as well as step sizes to get to next
> sample of same channel. This avoids the memcpy while still allowing
> filters to operate on a channel by channel basis if required.
> 
> Is there some specific part of the buffer handling that feels too
> convoluted?

The whole feels too convoluted, like instead of a single malloc()
you add a complex callback system that passes mysterious things through the
filter chain

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/20100927/526fa08f/attachment.pgp>



More information about the ffmpeg-devel mailing list