[FFmpeg-devel] [PATCH] Add libavsequencer.

Stefano Sabatini stefano.sabatini-lala
Thu Aug 19 16:21:11 CEST 2010

On date Thursday 2010-08-19 09:50:26 -0400, Ronald S. Bultje encoded:
> Hi,
> On Wed, Aug 18, 2010 at 7:10 PM, Stefano Sabatini
> <stefano.sabatini-lala at poste.it> wrote:
> > On date Wednesday 2010-08-18 18:49:04 -0400, Ronald S. Bultje encoded:
> >> We already discussed that for the time being, BSS will be private
> >> because we'll want to modify it a lot. The synth mixer should not be
> >> public, imo. What, then needs a public API with library versioning
> >> etc.?
> >
> > So I suggest to start to work on libavcodec, both BSS and eventually
> > mixer would go there and would be *private*. ?Then we'll move them to
> > libavwhatever.
> I think this is best. I'd like to see patches that place BSS, synth
> mixer and the TCM decoder (data in, BSS intermediate, PCM out) in
> libavcodec/, and the TCM demuxer (file in, data+metadata out) in
> libavformat/, so that (after applying those 4 patches) ffplay can play
> TCM files.
> Sebastian, can you prepare such patches so we can do a complete review
> of all code required for TCM playback? I don't mind if it's big,
> because eventually we'll have to review everything anyway, but
> obviously smaller is better and unused/overdesigned/unnecessary/etc.
> code is unacceptable. Hopefully the modplug guys can help us review
> BSS also then. The nice thing of doing it this way is that we can
> don't have to mark it experimental. It's just like any other codec.
> Once all that is reviewed, committed, the synth mixer is good and
> appears to be more broadly useful, we can consider moving it into
> libavfilter (or libavcore, accessible for both libavfilter and
> libavcodec), but that should not be the original goal just yet. The
> original goal should be TCM playback, nothing more. Also, note how
> lavseq/ is suddenly not necessary anymore.

I still see a scenario when having libavsequencer may be
useful. Suppose that there is a composer application which for
whatever reason wants to use the BSS definition but doesn't want to
link against lavc/lavf. Having the BSS definition in a distinct
libavsequencer would allow this (then the app may use whatever library
for muxing/demuxing/decoding/encoding), but it can still use
lavseq+libvavdeps for the BSS -> PCM conversion.

The other advantage of such approach is that it would be simpler to
keep all the new code disabled by default.

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.

FFmpeg = Fostering & Freak Magical Patchable Egregious Guru

More information about the ffmpeg-devel mailing list