[FFmpeg-devel] [PATCH] Add libavsequencer.

Stefano Sabatini stefano.sabatini-lala
Wed Aug 18 23:58:35 CEST 2010


On date Wednesday 2010-08-18 22:54:06 +0200, Sebastian Vater encoded:
> Michael Niedermayer a ?crit :
[...]
> > i think the problem we have is to get a single mixer and the surrounding
> > code reviewed, understood and into svn currently.
> > More mixers and a mixer selection api isnt going to help here.
> > we are a bit short on reviewing man power for module related code
> >   
> 
> I know, that's why I thought (and agreed with Stefano) that we simply
> start with the simplest version, the NULL mixer ;)
> 
> The null mixer allows to review everything except the actual sample
> reading stuff and optimized stuff. All (software) mixers will
> practically work like this on a very basic manner. So reviewing this
> will give basic understanding.
> 
> > That said, there is nothing wrong with you working and improving what you
> > like to. It doesnt help us to move forward with getting anything into svn
> > though
> >   
> 
> It's just an idea I got while recently talking to Stefano regarding
> this. So I thought to summarize our discussion regarding this here and
> bring it to discussion.
> 
> Still, it has nothing to do with the basic avseq integration patch, it
> won't change regarding the final mixer API we will finally take
> (regarding the hold back question).
> 
> Maybe regarding the mixer stuff, could you give a suggestion, what I
> should post here as [PATCH] for integration and what not?

Trying to resume the main points here:
1) do we want a libavsequencer *independent* from libavcodec? Such a
   library may be used for BSS definition / API and *eventually* for
   mixer API. The latter should be moved to some other place in a
   second moment, where it can be used indepentently from lavseq.

   Keeping BSS independant from lavc has also the advantage that for
   example a MOD composer application won't depend on libavcodec, so I
   tend to prefer this option.

2) BSS, which will go to libavsequencer, is still on a design
   discussion phase. Maybe it's time to move the current discussion on
   ffmpeg-soc here, where it would have more visibility.

3) As for the mixer API, there are many related problems. Do we want
   such a complex API? I see the advantages of the design proposed by
   Sebastian, but then I'm not really an audio expert so I don't feel
   like I can't properly judge the implications of such a design.  The
   location of the API is a secondary problem, since it can be moved
   wherever we'll want in a second moment (libavmixer?,
   libavresample?).

   What's for sure is that such an API will require a good amount of
   time (indeed it could have been a GSoC task dedicated just for it),
   if our objective is getting MOD support integrated as soon as
   possible, then it would be better to rely on a much simpler API, so
   this really depends on who will do most of the work (which is
   likely Sebastian in this case), as for me I'll try to help as I can
   in review (and mixing looks also required by audio lavfi).

...

So in the end I suggest this course of action: apply the lavseq patch,
*or* if we want to add more stuff to it before to commit it, then
maybe we should focus on the BSS. Once that's ready, we can create
lavseq *and* immediatly commit the BSS definition.

Alternatively we can work on the BSS *in libavcodec*, once it's ready
we can create lavseq and move it to the new lib.

The mixer path mainly depends on the contributors involved, on Michael
and/or on who have ideas related to the advantages of such a design.

Also I'd like to start to think about this eventual libavresample
(required by audio/lavfi), we could eventually plan to add the mixer
API there.

Regards.
-- 
FFmpeg = Fundamentalist and Fundamental Magic Pacific Enhancing Genius



More information about the ffmpeg-devel mailing list