[FFmpeg-devel] [PATCH] Add libavsequencer.

[Sebastian Vater]

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.

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.

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.

-- 

Best regards,
                   :-) Basty/CDGS (-: