Julien Vermillard wrote:
Your server need to do 3 things :
- sending HTTP header with good mime type
- sending the MP3 Header with encoding informations
- sending the compressed MP3 frames until the client disconnect
The way I would do it :) : dump an http reply from an icecast server,
dump the MP3 header and look at the values and try to recode the same
behaviour.
AFAIK there's nothing special about MP3 "streaming". It just uses the
built-in range features of HTTP/1.1. The client, who categorically
knows where the MP3 frames begin and end, will request a particular byte
range from the file when it feels like it wants it, and the server will
respond.
Specifically:
- Server adds "Accept-Ranges: bytes" to every response;
- Client sends "Range: bytes=startByteIndex-endByteIndex" with every
request;
- Server adds "Content-Range:
startByteIndex-endByteIndex/totalFileBytes" to all partial responses;
Personally I would avoid worrying about throttling etc. until you're
sure the client and server OS's built-in TCP stacks aren't doing a good
job. In many ways TCP was born for this job. :)
-0xe1a
