[FFmpeg-user] Using -filter_complex instead of lavfi with amerge hangs.

Tim Nicholson nichot20 at yahoo.com
Tue Jun 26 14:09:17 CEST 2012

On 26/06/12 12:47, Nicolas George wrote:
> Le nonidi 9 messidor, an CCXX, Tim Nicholson a écrit :
>> I do not understand that, as I thought that
>> "amovie=LTA01631701.mxf:si=1, aconvert=s16:mono:planar [a1]"
>> defined an input and assigned it to pad a1.
> It is a source, not an input. An input is a link not connected to anything,
> that ffmpeg will feed by itself.

OK, but does not the [a1] before the amerge provide the amerge with the
required input?

I will accept that it was not the "proper" way to do it, but its still
not clear to me why it failed since I did conform to the recognised
filtergraph syntax.

>> 					      Having extra sources in a
>> filtergraph is not uncommon, take the overlay filter for example, so
>> expecting the use of amovie to define a source is not unreasonable in
>> this circumstance, although possibly not the best way to do it.
>>> input-driven (this needs to be fixed, but this is not urgent), your filter
>>> graph does not fit its scheduling.
>>> Rule of thumb: do not use (a)movie with -filter_complex, use the ffmpeg -i
>>> option instead (and second rule of thumb: do not use the same inputs several
>>> times).
>> Just to clarify, with -vf it usual to add extra inputs (whether audio or
>> video) using (a)movie, but with -filter_complex you just use multiple -i
>> options and then pick the streams with the usual [file:stream] syntax?
> That is exactly that. IMHO, using the (a)movie source should be considered
> only a workaround for when ffmpeg was not able to deal with complex or audio
> filters. Now that it can, it should not be used.

In which case I will amend my doc patch at the end of the -map_channel
section which uses the amovie workaround and replace it with a
-filter_complex example. This will at least provide a start of a working

>> something like, but use ":" not "." in the mappings...;)
> My bad.
>> Would using "join" with the mapping option be more appropriate for this
>> operation?
> join is Nit Invented Here version of amerge from libav. I did not look into
> it in details, but at first glanced its design seemed botched.

> [...]


More information about the ffmpeg-user mailing list