[FFmpeg-devel] [PATCH] lavfi: add aconcat variant for the concat filter

Stefano Sabatini stefasab at gmail.com
Thu Sep 6 23:12:29 CEST 2012


On date Thursday 2012-09-06 20:58:34 +0200, Nicolas George encoded:
> Le primidi 21 fructidor, an CCXX, Stefano Sabatini a écrit :
> > It can be useful to specify aconcat rather than concat=a=1:v=0.
> > 
> > This is consistent with amovie/asplit and other filter variants
> > specialized on audio.
> > 
> > It is perfectly equivalent to concat otherwise.
> 
> I am sorry to say, I do not like it very much. It makes a lot of code to add
> and maintain for the sole practical result of abbreviating "concat=a=1:v=0":
> that is not a very good investment.
> 
> As for the frobnicate/afrobnicate symmetry, I see the afrobnicate variants
> as a constraint caused by the current design (type can not be negotiated or
> guessed): if someone comes with a smart idea on how to eliminate them
> without too much code, I would deprecate the afrobnicate variants in a
> heartbeat. And in particular, I would suggest to deprecate amovie right now.

Well, adding an xfrobnicate variant usually requires:

- duplicate the AVFilter definition

- duplicate the AVClass (this is actually required by the class
  iteration design, and could/should be avoided with some redesing)

- add some logic (based on filter name) to handle the variant.

This usually takes around ~40/50 lines of dummy code.

The ideal solution would be to make the filter autodetect the
input/output types and reconfigure itself accordingly.

For example:
unsharp,showinfo

will make showinfo work like a video filter:

atempo,showinfo

will make it work like an audio filter.

Right now the filter type is checked when building the graph, we could
leave the type unset (or specify a set of recognized types,
e.g. audio+video), and setup the filter link during the configuration
stage.

So yes in the long run this would be the better approach.

In the short term it is still useful to specify:
aconcat
rather than:
concat=v=0:a=1

but I won't insist on this if you disagree.

> Note that we will actually need a solution to the type problem before we
> start randomly implementing dsplit or ssetpts.
-- 
FFmpeg = Freak and Fundamentalist Martial Pacific Enigmatic Ghost


More information about the ffmpeg-devel mailing list