[FFmpeg-devel] [PATCH] SHOUTcast HTTP Support

[Michael Niedermayer]

On Mon, Mar 01, 2010 at 06:36:19PM -0500, Micah F. Galizia wrote:
> 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.

the file you provided is not compliant mp3
the first thing resembling mp3 starts at byte 294, before this is either 
a partial frame or not mp3 at all
the probe code behaves correctly in requireing more data to make sure that
its really mp3 that is corrupted at the start and not some other file
format that contains mp3. (avi containing mp3 would look the same to the
probe code ...)
what are these 294 bytes?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100302/a04e5290/attachment.pgp>