[Icecast-dev] Patch - MP3 Frame validation

[Klaas Jan Wierenga]

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