[FFmpeg-devel] [PATCH] Add get_audio_buffer_ref to lavfi audio framework
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
The whole feels too convoluted, like instead of a single malloc()
you add a complex callback system that passes mysterious things through the
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel