[FFmpeg-devel] [PATCH] Add libavsequencer.

[Vitor Sessak]

Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Aug 20, 2010 at 6:20 PM, Stefano Sabatini
> <stefano.sabatini-lala at poste.it> wrote:
>> On date Friday 2010-08-20 00:15:48 +0200, Michael Niedermayer encoded:
>>> On Thu, Aug 19, 2010 at 10:12:31PM +0200, Sebastian Vater wrote:
>>>> Vitor Sessak a ?crit :
>>>>> On 08/19/2010 07:48 PM, Sebastian Vater wrote:
>>>>>> Ronald S. Bultje a ?crit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, Aug 19, 2010 at 10:21 AM, Stefano Sabatini
>>>>>>> <stefano.sabatini-lala at poste.it>  wrote:
>>>>>>> [..]
>>>>>>>
>>>>>>>> The other advantage of such approach is that it would be simpler to
>>>>>>>> keep all the new code disabled by default.
>>>>>>>>
>>>>>>>
>>>>>> Hey Ronald&&  Stefano!
>>>>>>
>>>>>>> We could consider enabling the code by default, if:
>>>>>>> - it's not too big
>>>>>>> - it works
>>>>>>> - has been properly reviewed
>>>>>>> I think it's doable. :-).
>>>>>>>
>>>>>> Yes it is, but is still some way until we arrive at that point. ;-)
>>>>>> But even if it would work perfectly right now, there's another point to
>>>>>> keep it in avseq now, since IFF-TCM1 is, apart from us here and mine,
>>>>>> practically unused, therefore an IFF-TCM1 demuxer/decoder is only usable
>>>>>> for us right, now.
>>>>>>
>>>>>> There's no reason to make all external deps on FFmpeg making some
>>>>>> hundred KB's larger for a feature which practically nobody can use now.
>>>>> After getting TCM decoding working, is adding MOD support is trivial?
>>>>> If yes, it all should turn into a popular feature very soon, so this
>>>>> is not a big deal.
>>>> Yes, basically it's just a port from my already 68k asm MOD support
>>>> external lib using TuComposer. The same applies to S3M, XM, IT and
>>>> FC13/14. Just MED will be new.
>>>>>
>>>>>> So to summarize, let's keep us for now, avseq as a lib as it already is.
>>>>> I don't really understand which arguments in your email supports this
>>>>> idea.
>>>>>
>>>> Because practically nobody actually can use this codec currently, so
>>>> having it default disabled and all related stuff is a better idea, I think.
>>>>
>>>> It's clearer what should not be used right now, if all is in dir
>>>> libavsequencer/* instead of having that in libavcodec. In lavc we would
>>>> have the header files spread all around during 100 of other codecs.
>>>>
>>>> I'ld prefer the way to keep the lavseq stuff as it for now and later
>>>> decide when all works if we move that from lavseq to lavcore or sth. else.
>>> i also think lavseq should stay in lavseq for now
>> So please let's decide and stop bikeshedding on this, this can be
>> settled later.
> 
> Michael's maintainer, so lavseq it is. Let the patches come, and review begin.

In case someone is wondering, this is fine for me too.

-Vitor