[FFmpeg-devel] [PATCH] Add libavsequencer.

Vitor Sessak vitor1001
Thu Aug 19 21:05:43 CEST 2010


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.

> This will, however, change, when I have finished wxTuComposer to an
> usable application (using FFmpeg ;-)). But even this will take some time.
>
> I don't know who downloaded original TuComposer the last 5 years from my
> site and is using it, but I never saw TCM files in the wild, so...
>
>>
>>> Anyway there is no need to settle the final design just now, so it's
>>> better to start to work in lavc/lavf if we reached such an agreement.
>>>
>>
>> Exactly. Let's finish this stuff, get it reviewed, fixed, committed and rocking.
>>
>
> I already continued today getting the nits which Stefano already
> mentioned to the basic avseq integration patch (K&R function stuff)
> applied to the whole player.c, i.e. no more:
> int foo ( ... ) {
>      ...
> }
>
> all are now:
> int foo(...)
> {
>      ...
> }
>
> Besides this I found other nits like that during processing it.
>
> Now, I'm fixing the remaining playback issues, so we hopefully have a
> full playback like original TuComposer has at least at weekend.

Great!

> When this is finished, I'll continue with fixing the reading of synth
> sound stuff in the demuxer, and after that moving the IFF-TCM1 stuff
> currently in lavf to lavc.
>
> When this is finished, the avseq port will be on par with TuComposer, I
> will then use TuComposer for writing a raw dump of player stuff which we
> can implement as a test case for lavseq, which means we can test avseq
> using make test, et al.
>
> This will immediately show us any regressions when we change something
> in the API which is not on par with TuComposer and see if this breaks
> playback in early times.
>
> Once that's done, everything else should be pretty easy.

> 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.

-Vitor



More information about the ffmpeg-devel mailing list