[FFmpeg-devel] [PATCH] Add libavsequencer.

[Sebastian Vater]

Michael Niedermayer a ?crit :
> 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
>   

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?

-- 

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