[Icecast-dev] Patch - MP3 Frame validation

Paul Kelly paul at stjohnspoint.co.uk
Tue Oct 25 13:10:20 PDT 2011


(I'm aware that this patch is not likely to be accepted in the upstream 
source because Icecast doesn't really support MP3, but I thought it 
worthwhile to send it here in case anyone wishes to modify their local 
source with it.)

Background:

Icecast does not make any attempt to demarcate the boundaries between MP3 
frames, and when a listening client connects to the server it generally is 
sent an initial partial frame that can't be decoded. This is not a problem 
for almost all client players.

It becomes a problem however when a "pre-roll" intro clip is used. When 
Icecast connects the listener to the main stream after playing the intro 
clip, it will very likely cut in in the middle of a frame, which causes a 
problem for some players. Flash player in particular exhibits strange 
behaviour with the audio cutting in and out every few seconds. Pausing the 
player and resuming cures the problem.

A likely explanation for this is as follows (a best guess; may contain 
some slight inaccuracies and/or generalisations):

Adobe doesn't provide a facility in Flash Player to play a continuous 
audio stream via HTTP (e.g. from Icecast). Flash-based MP3 players 
typically get around this by downloading the stream in lots of separate 
overlapping chunks and playing these as if they were individual files. 
When one chunk is getting near the end, it starts playing the next chunk 
and then cross-fades into it. In effect there are two mini-MP3 players 
operating with constant cross-fading between them.

It looks like what is happening is that the player that was playing when 
the junk data occured at the crossover has got stuck, but that the other 
one is still functioning normally. Therefore silence is heard when the 
"stuck" player is supposed to be doing its bit, but normal audio when it's 
the other one's turn.

The attached patch address the issue by modifying Icecast so that it 
parses the MP3 data and makes sure it only starts streaming to a client at 
a frame boundary. It is in production use on a number of Icecast servers 
and is working well.

Note that the "channels" member of the mpeg_frame_t struct (and the 4 
lines of code in the validate_header() function that calculate its value) 
are not strictly necessary for the frame validation, but are included for 
completeness.

I hope it is useful for someone.

Best regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icecast-mp3-validation.diff
Type: text/x-diff
Size: 7159 bytes
Desc: 
Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20111025/8f4835f9/attachment.diff 


More information about the Icecast-dev mailing list