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

[Baptiste Coudurier]

On 3/29/12 9:50 AM, Michael Niedermayer wrote:
> 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

Humm, I'm not really fine with it. This an admitted hack and should not be applied,
instead the scenario proposed earlier should be focused on.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org