[FFmpeg-devel] [PATCH] Add libavsequencer.
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?,
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
FFmpeg = Fundamentalist and Fundamental Magic Pacific Enhancing Genius
More information about the ffmpeg-devel