[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