Re: Proposed Aim for Speak Freely

Thomas,

If there are going to be more codecs than there are now (a bad idea, IMHO),
then there should be a 2-way negotiation process to select codecs for
both sides of a conversation.  Each side should be able to limit the
negotiation to a subset of codecs in the event of local low network or CPU
bandwidth, or in the event of missing/broken codecs.  When you start adding
codecs willy-nilly, it is likely that people with older SF versions won't
have the latest whizbang codec that handles 6 channel surround sound,
10Hz-100KHz  +- 0.5 dB with 0.01% THD.

Telnet has a portion of its protocol devoted to negotiating an agreed upon
mutual video format.  I don't remember the exact token syntax, but its
something like "can",  "won't", "do", "don't".  The server tells the client
which video terminal emulation features it can and can't do.  The client
asks from the list of server-supported features the ones it wants the server
to "do".  Everybody is happy - sort of. :-)  There is an RFC that covers the
Telnet negotiation scheme - it might be a good paradigm for SF codec
negotiation.

Things will get really complicated in conferences.  There may not be enough
bandwidth in the conference "reflector" to handle wideband data streams,
sent out to many listeners.  The negotiation process would be very complex -
I suppose you'd have to use the lowest common denominator for all conference
members.  The conference reflector may have to keep track of the individual
abilities and preferences of each of its conference members and possibly act
as a codec negotiation proxy.

Breaking the application into well documented DLLs / SOs is a great idea.
Not everyone needs a GUI, especially if you want to add VOIP to an existing
app (like me).

Kevin

----- Original Message ----- 
From: "Thomas Shaddack" <[email protected]>
To: <[email protected]>
Sent: Monday, August 18, 2003 11:13
Subject: Re: [speak-freely] Proposed Aim for Speak Freely


> On Mon, 18 Aug 2003, Kevin McCoy wrote:
> > After all the important stuff is done, then add all the codecs you
like -
> > but make sure you #ifdef them in the code so I can shut them all off :-)
If
> > you guys can come up with codecs that use LESS bandwidth than the ones
> > already included in SF with decent audio quality, then go for it.
>
> Let's define the codec API. Then it will be possible to add new codecs
> (and ciphers, etc.) as .DLL (in Windows) or .SO (Linux) files,
> modularizing the code and removing the discussions about exotic and
> high-bitrate codecs from the mainstream part of the project to the
> appropriate byprojects.
>
> Another thing to take care of is the negotiation process for the codec to
> be used. The system's reaction when the other party has an unsupported
> codec should be cleanly defined (and if possible offer user override for
> the "I know what I am doing and there is a bug and a compatible codec
> claims it is incompatible" situations).
>
>
>                       * * *
>
> To unsubscribe from this mailing list, send E-mail containing
> the word "unsubscribe" in the message body (*not* as the
> Subject) to [email protected]
>



                      * * *

To unsubscribe from this mailing list, send E-mail containing
the word "unsubscribe" in the message body (*not* as the
Subject) to [email protected]