[FFmpeg-devel] [PATCH] Add libavsequencer.

[Michael Niedermayer]

On Wed, Aug 18, 2010 at 10:21:28PM +0200, Sebastian Vater wrote:
[...]
> Regardings to pluggable mixing API, I summarize the discussion I had
> recently with Stefano about this.
> 
> The point is we were discussing about OPL2/3 and such special stuff, but
> the actual point is way much simpler and closer (10l to me for that).
> 
> We were discussing only pure software mixing engines (like low / high
> quality mixers), but totally missed out the point (blame me for this,
> not remembering this although I did knew/know this perfectly), that
> there are a lot of hardware mixing capabilities.
> 
> I remembered it when I discussed the features of original DOS Cublic
> Player (the most famous MOD player in that time) and it's move to open
> source today known as OpenCubicPlayer (look at a package named ocp in
> your Linux repository) which supported not only basic software mixing
> (null, lq, hq and floating point mixer) but also hardware capable mixing
> (in the DOS time there was an GUS mixer, a SB AWE 32/64 EMU8000 chip
> mixer, etc.).
> 
> Now, of course, we don't work with old Gravis UltraSound cards and/or SB
> AWE 32/64, but today we have:
> DirectSound mixing API (which uses hardware mixing of modern soundcards
> if availble), or OpenAL (same for Linux, etc.) API.
> 
> Since practically every soundcard today supports hardware mixing, it
> would pose up the question: "Why not use HW mixing as only option then?".
> 
> Well the answer is. Hardware mixers are very different in its features /
> capabilities, esp. maximum number of channels, volume stuff and output
> sampling rate.
> 
> The craziest one is probably the GUS regarding this, the more maximum
> number of channels you did allocate, the lesser the maximum sampling
> rate allowed was (this is independent of how much channels are actually
> being played).
> 
> Such limitations still apply to most hardware mixers today (very often
> we have a limit of 64 channels, panning also (often no surround), volume
> ranges, etc.)
> 
> Now you remember the point, I told already, that you can "chain" mixers
> as I planned and posted them here as patch (see my copying channels from
> lq to null mixer and back in the exact seek discussion).
> 
> This is, where FFmpeg again can kick ass, if we manage it to offer an
> mixer API which a) utilizes hardware mixing devices and b) software
> mixing devices...we can combine THEM!

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

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100818/0f0f8501/attachment.pgp>