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

[Michael Niedermayer]

On Tue, Mar 27, 2012 at 01:18:59AM +0200, Stefano Sabatini wrote:
> 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.

iam fine with the extra complexity.
A fate test would be nice though

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Incandescent light bulbs waste a lot of energy as heat so the EU forbids them.
Their replacement, compact fluorescent lamps, much more expensive, dont fit in
many old lamps, flicker, contain toxic mercury, produce a fraction of the light
that is claimed and in a unnatural spectrum rendering colors different than
in natural light. Ah and we now need to turn the heaters up more in winter to
compensate the lower wasted heat. Who wins? Not the environment, thats for sure
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120329/8356c809/attachment.asc>