[FFmpeg-devel] [PATCH] SHOUTcast HTTP Support

MIcah Galizia micahgalizia
Sun Feb 28 18:38:50 CET 2010

On 10-02-28 11:43 AM, Michael Niedermayer wrote:


>> I have moved the probe loop into its own method and it is working for ogg
>> (because ogg_probe is so simple), but it causes a problem for mp3 streams
>> due to the minimum score we require when probing the stream. In utils.c,
>> unless we have reached the max probe buffer size, score_max is 25 and
>> unless the demuxer returns a probe score>  25, that demuxer will not be
>> used.
>> The mp3 demuxer does not return>  25 unless max_frames>  500 or
>> first_frames>  4.  I don't know anything about those frames (or what they
>> do), but I have observed that those conditions are not met until we have
>> read 256Kb (on a local file and a stream without icy).
> I think ive fixed this, if not i need the mp3 file that is failing to be
> detected quicker

I just pulled down a clean version of ffmpeg from svn and for my local 
mp3 file, first_frames is no longer zero each time so the probe succeeds 
much faster (buffer size is 1<<13). However, the problem still exists 
for the streams I have been testing with. Try playing 
http://shoutcast1.cbcradio3.com (or chronix radio at  Both of these still require a buffer size 
of 1<<18 and reconnect three times. Also, first_frame is always zero for 
these streams.

After updating my modified version of ffmpeg with icy turned on, the 
results are event worse (I suspect because of the metadata) and the 
probe keeps failing.

>> However, in a
>> shoutcast stream, the interleaved metadata is included after only 32K.
>> This causes problems, as I cannot keep track of the metadata (since we read
>> way beyond it) and the metadata is also causing problems for the mp3
>> demuxer.
> so your code is buggy ...

It had more to do with reading way beyond several metadata segments in 
utils.c which prevents me from knowing how much of the data we have read 
was actually metadata, so I can't synchronize my counts. In any case, 
it's a non-issue since we do start from the beginning of the stream 
after the second probe (that was my misunderstanding).

>> Additionally, reconnecting this many times (closing and
>> reconnecting each time the buffer size is doubled from 2K to 256K) makes
>> opening the stream _really_ slow.
> dont reconnect, but keep reading more data

I'll defer seeking back to the start until after the probe succeeds.

>> What I would like to do to resolve this, is require that the piece of code
>> calling the probe method specify the score required as a parameter.  That
>> way, the shoutcast demuxer could lower the requirements (maybe
>> AVPROBE_SCORE_MAX/10) and utils.c could maintain 25 (AVPROBE_SCORE_MAX/4).
>> Any thoughts?
> iam against adding random hacks to patch over bugs

Micah F. Galizia
micahgalizia at gmail.com

"The mark of an immature man is that he wants to die nobly for a cause, 
while the mark of the mature man is that he wants to live humbly for 
one."   --W. Stekel

More information about the ffmpeg-devel mailing list