[FFmpeg-devel] [PATCH] avfilter/showwaves: add single_pic option

[Stefano Sabatini]

On date Friday 2014-12-26 00:17:53 +0100, Clément Bœsch encoded:
> On Fri, Dec 26, 2014 at 12:14:52AM +0100, Stefano Sabatini wrote:
> > On date Wednesday 2014-12-24 15:03:26 +0100, Clément Bœsch encoded:
> > > TODO: bump minor
> > > ---
> > >  doc/filters.texi            |  12 +++
> > >  libavfilter/avf_showwaves.c | 175 +++++++++++++++++++++++++++++++++++++++-----
> > >  2 files changed, 169 insertions(+), 18 deletions(-)
> > > 
> > > diff --git a/doc/filters.texi b/doc/filters.texi
> > > index 7fac8fb..7953e62 100644
> > > --- a/doc/filters.texi
> > > +++ b/doc/filters.texi
> > > @@ -11334,6 +11334,11 @@ option @var{n}. Default value is "25".
> > >  @item split_channels
> > >  Set if channels should be drawn separately or overlap. Default value is 0.
> > >  
> > > + at item single_pic
> > > +Output only one frame at the end if set. This option can only work with
> > > + at option{mode}=@var{cline}. Note that this option will store the whole decoded
> > > +audio track in memory. Default value is 0.
> > 
> > I wonder if we should rather have a different filter, computing the
> > average value over N samples and printing it. This should not require
> > the buffering logic. Note that we may also adapt the filter and use a
> > high value of n. That together with tile would do the trick.
> 
> How do you define N without decoding everything?

I see there are two distinct use cases:

1. the user wants to plot a graph of the averaged samples volume, with
a fixed size

2. the user wants to plot a graph of the averaged samples volume, with
varying size.

In the first case, your patch addresses the issue, but requires
buffering the whole input. In the second case, the user can generate
several images and then concatenate them in a second step using the
tile filter. The advantage of the second approach is that it will
generate an image with a size proportionate to the input size, and
will not require any buffering.

The two approaches are not mutually exclusive, but the latter is
probably more flexible.

I'll prepare a patch to cover case 2. About case 1, I wonder if having
a dedicated filter (sharing part of the code of showwaves) wouldn't be
a better approach, but I'm not sure it will.
-- 
FFmpeg = Funny and Fundamentalist Mere Programmable Exxagerate God