[FFmpeg-devel] [PATCH] SHOUTcast HTTP Support

[Micah F. Galizia]

On 10-02-28 03:00 PM, Michael Niedermayer wrote:
> On Sun, Feb 28, 2010 at 12:38:50PM -0500, MIcah Galizia wrote:
>> 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
>> http://205.188.215.225:8012).  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.
>
> the probe code should work fine for mp3.
> if not, thats a bug and if you upload a mp3 file for which it fails i can
> look into this.
> a wget of the urls above does not return mp3 (theres html&  icy stuff
> interleaved). Its of course clear that feeding sliced and diced mp3 is
> not probed which high score. mp3 in avi is not mp3 and we wouldnt want it
> detected as such

I can't comment on the mp3 code (I don't know anything about the file 
format) aside from it requiring a 256Kb buffer before max_frames is 
large enough to consider the probe successful -- maybe that is 
acceptable but it seems too big to me. I have uploaded a sample mp3 that 
demonstrates this behavior to (http://filebin.ca/qkdztr/large_probe.mp3) 
-- this is just a dump of the mp3 data from the streams without the http 
header.

Also, the http URLProtocol strips off http header, and unless we 
actually request Icy-MetaData in the http request (currently, we do not) 
we do not have interleaved metadata, so I disagree that for that reason, 
the streamed data is not mp3.

TIA and I hope the sample helps clarify things.
-- 
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