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.
> > > >
> > > > +@item single_pic
> > > > +Output only one frame at the end if set. This option can only work with
> > > > +@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.
pgpTqs0OqJMXl.pgp
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
