(#493) Speex codec options

Message posted to the Speak Freely Forum
  by John H on Tue, 14 Oct 2003 02:18:13 +0200 (MEST).
  http://www.fourmilab.ch/wb/speak-freely.pl?rev=493

I'm just about to add the speex codec into speakfreely, but there are still
some design decisions to be made, as speex offers a lot of options. It offers
2k, 4k, 8k, 11k and 15k bitrates with 20ms frames, and each frame can have a
different bitrate if desired. A constant 8k is pretty similar in quality to
gsm, though there is a bit more echoing. The lost packet recovery is much
better though. Working with 4 frames to a packet (80ms), a 20% packet loss
bridged with speex extrapolation is quite tolerable.

My current idea is to use the Speex variable bit-rate encoding algorithm,
which gives GSM quality at average about 6kbps, and peaking at 15kbps.
Basically the receiver could handle any packet size, and it would be up to the
transmitter what to send.

There is a complication though, and that is I have the idea of including
redundancy via a separate 2kps encoding. At 22bytes per 80ms packet, it's not
worth the 28bytes of headers (IP, UDP, RTP) to send it as a separate packet,
but it could be appended to the subesquent outgoing packet. My packet queuing
code will already allow (t+1) packet information to be used to interpolate a
(t) packet (if it's arrived), but it raises the question of how the packet
would be coded.

I had originally been hoping to code up the speex rtp standard, but of course
it has no facility for redundancy. Placing the redundant informant at the end
would help compatibility, but with the variable bit rate, it's not so quick to
search forward and find it when necessary. Conversly, at the start it's quite
easy to skip past the 22bytes of reduntant data to get to the normal bytes. So
now I'm leaning to placing the redundancy at the start of the packet. So while
standard speex could be a run-time option, I would be leaning to a
non-standard format as the norm.

In the tests I've done, you can bridge out a 20% packet loss from an 8kbps
stream with the 2kbps data with very little perceptable quality loss. Then
when no redundant information is available, the speex extrapolation can be
used instead.

So my question is: does anyone have any ideas or suggestions about how this
should be done?

Once I've tried this speex encoding out, I may have a look at replacing the
speakfreely for windows transport code using the oRTP and oSIP libraries,
which should make it compatible with Linphone. Then it will be time to make
some improvements to linphone.... :-)


                      * * *

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