[FFmpeg-devel] [PATCH 4/4] ffmpeg: add -amerge option to merge audio streams.

[Stefano Sabatini]

On date Monday 2012-03-26 17:36:47 +0200, Clément Bœsch encoded:
> On Sat, Mar 24, 2012 at 02:24:59PM +0100, Stefano Sabatini wrote:
> [...]
> > > +            continue;
> > > +        av_bprintf(&lavfi, "\namovie=%s:si=%d [a%d];", ifname, map->stream_index, nb_astreams++);
> > 
> > I see this is quite limited. Suppose that the user wants to specify a
> > seek point or time, or in general codec/format options for the input
> > file, this won't be possible. We can surely add such options to movie,
> > but in general mapping ffmpeg options to *movie options will be a
> > problem, and very hard to maintain, since they use rather different
> > logics.
> > 
> 
> Yup indeed, it's quite a hack. But integrating this feature properly means
> changing quite a bunch of things. The only proper way I see right now is:
> 
>  1) ffmpeg using libavfilter for audio which depends on:
>     * proper libavfilter audio API (AVFrame based API)
>     * filter auto reconfiguration in case of sampling rate change
>     * audio stretching in libavfilter (-async)
>     * -af option (with auto insert of pan for map channel, and various
>       others)
>  2) create in the -amerge scope a merge context filtergraph just like the
>     one used for -af, and reference the different input streams in the
>     output stream context.
>  3) make ffmpeg handle multiple input streams for a given output stream
> 
> This requires a tremendous amount of work before we can hope for this
> feature.
> 
> Of course the current solution is far from ideal; just like you said, we
> can't configure the input properly, and it will basically be limited to
> standard usages. Though, it has the advantage to cover a majority of use
> cases. Also, the hack is quite isolated (it doesn't affect the internals).
> 
> Do you or anyone else has an alternative to propose?

I basically agree with this, indeed my objection was not blocking,
although documenting a bit the limitations seems in order. Apart from
that I leave to the ffmpeg maintainer the choice of injecting or not
the extra complexity, I can review the code.
-- 
FFmpeg = Fundamentalist and Freak MultiPurpose Ecumenical Gladiator