(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
Hi Paul, Interesting patch! I'm recording mp3 streams from an Icecast server (using curl). This means files will start with partial frames. Most media-players don't have a problem with this, but some do, which results in incorrect bitrate detection for example. If I am right, this patch would solve that problem, causing the recorded file to start on a frame boundary because on connection the stream starts on a frame boundary. For which branch and version of Icecast did you develop this patch? Best regards, Klaas Jan Wierenga Op 25 okt 2011, om 22:10 heeft Paul Kelly het volgende geschreven:> (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 > <icecast-mp3-validation.diff>_______________________________________________ > Icecast-dev mailing list > Icecast-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-dev
Hi Klaas, On Wed, 26 Oct 2011, Klaas Jan Wierenga wrote:> I'm recording mp3 streams from an Icecast server (using curl). This means files will start with partial frames. Most media-players don't have a problem with this, but some do, which results in incorrect bitrate detection for example. > > If I am right, this patch would solve that problem, causing the recorded file to start on a frame boundary because on connection the stream starts on a frame boundary.Yes, it should fix that as far as I can see (if the administrator of the server were to apply the match).> For which branch and version of Icecast did you develop this patch?It is against the 2.3.2 source (it applies cleanly against the Icecast version in Ubuntu 10.04). Sorry should have mentioned that - although it is indicated in the diff header. Also I just noticed an extraneous variable - don't now how I missed that before - you can safely delete the line char message[200]; from validate_header() function. Best regards Paul