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

[Clément Bœsch]

On Fri, Dec 26, 2014 at 01:16:07AM +0100, Stefano Sabatini wrote:
> 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 first case has its use cases. Random example:
https://soundcloud.com/explore

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

In the second case, you'll probably need successive scaling before you
reach the targeted size. It's probably a bit more complex than the current
patch, but might do the trick.

Note that, while I don't think it will matter, the beginning of the track
will probably suffer from accuracy given how many time it will be
averaged/scaled.

> 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.

I'm a bit lazy to do that, feel free to take over this patch.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141228/5c841d6a/attachment.asc>