[Libav-user] Is it possible to dynamically reconfigure a filter graph?

[Stefano Sabatini]

On date Tuesday 2012-10-23 14:45:53 -0600, Michael Bradshaw encoded:
> On Tue, Oct 23, 2012 at 2:38 PM, Stefano Sabatini <stefasab at gmail.com> wrote:
> > On date Tuesday 2012-10-23 13:03:27 -0600, Michael Bradshaw encoded:
> >> I'm using avfilter to rescale video (and convert it to the right pixel
> >> format) and convert audio (to the right sample format, sample rate,
> >> and channel_layout) (I'm also buffering audio using asetnsamples to
> >> fill frames with a consistent number of samples). While reading the
> >> source video and source audio, it's possible they change in the
> >> stream.
> >
> >> If the source audio stream changes (i.e. sample rate, sample
> >> format, channel_layout), or if the source video stream changes (width,
> >> height, or pixel format), do I have to completely destroy and rebuild
> >> the filter graph? Or is there a way to "update" the source filters to
> >> the new formats and update (without destroying) the filter graph?
> >
> > Some filters do, others won't, so in general the best way is to
> > "normalize" the input media before injecting it in the filtergraph, a
> > consistent and robust way to deal with that will require some
> > (re)design at the framework level.
> 

> How would you suggest to "normalize" the input media? Because that's
> exactly what I'm (ab)using libavfilter for: given "unormalized" source
> media, produce "normalized" output with consistent picture size/format
> and audio format. If there's currently a preferred or better solution
> to do this, I'd love to know.

Well, do you need to normalize the input or the output? Old versions
of buffer/abuffer supported input normalization, before the libav
changes discarding that feature were merged in.

In general it should not be hard to implement a normalization input
buffer source. Dealing with that in a generic way (some filters can
support mid-stream changes, other can't, so the framework should
automatically auto-add format normalizers in the latter case).

Alternatively you could just have a scaler/resampler just before the
filtergraph input, if you need to perform further filtering.
 
> Right now I'm thinking of abandoning libavfilter and just using
> swscale and swresample directly, and dynamically reconfiguring the
> swscale and swresample contexts as necessary, but I'm exploring
> alternatives.
> 
> >> My primary concern is that asetnsamples may have some samples
> >> buffered, and destroying and recreating the filter graph would lose
> >> these buffered samples.
> >>
> >
> >> Also, if it's possible to update the filters without destroying the
> >> graph and recreating it, would it be possible to change the number of
> >> samples set for asetnsamples? I'm not seeing anything that makes it
> >> look like this is possible, but it's worth double checking.
> >

> > This should be easily feasible by implementing a process_command()
> > callback in asetnsamples, also have a look at the asendcmd filter,
> > patches (or alternatively a feature request) are welcome.
> 
> Cool. I guess this can be added to the "On libavfilter: A summary of
> issues" thread. I'll work on it if I have time, though I doubt I will
> for a while.

Well libavfilter dynamic reconfiguration can be considered a framework
limitation (and I don't think there are many filtering frameworks
which can deal with it), the lack of contributions or lack of time of
the FFmpeg slav^H^H^H^Hdevelopers is hardly a problem specific of
libavfilter.