RTP Stuff from Fefe

(Note: This is from 1999 and has not been touched since 2000)

RTP is the Realtime Transport Protocol as defined in RFC 1889. It is the transport mechanism of choice to multicast an mp3 stream.

[Update!] A new version of the code is now available as rtp2.tar.bz2. It support IPv4 and IPv6 unicast and multicast and contains a trivial sender and a trivial receiver that can be used to send or receive arbitrary data over RTP. An implementation of generic forward error correction is planned, too.

For the 1999 Chaos Communication Congress it was decided that we should make mp3 files of the three concurrent workshops for archival purposes. We also decided to provide the streams over the network (at least locally) so that people can attend workshops even if the workshop room is full.

It is clearly desireable not to congest the congress network with concurrent transfers of the same unicast stream, so we wanted to multicast the three workshops. Since there were no free open source programs to encode and multicast an mp3 stream, I decided to write my own.

There are several parts to this solution:

  1. lame-3.58-rtp.diff [7k]. This is a unified diff (you probably need GNU patch to apply it) to lame 3.58. Please note that this diff is now obsolete as recent beta versions of lame include a version of this code. Just type "make mp3rtp". The code was broken, but the CVS code is reported to work (and interoperate with playRTPMPEG) as of Feb 21 2000.
    Please note that the output stream will only have the correct speed if the input is live recorded stream from your sound card or lame encodes exactly in real-time on your CPU!
  2. receiver.tar.gz [3k]. This is a trivial receiver. Compile with gcc -o main main.c. Usage is ./main multicast-ip port. If invoked as "unicast.cgi", it will simulate an HTTP server that simply outputs all multicast packets to every connecting client. Please note that this is a gross hack, it does not even look at the HTTP request and the multicast IP and port are hardcoded ;-). Please don't complain but send diffs.

Andreas and me have tested the sender and the receiver for 24 hours straight and both do not leak memory or dump core mysteriously (so far).

Warning! Writing a good RTP receiver is much harder than writing a good RTP sender. This receiver does not handle dropped, corrupt, duplicate or out-of-order packets gracefully. It is only useful over a LAN in its current state. We will maybe publish a better receiver soon.

BTW: I know about gogo and also considered writing a gogo RTP backend, but the lame sources looked easier to hack. gogo is a very good mp3 encoder and if you send me a patch for it, I will gladly host it here, too (with full credits to you, of course).

This code is published AS IS and WITHOUT ANY WARRANTY and I hereby place it under the GNU General Public License. I wrote this code while working for Convergence, thanks to them for paying my food. This code is (c) 1999 Convergence.

Why patch lame and not write an external program?

Good question. Basically, if you write an external program, you have to parse the MPEG stream yourself, so you know how much data to send this second. Or, you kludge around the issue and parse only the first few bytes, then your program will only work for non-VBR mp3s :(

I like my kludge better.

See also